eth0 et eth1 ne se cause plus

Support Debian
#1

salutatous

je reinstall un pc qui me sert de firewall ou pour commencé, il y à 2 crt reseau
eth0(192.168.1.2) -> qui file dans la box (192.168.1.1)
eth1 (192.168.10.2) -> mon LAN

j’ai mis shorewall de base en mettant bien startup = 1 et IP_FORWARDING = yes

mon fichier /proc/sys/net/ipv4/ip_forward est bien à 1

j’ai mis dans le fichier autorespond eth1

malgre shorewall sur stop rien ne passe

ca doit être d’une betise monstrueuse ça fait 2 jours que je cherche en vain

du firewall je ping eth0 et 1 ainsi que la box

de mon pc je ping eth1 mais pas eth0 et la box

a+

#2

une idée pour débugger.
Sur un PC de ton LAN, fait un traceroute vers la box

#3

[quote=“piratebab”]une idée pour débugger.
Sur un PC de ton LAN, fait un traceroute vers la box[/quote]
Et une capture “tcpdump” sur chacune des interfaces de ton serveur pour voir jusqu’où transite les paquets.

#4

que donne :

que donne :

Merci

#5

Je soupçonne que cela doit plutôt être “IP_FORWARDING”.

N’est-ce pas dans /proc plutôt que /etc ?

Qu’est-ce que c’est ? (je ne connais pas shorewall)

Qu’est-ce qui te fait dire cela ?
Il ne faudrait pas aussi du masquerading qui n’aurait pas été activé ?

Non, on ne ping pas une interface mais une adresse. En l’occurence il s’agit des propres adresses de la machine, donc le ping et sa réponse passent par l’interface de loopback lo et non les interfaces ethernet. Sans intérêt.

Je suppose que tu veux dire : depuis le PC tu obtiens une réponse à un ping vers l’adresse LAN du firewall, mais pas vers l’adresse WAN ? C’est intéressant. Soit le PC n’a pas la bonne route par défaut, soit le firewall filtre en entrée en fonction de l’adresse de destination ou en sortie en fonction de l’adresse source. En tout cas cela ne fait pas intervenir le forwarding puisque ces deux adresses appartiennent au firewall. Voire du filtrage sur le PC.
Il y a des messages d’erreur ?

iptables-save, c’est mieux.

#6

merci a tous pour vos réponses et excuse moi pascal pour ses fautes de frappes :unamused: je les est corrigées

j’avais raison

ma carte du FW eth1 = 192.168.10.2 j’avais mis comme passerelle sur le pc 192.168.10.1 une fois modifier tout est partis

a+ gilles

#7

C’était ma première hypothèse : “le PC n’a pas la bonne route par défaut”.

#8

Non, on ne ping pas une interface mais une adresse. En l’occurence il s’agit des propres adresses de la machine, donc le ping et sa réponse passent par l’interface de loopback lo et non les interfaces ethernet. Sans intérêt.[/quote]

Pas d’accord. Une IP configurée sur un interface ne correspond pas à la loopback.
Un PING vers la loopback permet de s’assurer que la pile TCP/IP est opérationnelle.
Un PING vers une IP configurée sur une interface (style eth0) permet de tester la pile TCP/IP + la configuration IP de l’interface (test juste l’adresse IP) + permet de vérifier que l’interface soit correctement monté au niveau 2 (ARP).

iptables-save, c’est mieux.[/quote]

Merci, effectivement c’est mieux! C’est d’ailleurs ce que je recherchais. :041

#9

Si, si on y accède depuis la machine elle-même.

$ ip -4 addr ls dev eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0 $ ip route get 192.168.0.1 local 192.168.0.1 dev lo src 192.168.0.1 cache <local> mtu 16436 advmss 16396 hoplimit 64
On voit bien que l’adresse configurée sur eth0 est atteinte par lo.

Non, pas besoin que l’interface correspondante soit montée.

#10

Effectivement tu as raison, je viens d’effectuer des tests de PING en VM vers une interface déconnectée et cela fonctionne.

[La confiance n’exclue pas le contrôle]

Merci pour ces infos et bonne soirée.