Bonjour amis débianistes!
Attention pavé!
Débutant sur debian/ubuntu (moins d’un an), je m’intéresse depuis peu au fonctionnement réseau/pare-feu, etc. Mais plus je lis sur le sujet et plus je pratique, moins j’ai l’impression de comprendre…
J’essaie d’utiliser des règles iptables pour me familiariser avec cet outil, et j’essaie de comprendre ce qu’il se passe avant d’aller plus loin. Etant fan de virtualisation, mon but est d’avoir une VM debian qui sert de “gateway” (“static networking”, pas de serveur dhcp) pour les autres VM debian clientes qui se connectent dessus. J’y suis arrivé après de nombreux essais, mais de nombreuses questions restent en suspens, surtout en ce qui concerne la gestion des résolutions DNS, gros mystère pour moi. J’espère que des spécialistes pourront m’aider à comprendre ce qui se trame “sous le capot”. Je précise que tout se passe sous VirtualBox, n’étant pas assez calé pour le moment pour tenter KVM…
Sans plus attendre, voici ma configuration actuelle:
1. VM debian 9, “gateway” (vm1):
Cette VM sert de “gateway” aux autres VM s’y connectant et “forwarde” leur traffic sur internet.
Cette VM est reliée à deux interfaces dans le gestionnaire de VirtualBox:
-
la première interface est “NAT”, le NAT virtuel par défaut créé par VirtualBox qui communique directement avec le host. Elle correspond à l’interface
enp0s3dans la vm1. -
la deuxième interface est “intnet” (le nom n’a aucune importance), un “internal network” qui sert à relier des machines entre elles sur un réseau virtuel privé qui n’est connecté ni au host, ni à l’internet public. Cette interface correspond à l’interface
enp0s8dans la vm1.
Dans la vm1, j’ai configuré ces interfaces de la manières suivante (contenu de /etc/network/interfaces):
allow-hotplug enp0s3
iface enp0s3 inet dhcp
allow-hotplug enp0s8
iface enp0s8 inet static
address 192.168.42.10
netmask 255.255.192.0
Comme on le voit, l’interface connectée au NAT virtuel obtient son IP automatiquement par le dhcp virtuel de VirtualBox. Elle est donc connectée à internet. La deuxième interface enp0s8 obtient l’adresse statique 192.168.42.10 que je lui ai attribuée dans /etc/network/interfaces. C’est un choix arbitraire, j’aurais pu prendre n’importe quelle autre adresse IP privée. Voici ce que renvoie ifconfig:
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.2.15 netmask 255.255.255.0 broadcast 10.0.2.255
ether 08:00:27:c8:c2:9f txqueuelen 1000 (Ethernet)
RX packets 16369 bytes 7812753 (7.4 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 11244 bytes 2025946 (1.9 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp0s8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.42.10 netmask 255.255.192.0 broadcast 192.168.63.255
ether 08:00:27:ee:89:b0 txqueuelen 1000 (Ethernet)
RX packets 6985 bytes 1206798 (1.1 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 7157 bytes 6129776 (5.8 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
On constate que par défaut, enp0s3 se voit attribuer l’IP 10.0.2.15 par le NAT virtuel de VirtualBox.
Le contenu de /etc/resolv.conf est:
domain home
search home
nameserver 10.0.2.3
Là aussi, généré automatiquement par VirtualBox.
Je précise que j’ai désactivé le support IPV6 sur les deux machines virtuelles et qu’elles n’ont pas de network-manager. Tout se passe avec /etc/network/interfaces.
2. VM debian 9 “client” (vm2)
Cette VM n’a qu’une interface réseau, enp0s3, uniquement connectée au réseau interne “intnet”. Par défaut, elle n’a donc pas accès à internet, seulement à ce réseau virtuel. En l’état, elle peut “pinger” la gateway ou s’y connecter en ssh, ainsi qu’à toute autre machine partageant ce réseau interne virtuel, mais ne peut pas communiquer avec le “vrai” internet externe. Voici le contenu de son /etc/network/interfaces:
auto lo
iface lo inet loopback
allow-hotplug enp0s3
iface enp0s3 inet static
address 192.168.42.11
gateway 192.168.42.10
netmask 255.255.192.0
tandis que ifconfig retourne:
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.42.11 netmask 255.255.192.0 broadcast 192.168.63.255
ether 08:00:27:9a:84:a1 txqueuelen 1000 (Ethernet)
RX packets 8238 bytes 6430199 (6.1 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 8514 bytes 1768757 (1.6 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1 (Local Loopback)
RX packets 108 bytes 6727 (6.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 108 bytes 6727 (6.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Concernant son /etc/resolv.conf ça se corse… Par défaut, le contenu est le même que pour une machine virtuelle sous NAT VirtualBox: 10.0.2.3. En effet, la machine a été installée normalement avec le NAT de VirtualBox, j’ai modifié l’interface après. Je n’ai donc pas touché à ce fichier, car je partais du principe que ason contenu n’avait pas d’importance et que la résolution DNS serait de toute façon opérée dans la vm2 “gateway” (ce n’est apparememnt pas tout à fait le cas, et c’est d’ailleurs l’objet de ma question, on y reviendra plus tard):
domain home
search home
nameserver 10.0.2.3
3. IP forwarding et règles iptables sur la “gateway” (vm1)
Pour permettre à la vm2 de communiquer avec internet, j’ai activé l’ip forwarding sur la vm1 (en ajoutant net.ipv4.ip_forward=1 dans /etc/sysctl.conf)
et entré les règles iptables suivantes (je rappelle que je suis en “static networking”, pas de serveur dhcp sur la vm1):
iptables -t nat -A POSTROUTING -o enp0s3 -j MASQUERADE
iptables -A FORWARD -i enp0s3 -o enp0s8 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i enp0s8 -o enp0s3 -j ACCEPT
Depuis la vm2, je peux maintenant “pinger” des adresses ip externes. Mais curieusement, la vm1 ne peut pas résoudre de noms… Un “curl google.fr” renvoie systématiquement curl: (6) Could not resolve host: google.fr Pour permettre la résolution de noms, j’ajoute encore ces deux règles sur la “gateway” qui d’après ce que j’ai compris redirigent le traffic DNS de la vm2 sur le serveur DNS de la vm1 (par défaut avec le NAT de VirtualBox: 10.0.2.3):
iptables -t nat -A PREROUTING -i enp0s8 -p udp --dport 53 -j DNAT --to-destination 10.0.2.3
iptables -t nat -A PREROUTING -i enp0s8 -p tcp --dport 53 -j DNAT --to-destination 10.0.2.3
A présent, je peux accéder normalement à internet depuis la vm1.
4. Questions
Tout fonctionne donc me direz-vous (si vous êtes encore là!), mais alors:
-
Pourquoi, si je vide le fichier
/etc/resolv.confsur la vm2, ou remplace10.0.2.3par une adresse bidon, la vm2 ne peut plus résoudre aucun nom? La résolution DNS étant censée être faite par la vm1 “gateway”, pourquoi la vm2 “cliente” “bloque” lorsque son fichier/etc/resolv.confest vide ou comprend une adresse invalide? Pourquoi la vm2 cherche-t-elle absolument à résoudre les noms? -
Pourquoi l’entrée
10.0.2.3dans le fichier/etc/resolv.confest-elle considérée comme correcte par la vm2, alors qu’elle n’a pas accès à ce réseau virtuel (si je “pinge”10.0.2.3je n’obtiens rien), son interface étant uniquement un réseau interne avec comme ip statique 192.168.42.11? -
Y a-t-il un moyen d’empêcher la vm2 cliente de résoudre les noms et de lui faire comprendre qu’elle doit forwarder cette tâche à la gateway (vm1), comme le reste de son traffic?
-
D’une manière générale, pourquoi le traffic DNS a-t-il besoin d’une règle à part dans les règles iptables de la “gateway”? Qu’a-t-il de spécial pour cela? Pourquoi n’est-il pas forwardé avec le reste du traffic?
-
Mes règles iptables pour le traffic DNS sont-elles correctes?
Je vous assure avoir bien googlé tout ça, en français comme en anglais, mais je n’ai pas réussi à trouver de réponses satisfaisantes. Je suis preneur de toutes explications, je suis encore très débutant en la matière et certaines choses sont bien confuses…
Merci d’avance!
