Petit soucis entre IP public direct et routeur voisin

bonjour a tous,

je vous explique mon petit soucis qui n’en ai peutêtre pas un dailleur

j’ai deux interfaces connecter a internet
l’une avec eth0 en 77.207.x.x
l’autre en eth2 en 192.168.2.20 avec un routeur

lorsque je suis avec une IP extérieur a 77.207.x.x je peux accèder a ma debian avec l’ip de la connexion dsl qui est sur( eth2 mais lorsque je le fait avec 77.207.x.x j’ai rien qui viens

comme ci cela bloqué du fait que ce sois son IP a lui et du coup qu’il sache pas ou renvoyé les paquet (ceci n’est qu’une ipothèse)

quelques petite table de routage

77.207.x.0/26 dev eth0 proto kernel scope link src 77.207.x.x
192.168.2.0/24 dev eth2 proto kernel scope link src 192.168.2.20
default via 77.207.x.1 dev eth0

mercid’avance si vous avez compris mon problème si toute fois cela en ai un.

Jérémy

Il y a deux causes de problèmes bien connues lorsqu’il y a plusieurs connexions internet et du NAT.

  1. La validation d’adresse source
    La pile IPv4 du noyau Linux a un mécanisme de validation d’adresse source optionnel basé sur le “filtrage par chemin inverse” (reverse path filtering, rp_filter). En clair, la pile n’accepte un paquet d’une adresse source A reçu sur une interface I que si la table de routage route l’adresse A par l’interface I. Ce filtrage est contrôlé par le paramètre du noyau sysctl net.ipv4.conf..rp_filter (/proc/sys/net/ipv4/conf//rp_filter).

Dans ton cas, si rp_filter est activé pour eth2, alors les paquets provenant de 77.207.x.x relayés par le routeur sont rejetés puisque la table de routage dit que 77.207.x.x est routé par eth0.

  1. Le chemin asymétrique
    Le NAT a besoin d’un chemin symétrique à l’aller et au retour. En effet si l’adresse destination (resp. source) est modifiée à l’aller, alors l’adresse source (resp. destination) doit être restaurée au retour avec l’adresse originelle.

Dans ton cas, une requête provenant de 77.207.x.x atteint le routeur NAT, est redirigée vers l’adresse 192.168.2.20 mais le chemin retour de la réponse vers 77.207.x.x passe par eth0 et non par eth2 et le routeur NAT. 77.207.x.x reçoit donc une réponse non modifiée ayant comme adresse source 192.168.2.20 qui ne correspond pas à la destination de sa requête.

bonjour,

donc en encore plus claire, le problème que je vous décrit vous semble normal ?

et on peux pas y remédier sans modifier trop de chose

Jérémy

Disons que c’est le genre de problème qu’il faut s’attendre à rencontrer si on ne fait pas attention. Je ne dis pas que c’est insoluble. Par exemple si cela vient de la validation d’adresse source, il suffit de la désactiver sur la ou les interfaces concernées.

Cependant il y a ici un détail qui me trouble : la route par défaut est par eth0, du même côté que 77.207.x.x. et non par le routeur NAT. Par conséquent les requêtes envoyées à l’adresse du routeur depuis n’importe quelle adresse source publique et pas seulement 77.207.x.1 devraient aussi être affectées.

ben dans la mesure ou l’autre passerel par féfault est configurer avec ip route dans le fichier interface cela fonctionne …

a moins que j’ai mal compris ce que vous voulez me dire

Jérémy

On peut avoir des détails sur cette configuration ?

je montre l’exemple pour eth2

dans interface

auto eth2
iface eth2 inet static
address 192.168.2.20
netmask 255.255.255.0
network 192.168.2.0
up /sbin/ip route add default via 192.168.2.1 dev eth2 table 125
up /sbin/ip rule add from 192.168.2.20/32 table 125
post-down /sbin/ip rule del from 192.168.2.20/32 table 125

la table 125 ne correspond a rien sur le linux mais le code fonctionne comme ça donc je l’ai laisser

Jérémy

D’accord, a priori cela exclut le routage asymétrique. Reste à vérifier la valeur de rp_filter pour eth2 car malheureusement la validation d’adresse source ne tient pas compte des règles de routage avancées basées sur l’adresse source.

La table 125 est une table disponible parmi d’autres, pas besoin de justifier. J’utilise pour ma part les tables 100, 101… Chacun fait comme il veut.

re,

voici ce que cela me retourne
net.ipv4.conf.eth2.rp_filter = 0

interressant toute ces discutions

Jérémy

Alors ce n’est pas ça non plus. Il n’y aurait pas des règles de filtrage iptables sur la machine qui pourraient bloquer le trafic entrant ou sortant avec 77.207.x.x sur eth2 ?

non malheureusement

si pas d’autres idées je montrerai mes règles iptables

mais je suis impossible de me rappeler si cela a déjà fonctionner puisque je me connecte rarement avec moi même

merci de vos conaissances

tu as deja essayé de couper la pate qui fonctionne pour tester deja seulement la connexion qui passe par le routeur ? pour deja etre sure que tout est bien configuré

tout fonctionne impécable puisque comme je l’ai dit depuis une autre IP que la mienne cela fonctionne
Jérémy

J’ai du mal à comprendre ton problème et ses résultats. Mais je pense que le VPN est peut être la solution qui s’impose

je pense qu’il y a tout simplement pas de réponse a ma question

le débat reste ouvert

Il serait intéressant de tracer les paquets pâssant par les deux interfaces par tcpdump, cela permettrait peut être de voir le pbm.

Un petit schéma aiderait certainement aussi

bonjour dmon,

je pense que tout figure dans mon premier poste

a mon simple avis les paquet reparte pas dans l’autre sens vu qu’il y a déjà une route de 77.207.x.0

Jérémy

C’est facile à vérifier en faisant une capture de paquets sur chaque interface comme François l’a suggéré.

Quand tu as écris “lorsque je le fait avec 77.207.x.x j’ai rien qui viens” dans ton premier message, tu voulais dire depuis une autre machine du réseau 77.207.x.0/26 ou depuis la machine elle-même ? Dans le second cas, c’est normal que ça ne marche pas pour deux raisons.

  • Validation d’adresse source : même si rp_filter est désactivé, le noyau refuse les paquets dont l’adresse source appartient à la machine reçus par une interface autre que l’interface de loopback. Donc les requêtes provenant de l’adresse d’eth0 reçues par eth2 sont jetées.

  • Routage asymétrique : lorsque la destination est une adresse locale, les paquets sont routés par l’interface de loopback, car la table de routage “local” a priorité sur toutes les autres. Donc si les requêtes n’étaient pas jetées, les réponses seraient émises sur l’interface de loopback et non par eth2 vers le routeur NAT comme il faudrait.

bonjour pascal,

je le fait depuis mon réseau local mais la sorti ce situe bien a 77.207.x.x puisque c’est ma connexion internet principal.

donc ok je comprends bien c’est impossible et donc contrairement a ce que j’ai plus croire cela n’as du jamais fonctionner

Jérémy.