UDP sendto échoue lors de l'utilisation de tables de routage spécifiques

J'ai un système avec plusieurs interfaces. J'ai isolé toutes ces interfaces les unes des autres à l'aide de quelques sysctloptions, de tables de routage et de règles.

Chaque interface a sa propre table de routage définissant une route par défaut.

Chaque table de routage a un ensemble de 4 règles qui définissent quels paquets doivent aller à quelle table.

Pour simplifier, disons que j'ai eth0 (192.168.1.1)et eth1 (192.168.1.2).

de 192.168.1.1tableeth0

à 192.168.1.1tableeth0

iif eth0 table eth0

oif eth0 table eth0

Car eth2c'est pareil.

Les sysctloptions sont:

net.ipv4.conf.all.arp_filter = 1
net.ipv4.conf.all.arp_ignore = 2
net.ipv4.conf.all.arp_announce = 1
net.ipv4.conf.all.rp_filter = 1

Cela fonctionne très bien pour 99% des cas d’utilisation auxquels je suis destiné, mais l’un échoue. Si un paquet est généré à partir d'une socket non liée, comme pour répondre à un client UDP avec "sendto", l'appel échoue avec "Network Unreachable". Si une adresse IP spécifique est liée avant d'appeler sendto, l'appel aboutit comme prévu.

En dehors de la configuration d'une route par défaut fourre-tout pour de telles situations, y a-t-il quelque chose qui puisse être fait en utilisant un routage de politique (par exemple, iptables, règle d'IP) pour résoudre ce problème?

Merci

— IMerin
source

Une solution utilisant une marque avec iptables ne vous aidera pas. Le point d'ancrage de sortie de iptables se produit après la première recherche d'itinéraire ("décision de routage") et déclenche une seconde recherche ("contrôle de redirection"). Donc, utiliser la marque d'iptables n'aidera pas ici, car "le réseau est inaccessible" se produit à la première recherche et la table mangle n'est jamais utilisée. Voir cette image: en.wikipedia.org/wiki/Netfilter#/media/…

— AB

Mais ajouter cette route par défaut, même si vous n’avez jamais l’intention de l’utiliser, autoriserait alors l’utilisation de la règle mark + ip fwmark de iptables (à partir de la vérification de la redirection déclenchée). Je ne sais pas s'il existe une solution en utilisant iptables pour ce problème, mais une route par défaut "par défaut" est toujours nécessaire si iptables est impliqué

— AB

Merci. Existe-t-il une solution n'impliquant pas les tables ip? Je me demande pourquoi la recherche de routage échoue si l'adresse source est spécifiée et j'ai une règle indiquant tous les paquets de l'adresse source X. Utilisez la table Y

— IMerin du

Et ça? ip link add dummy0 type dummy; ip link set dummy0 up; ip route add default dev dummy0. De toute évidence, aucun paquet ne sera envoyé au mauvais endroit. Lors de mon test avec socat, je suis passé de "Le réseau est inaccessible" à une réponse avec la source 192.168.1.1 lorsque le même réseau a été contacté via eth0 à 192.168.1.1. Maintenant, cela semble être un cas simple. Existe-t-il un cas réel? Au fait, vous n'avez pas écrit de route dans la question, donc je ne peux pas faire plus que ça ici

— AB

ok, les choses fonctionnent bien pour répondre (y compris le cas de l’UDP). Mais lors de l'établissement d'une connexion sortante, sans indiquer d'adresse IP, il choisira l'adresse IP de la première interface (192.168.1.1) et l'interface de routage par défaut dummy0. Mais si je marque ensuite le paquet, il déclenche une vérification de la redirection et suit enfin les règles attendues (donc passe à eth0), pas même la nécessité d'ajouter une règle fwmark, la redirection à elle seule le fait.

— AB