La Fibre
Datacenter et équipements réseaux => Routeurs => 
OpenWrt => Discussion démarrée par: basilix le 23 mars 2024 à 11:10:37
-
Bonjour !
Je n'arrive pas à comprendre plusieurs concepts (voir schéma en pièce-jointe).
Jool (traducteur NAT64) capture tous les paquets qu'il peut traduire. En fait, le problème c'est qu'aucun paquet valide ne peut être filtré par le mécanisme du pare-feu.
On mentionne dans la documentation en ligne (https://www.jool.mx/en/intro-jool.html#netfilter) que l'on peut exécuter Jool dans un espace de nommage réseau. De cette façon, il deviendrait ainsi possible de filtrer le flux réseau du traducteur.
En principe, une paire de périphériques Ethernet virtuels (veth1 et veth2) (man 4 veth) pourrait servir à établir une connexion entre l'espace de nommage courant (Main NS) et celui de Jool (Jool NS).
Sauf que je ne maîtrise pas bien le concept d'espace de nommage réseau ainsi que le pare-feu Linux « Netfilter ».
- Est-ce qu'on peut filtrer le trafic provenant du traducteur et arrivant sur l'interface veth1 ?
- Est-ce qu'on peut filtrer le trafic arrivant au traducteur depuis l'interface WAN (eth1) ?
- Est-ce qu'on peut filtrer le trafic provenant du traducteur vers l'interface LAN (eth0) ?
Note : Invoquer Jool dans un espace de nommage réseau engendre un double NAT (NAT64 + NAT44).
Cdlt, basilix
-
j'ai rien pigé mais en général les NAT et/ou le filtrage vient en "coupure" entre deux "bidules"
Là ton Jool a une seule patte.
-
@Fyr : Moi non plus ! ???
J'essaye de deviner en recoupant les informations et en mélangeant à mes modestes connaissances.
J'ai essayé d'intégrer conceptuellement ce qu'exposait Ondřej Caletka (https://ondřej.caletka.cz/dl/slidy/20231127-RIPE87-IPv6-mostly_on_OpenWRT.pdf) lors du RIPE 87 (vidéo (https://ripe87.ripe.net/archives/video/1136/)) et ce que j'ai pu trouver sur le sujet (essentiellement, des infos glanées sur le site Web NEXT.as (https://docs.netx.as/docs/l3/l3-nat64.html)).
Je ne sais pas si on peut vraiment parler de « pattes » avec les espaces de noms. On a deux piles réseaux internes au routeur. Jool s'exécute dans un autre espace de nom.
A network namespace is logically another copy of the network stack, with its own routes, firewall rules, and network devices.
On retrouve également ce concept d'espace de nom dans les conteneurs.
Le flux peut être acheminé de l'interface eth1 à l'interface eth0 (IP forwarding). Similairement, on peut sûrement acheminer le flux de eth0 à veth1 puis de veth1 à veth2 (périphériques Ethernet virtuels).
D'après ce que j'ai vu, il me semble que c'est du routage commun (assigner des préfixes et créer des routes statiques dans le routeur).
En schématisant :
WAN <--> LAN (trafic IP usuel) mais aussi,
WAN <--> JOOL (traduction IPv4 du serveur distant en IPv6) ou bien,
LAN <--> JOOL (traduction IPv6 du client local en IPv4).
-
Sur la doc du RIPE
"Stealing packets in the PREROUTING, injecting translated packets into POSTROUTING"
c'est là tes "deux pattes".
y a des conf ave ip netns
https://man7.org/linux/man-pages/man8/ip-netns.8.html
ce que tout le monde appelle un VRF avec leur propre forwarding information bases (FIBs) ??
Par exemple sii tu as un mikrotik tu accèdes aux règles PRE/POST dans la partie RAW des firewalls. Donc "en dessous/antérieurement" aux règles input/ouput/forward dans ton linux
https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks
-
Les BSD font deux tables, rentre les réseaux 4 et 6 dedans, et y a une commande pour la nat64
https://bsdrp.net/documentation/examples/nat64
Dans OPenSense y a ton jool qui s'appelle tayga (si je sujis bien...) et y a une conf, si ça t'inspire...
https://imgur.com/mTN1ype
https://docs.opnsense.org/manual/how-tos/tayga.html#
-
@Fyr :
C'est compliqué !
Je ne sais même pas si le schéma que j'ai adapté, dans mon premier post, en pièce-jointe, est correct. Je ne connais pas les concepts, à l'origine.
J'ai fais une approximation en me basant sur la configuration Ondřej Caletka et en essayant de suivre son propos (il a notamment affirmé que cela
engendrait un double NAT, du coup, on est plus dans le concept original de NAT64).
En outre, Jool n'est pas intégré nativement (https://marc.info/?l=netfilter-devel&m=158723432432044&w=2) au système Netfilter et sa conception reste assez particulière (dixit son développeur (https://github.com/NICMx/Jool/issues/397#issuecomment-1586258901)). En ce qui concerne
le filtrage des paquets, je suis aussi complètement perdu. Netfilter filtre les paquets mais peut également traduire les adresses (NAT et NAPT).
Le problème c'est que je ne sais par quel « chemin » passe les paquets. Jool ne faisant pas de filtrage en utilisant le plugin Netfilter Jool.
Tayga est un traducteur NAT64 sans état fonctionnant en mode utilisateur. Comme je n'ai qu'une seule adresse IPv4 publique, il faut passer par le NAT44.
Je suppose aussi que Tayga ne filtre pas les paquets. Néanmoins on change complètement le concept original de « traducteur sans état ».
J'aurais voulu filtrer les paquets via Nftables ou firewall4 (fw4) (surtout pas Iptables). C'est embêtant mais je crois que je vais devoir creuser du côté de Netfilter.
-
Je pense que j'ai une idée du principe sur le filtrage par le pare-feu. Mais à vérifier.
Il faudrait que je filtre de eth1 à veth1 en IPv4 (trafic WAN) et de eth0 à veth1 en IPv6 (trafic LAN).
-
J'aurais voulu filtrer les paquets
De mémoire, les paquets traités par Jool peuvent être filtrés en PREROUTING et POSTROUTING au niveau de la table MANGLE.
Ce n'est pas du tout fait pour ça, mais c'est à tester quand même ( :-X).
via Nftables ou firewall4 (fw4) (surtout pas Iptables). C'est embêtant mais je crois que je vais devoir creuser du côté de Netfilter.
Il y a un peu de confusion là. nftables/iptables utilisent tous les deux netfilter, qui est une "sous-couche".
fw4 d'openwrt est une surcouche pour nftables.
-
@ppn_sd:
Oui, nftables est un socle d'application (framework) basé sur Netfilter. Oui, fw4 est une interface basée sur nftables. Ce que je voulais dire c'est que je dois acquérir
des connaissances de base sur Netfilter pour mieux appréhender la pile réseau de Linux.
Non, je ne souhaite pas filtrer les paquets (https://github.com/NICMx/Jool/issues/41#issuecomment-156264186) avec la table "mangle" (terminologie iptables).
-
Juste par curiosité, que filtres-tu qui nécessite ce machinisme ?
-
@ppn_sd:
Je souhaite administrer mon réseau local en IPv6 uniquement. Le pare-feu du réseau local domestique doit filtrer le trafic passant par le traducteur IPv4/IPv6.
Cela dit, il me semble que c'est finalement le fonctionnement usuel de Netfilter, en étant apparié à Jool. Je ne fais que reprendre ce qui a été déjà fait, sauf que
je suis débutant dans le domaine.
Le traducteur (NAT64) permet en principe à un client local en IPv6 de se connecter à un serveur distant en IPv4. Évidemment, ce sera fait en remplacement de
la Livebox.
-
J'entends bien tout ça, mais que veux-tu filtrer exactement en sortie de Jool ?
-
@ppn_sd :
En sortie ? Rien.
Flux eth1 vers veth1 : trafic IPv4 du WAN vers Jool.
Flux eth0 vers veth1 : trafic IPv6 du LAN vers Jool.
-
Et tu filtres quoi là dedans ?
-
Surveiller les connexions et essayer de détecter (capter) celles qui sont suspectes. On marque la séparation entre deux zones.
C'est fait différemment (NAT64 + NAT44 dans le même routeur). Mais sur le principe, c'est pareil que pour le trafic usuel (séparation WAN / LAN).
-
Tant pis pour ma curiosité :).
N'hésite pas à poster les suites de commandes quand tu seras parvenu à tes fins.
-
@ppn_sd:
Je pourrais exposer comment mettre en œuvre Jool dans OpenWrt. Car on pourrait éventuellement améliorer son intégration.
Comme je l'ai déjà signifié, je pense qu'on est également dans une configuration standard au niveau du pare-feu.
HS
Normalement, le trafic du réseau local sera essentiellement en IPv6. Il faudrait que je sache quels services externes sont accessibles uniquement en IPv4.
Ainsi, j'espère pouvoir détecter les flux inhabituels pour éventuellement les bloquer. J'aurai vraisemblablement plusieurs niveaux de pare-feu. Mais je débute
et je ne sais pas encore quelle politique de filtrage appliquer suivant le pare-feu (routeur, station). Il faut penser la sécurité informatique dans son ensemble.
Certaines machines tournent encore sur MS Windows, d'autres sur GNU/Linux. Et certains appareils ne sont éventuellement pas renforcé e.g. l'imprimante.
Je ne préciserai pas la configuration de mon pare-feu en ligne (à quiconque). Avec les outils et techniques actuels, je pense que c'est trop dangereux. Par
exemple, les joueurs d'échecs professionnels étudient les ouvertures des parties de leur adversaire pour augmenter sensiblement leur chance de gagner.
Idem, en sécurité informatique. Il faut ralentir, de façon envisageable (rendre les choses difficiles), les personnes qui veillent sur les ouvertures et dans la
mesure du possible ne pas leur faciliter la mise. Je sais également qu'un pare-feu ne protège que partiellement. Mais je suis débutant et c'est une ligne de
défense parmi d'autres (sécurité en profondeur).
De façon générale, je fais aussi ces remarques car je prévois d'auto-héberger des services en ligne (les risques peuvent devenir accrus en étant branché
non stop) !
-
J'ai fait des essais d'installation de Jool dans OpenWrt sous GNS3 pour m'exercer. Cela fonctionne ! :)
-
config device
option name 'veth1'
option type 'veth'
option peer_name 'veth2'
option macaddr '2a:33:f4:07:ba:c4'
option peer_macaddr '36:5d:06:b4:4d:21'
config interface 'jool'
option device 'veth1'
option proto 'static'
option ip6addr 'fd00::1/64'
option ipaddr '192.168.200.1/30'
On peut définir une interface réseau virtuelle avec UCI mais c'est réalisé partiellement. Le périphérique Ethernet virtuel veth2 apparaît dans le même espace de noms réseau que veth1.
Sinon, on aurait pu définir les interfaces dans la configuration UCI network. La configuration des espaces de noms disparaît après un redémarrage du routeur. Par conséquent, il faudrait
idéalement créer un script pour refaire automatiquement la configuration à chaque amorçage.
Certains paramètres peuvent également être spécifiés dans le fichier de configuration de Jool '/etc/jool/jool-nat64.conf.json'.
#opkg update && opkg install kmod-veth ip-full kmod-jool-netfilter jool-tools-netfilter
ip netns add joolns
ip link add veth1 type veth peer name veth2 netns jools
ip link set dev veth1 up
ip addr add 192.168.200.1/30 dev veth1
ip addr add fd00::1/64 dev veth1
ip netns exec joolns ip link set dev lo up
ip netns exec joolns ip link set dev veth2 up
ip netns exec joolns ip addr add dev veth2 192.168.200.2/30
ip netns exec joolns ip addr add fd00::2/64 dev veth2
ip netns exec joolns ip route add default via 192.168.200.1
ip netns exec joolns modprobe jool
ip netns exec joolns jool instance add --netfilter --pool6 64:ff9b::/96
ip netns exec joolns jool global update lowest-ipv6-mtu 1500
ip netns exec joolns jool pool4 add 192.168.200.2 33000-65535 --tcp
ip netns exec joolns jool pool4 add 192.168.200.2 33000-65535 --udp
ip netns exec joolns jool pool4 add 192.168.200.2 33000-65535 --icmp
On peut aussi définir la route vers 64:ff9b::/96 avec la configuration UCI.
config route6 'nat64'
option interface 'jool'
option target '64:ff9b::/96'
option gateway 'fd00::2'
Ou en ligne de commande.
ip -6 route add 64:ff9b::/96 via fd00::2 dev veth1
Enfin, pour finir, ce qui m'a bloqué : configurer le pare-feu en ajoutant par exemple l'interface 'jool' dans la zone LAN du pare-feu.
uci add_list firewall.@zone[0].network='jool'
config zone
option name 'lan'
list network 'lan'
list network 'jool'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
-
J'utilise un préfixe local (ULA prefix) au site administratif (ou campus) pour définir l'adresse de veth2. Dans la démo, c'est bien une adresse locale au lien (link-local address) qui est employée.
Mais je n'en connais pas la raison car je ne saisis pas très bien le principe d'emploi des adresses lien-local.
C'est sûrement la table de routage.
-
La page Wiki OpenWrt sur Jool (https://openwrt.org/docs/guide-user/network/ipv6/nat64) a été complété récemment.
J'aurais bien voulu savoir si on pouvait lancer Jool dans un nouvel espace de nom réseau grâce à procd (https://openwrt.org/docs/guide-developer/procd-init-scripts#service_jails) ?