Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

ipv6, pare-feu, perte de connexion

12 réponses
Avatar
Yannick Palanque
Bonjour tout le monde,

Voilà, j'ai une machine qui obtient une adresse IPv4 et un bloc /48
IPv6. « Tout marche bien » sauf que je perds (je ne saurais expliquer
ce qui se passe dans le détail) ma connexion IPv6 lorsque je bloque le
trafic IPv6 entrant avec Netfilter, ce qui ne se produit pas en IPv4.
Quelques précisions :

- Le système d'exploitation est une Gentoo Linux plutôt récente (noyau
2.6.26 par ailleurs).
- Mon fichier de configuration en ce qui concerne le
réseau, /etc/conf.d/net, ressemble à :
modules=( "iproute2" )
config_eth0=( "42.41.233.142/24" "2001:42:1871::2/48" )
routes_eth0=( "default gw 42.41.233.1" )


0/ $ ip address show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
qlen 100 link/ether 00:30:48:80:42:62 brd ff:ff:ff:ff:ff:ff
inet 42.41.233.142/24 brd 42.41.233.255 scope global eth0
inet6 2001:42:1871::2/48 scope global
valid_lft forever preferred_lft forever
inet6 fe80::230:48ff:fe83:4362/64 scope link
valid_lft forever preferred_lft forever



1/ Les règles ip6tables sont vides :
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy DROP)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination


2/ Je peux joindre n'importe quelle machine en IPv6 :
PING geeknode.org(2001:758:1664::1667) 56 data bytes
64 bytes from 2001:758:1664::1667: icmp_seq=1 ttl=63 time=0.897 ms
64 bytes from 2001:758:1664::1667: icmp_seq=2 ttl=63 time=0.781 ms
64 bytes from 2001:758:1664::1667: icmp_seq=3 ttl=63 time=0.447 ms


3/ Si je bloque le trafic entrant en utilisant la règle
ip6tables -P INPUT DROP
accompagnée de
ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
je perds aussitôt la connexion IPv6 (ICMP, IRC, etc.). Je ne vois rien
de particulier dans les journaux.


Ce comportement ne se produit pas avec l'IPv4, je peux bloquer les
paquets entrants sans perdre aucune connexion sortante. Il se trouve
que je ne comprends pas encore tout à l'IPv6. :-P
Le fait que tout un bloc m'est « routé » (ce que je n'ai pas
entièrement compris) m'oblige-t-il à prendre des dispositions
particulières ? J'avais ajouté une règle pour autoriser le trafic
venant de 2001:42:1871::1 (la passerelle) sans résultat positif.

Je suis sûr que c'est tout bête. Une piste ? :-)

Yannick

--
« Quand je serai grand, je ferai des bug reports sur la LKML »
-- Octane in fcolm

2 réponses

1 2
Avatar
Jean-Michel Company
Yannick Palanque wrote:


3/ Si je bloque le trafic entrant en utilisant la règle
ip6tables -P INPUT DROP
accompagnée de
ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
je perds aussitôt la connexion IPv6 (ICMP, IRC, etc.). Je ne vois rien
de particulier dans les journaux.






Il me semble que ces états (ESTABLISHED,RELATED) ne sont pas encore
gérés par ip6tables.....
Personnellement, j'utilise la règle:

-A INPUT -i ppp0 -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -j ACCEPT

pour remplacer... Avec ça, je crois que tes connexions sortantes marcheront
beaucoup mieux!


JM
Avatar
Pascal Hambourg
Jean-Michel Company a écrit :

Il me semble que ces états (ESTABLISHED,RELATED) ne sont pas encore
gérés par ip6tables.....



Le suivi de connexion IPv6 est disponible depuis le noyau Linux 2.6.15
(mais réellement utilisable à partir de 2.6.20) et iptables 1.3.5.

Personnellement, j'utilise la règle:

-A INPUT -i ppp0 -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -j ACCEPT

pour remplacer... Avec ça, je crois que tes connexions sortantes marcheront
beaucoup mieux!



Pas vraiment, puisque cette règle ne concerne que les paquets TCP alors
que le problème venait visiblement du blocage de paquets ICMPv6 utilisés
par le protocole Neighbor Discovery, l'équivalent d'ARP pour IPv6. Sur
ton interface PPP qui n'a pas la notion d'adresse MAC on n'a pas besoin
de Neighbor Discovery (ni d'ARP pour IPv4), aussi cette seule règle peut
suffire pour les connexions TCP sortantes... mais en aucun cas sur une
interface ethernet.
1 2