La Fibre
Datacenter et équipements réseaux => Routeurs => 
OpenWrt => Discussion démarrée par: basilix le 29 mars 2024 à 14:06:24
-
Bonjour !
Dans mon routeur OpenWrt, je ne parviens pas à établir une connexion d'un espace de nom réseau vers l'espace de nom par défaut.
root@OpenWrt:~# ip netns add joolns
root@OpenWrt:~# ip link add veth1 type veth peer name veth2 netns joolns
root@OpenWrt:~# ip link set dev veth1 up
root@OpenWrt:~# ip addr add 192.168.200.1/30 dev veth1
root@OpenWrt:~# ip route | grep veth1
192.168.200.0/30 dev veth1 proto kernel scope link src 192.168.200.1
root@OpenWrt:~# ping -c3 192.168.200.2
PING 192.168.200.2 (192.168.200.2): 56 data bytes
64 bytes from 192.168.200.2: seq=0 ttl=64 time=0.170 ms
64 bytes from 192.168.200.2: seq=1 ttl=64 time=0.098 ms
64 bytes from 192.168.200.2: seq=2 ttl=64 time=0.066 ms
--- 192.168.200.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.066/0.111/0.170 ms
root@OpenWrt:~# ip netns exec joolns ip link set dev lo up
root@OpenWrt:~# ip netns exec joolns ip link set dev veth2 up
root@OpenWrt:~# ip netns exec joolns ip addr add 192.168.200.2/30 dev veth2
root@OpenWrt:~# ip netns exec joolns exec sh
root@OpenWrt:~# ip route
192.168.200.0/30 dev veth2 proto kernel scope link src 192.168.200.2
root@OpenWrt:~# ping -c3 192.168.200.1
PING 192.168.200.1 (192.168.200.1): 56 data bytes
^C
--- 192.168.200.1 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
root@OpenWrt:~# exit
root@OpenWrt:~#
Cela fonctionne dans ma station de travail.
Quelqu'un pourrait-il m'aider ?
Cdlt, basilix
-
Qu'entends tu par namespace par défaut ?
L'utilisation d'un namespace avec Jool sert à faire du 464XLAT. Si c'est le cas, pourquoi vouloir le faire au niveau d'un routeur ?
-
@ppn_sd:
Non, c'est du NAT64. L'idée est de placer Jool dans un espace de nom séparé. Ainsi, on peut filtrer les paquets avec le pare-feu dans l'espace de nom initial.
Chaque espace de noms dispose de son propre pare-feu. Les paquets ne peuvent plus être filtrés avec le module noyau Jool Netfilter car ceux-ci ne passent
plus par le crochet forward (a.k.a Netfilter hook) dédié au filtrage.
-
@ppn_sd:
Deux conférences sur le sujet par le même orateur (NAT64 vs. CLAT+PLAT (464XLAT)).
- Ondřej Caletka - IPv6-mostly on OpenWRT (RIPE 87) (https://ripe87.ripe.net/archives/video/1136/)
- Ondřej Caletka - Improving IPv6-only experience on Linux (FOSDEM 2024) (https://fosdem.org/2024/schedule/event/fosdem-2024-1798-improving-ipv6-only-experience-on-linux/)
Sur GNU/Linux et MS Windows on a pas de CLAT nativement, contrairement à Google Android et Apple Mac OS (diapo. p. 5 (https://fosdem.org/2024/events/attachments/fosdem-2024-1798-improving-ipv6-only-experience-on-linux/slides/22113/FOSDEM2024-Improving_IPv6-only_experience_on_Li_DXG1q8n.pdf)).
-
@ppn_sd:
Non, c'est du NAT64. L'idée est de placer Jool dans un espace de nom séparé. Ainsi, on peut filtrer les paquets avec le pare-feu dans l'espace de nom initial.
Chaque espace de noms dispose de son propre pare-feu. Les paquets ne peuvent plus être filtrés avec le module noyau Jool Netfilter car ceux-ci ne passent
plus par le crochet forward (a.k.a Netfilter hook) dédié au filtrage.
OK. J'ai tilté après que cela avait un lien avec l'autre topic.
https://lafibre.info/openwrt/comment-filtrer-le-flux-traduit-par-le-nat64-jool/ (https://lafibre.info/openwrt/comment-filtrer-le-flux-traduit-par-le-nat64-jool/)
-
@ppn_sd: Oui, c'est le même sujet.
Il se pourrait que le ping soit filtré par une règle dans le pare-feu de mon routeur OpenWrt.
Il faudrait que je vérifie, cela me paraît plausible.
-
Le problème est effectivement engendré par le pare-feu du routeur.