Routeur / pare-feu dans une VM (machine virtuelle)

Support Debian
#1

Bonjour,

J’essaye d’installer dans une VM (machine virtuelle) un routeur et un pare-feu. La VM c’est VirtualBox-non-ose.
Le système hôte Lenny, le système virtuel pfSense

Je rencontre des difficultés avec la partie réseau… Voici le schéma de l’installation :

Internet <----> eth0 (br0) <—> Debian <—> em0 (Machine virtuelle) em1 <—> Debian <—> (br1) eth1 <—> Intranet

em0 et em1 sont les noms des interfaces dans la VM.

J’ai configuré les interfaces de la VM en connexions par pont (sur les interfaces br0 et br1) avec des ip fixes.

Voici le /etc/network/interfaces de la machine hôte

[code]laurent@isalo:~$ cat /etc/network/interfaces

The loopback network interface

auto lo eth0 eth1

iface lo inet loopback

interface internet

   iface eth0 inet manual

Bridge sur eth0

   auto br0 
   iface br0 inet static
   address 41.188.26.122
   netmask 255.255.255.248
   gateway 41.188.26.121
   network 41.188.26.0

MTU 1492

   dns-nameservers 41.188.9.130 196.192.32.5
   post-up iptables-restore < /etc/iptables.up.rules
   bridge_ports eth0

interface private

   iface eth1 inet manual

Bridge sur eth1

   auto br1
   iface br1 inet static
   address 192.168.0.3
   netmask 255.255.255.0
   network 192.168.0.0
   dns-nameservers 192.168.0.3 41.188.9.130 196.192.32.5
   bridge_ports eth1

auto iface
iface iface inet manual[/code]

Et ça donne :

[code]laurent@isalo:~$ /sbin/ifconfig
br0 Link encap:Ethernet HWaddr 00:13:74:00:5c:38
inet adr:41.188.26.122 Bcast:41.188.26.127 Masque:255.255.255.248
adr inet6: fe80::213:74ff:fe00:5c38/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:0 (0.0 B) TX bytes:5903 (5.7 KiB)

br1 Link encap:Ethernet HWaddr 00:0e:2e:f2:46:6e
inet adr:192.168.0.3 Bcast:192.168.0.255 Masque:255.255.255.0
adr inet6: fe80::20e:2eff:fef2:466e/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:86 errors:0 dropped:0 overruns:0 frame:0
TX packets:68 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:13802 (13.4 KiB) TX bytes:10401 (10.1 KiB)

eth0 Link encap:Ethernet HWaddr 00:13:74:00:5c:38
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:3
collisions:0 lg file transmission:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Mémoire:dffc0000-e0000000

eth1 Link encap:Ethernet HWaddr 00:0e:2e:f2:46:6e
adr inet6: fe80::20e:2eff:fef2:466e/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1216 errors:0 dropped:0 overruns:0 frame:0
TX packets:967 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:122916 (120.0 KiB) TX bytes:143456 (140.0 KiB)
Interruption:17 Adresse de base:0xac00

lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:376 errors:0 dropped:0 overruns:0 frame:0
TX packets:376 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:37679 (36.7 KiB) TX bytes:37679 (36.7 KiB)[/code]

Mais… ça ne fonctionne pas. La VM a bien un accès Inernet, mais impossible de joindre la VM à partir d’une machine du réseau… Par contre la VM ping bien toutes les IP de mon Intranet.

Enfin bref… je suis un peu paumé (vous avez peut-être vu passer mon fil hier :mrgreen: )

Un peu d’aide pour m’éclaircir les idées serait la bienvenue :smiley: J’avoue en avoir plein le dos de chercher une solution… :frowning:

Edit : Et j’ai un petit “lockfile creation failed” qui s’affiche dans la console, que je n’avais pas avant…

#2

le routeur doit être ton problème
les routeurs ne laissent pas passer les pings dans la grande majorité des cas
de plus ton pare feu peu aussi bloquer les pings
moi perso je regarderais par la

#3

Bonjour,
C’est une bonne journée je vais pouvoir faire autre chose que me coltiner des problèmes :smiley:

Problème réglé pour le réseau.

La VM : connexion NAT sur eth0 (la connexion Internet) et connexion de pont sur br1 avec une IP fixe - différente de l’IP de la machine hôte.
Ça “ping” dans tous les sens, ça accède au net, au réseau interne… Les routes ont l’air bonnes !

[code]isalo:~# cat /etc/network/interfaces

The loopback network interface

auto lo eth0 eth1
iface lo inet loopback

interface internet

    iface eth0 inet static
    address 41.188.26.122 
    netmask 255.255.255.248
    gateway 41.188.26.121  
    network 41.188.26.0    
    broadcast 41.188.26.248

MTU 1492

    dns-nameservers 41.188.9.130 196.192.32.5
    post-up iptables-restore < /etc/iptables.up.rules

Bridge sur eth1

    auto br1
    iface br1 inet static
    address 192.168.0.3
    netmask 255.255.255.0
    network 192.168.0.0
    dns-nameservers 192.168.0.3 41.188.9.130 196.192.32.5
    bridge_ports eth1

auto iface
iface iface inet manual
[/code]

Maintenant… J’ai des questions sur la façon dont il faut que je fasse mon pare-feu sur le machine hôte (la Lenny).

La machine hôte n’est pas du tout protégée ? Comment faire mon pare-feu ? A-t-il un influence sur la VM ?

Comment autoriser eth0 vers la VM et filtrer eth0 vers la machine hôte ?

Merci d’avance pour vos pistes, remarques et pour votre intérêt ! :smt006

#4

Re,

Bon ça ne fonctionne plus…

Je crois que je me suis complètement “gouravé”…

Si j’ai compris les divers tutos que j’ai lus, un bridge relie deux interfaces (par exemple une réelle et une virtuelle).

Il faut donc que je crée d’abord une interface virtuelle (tap ou tun) et que je fasse un bridge entre eth et tap (ou tun).

C’est mieux ?

#5

oui
normalement en nat ça veut dire que ton virtualiseur travaille comme un routeur (il fait du nat qui l’eu cru ?) entre ta carte virtuel et physique
avec du bridge tu fait un pont entre le virtuel et le physique donc tu accède directement, ça permet que de l’extèrieur de ta machine on ne puisse pas faire la différence entre la machine virtuelle ou physique (ta machine virtuelle a presque le meme accès qu’une machine physique
et le reseau local ben tu devine

donc dans la logique il te faut du bridge est ce que sur ta machine virtuelle le pare feu et le routeur sont déjà installé et configuré ?

#6

[quote=“bobzer”]oui
normalement en nat ça veut dire que ton virtualiseur travaille comme un routeur (il fait du nat qui l’eu cru ?) entre ta carte virtuel et physique
avec du bridge tu fait un pont entre le virtuel et le physique donc tu accède directement, ça permet que de l’extèrieur de ta machine on ne puisse pas faire la différence entre la machine virtuelle ou physique (ta machine virtuelle a presque le meme accès qu’une machine physique
et le reseau local ben tu devine

donc dans la logique il te faut du bridge est ce que sur ta machine virtuelle le pare feu et le routeur sont déjà installé et configuré ?[/quote]

Merci de ta réponse.
C’est pas évident pour faire entrer ça dans ma petite tête… J’ai du mal à saisir la notion de bridge (pas dans l’absolu, car je comprend bien ce qu’est un pont… mais en pratique… quand je crée un bridge, c’est une interface aussi ?)
La VM est une pfsense (routeur/pare-feu/portail captif) elle est déjà fonctionnelle, puisque j’ai cru que c’était bon pendant quelques heures (et ça a bien fonctionné), jusqu’au redémarrage de ma Lenny :frowning:
Bref, je tente demain l’interface virtuelle et le pont, je verrais bien. Je n’ai pas trouvé de tuto adapté à ce que je souhaite (c’est souvent du Xen - ou du vmware - et la partie réseau est faite par des scripts et des commandes particulières à Xen ou vmware…). Il faut dire que Virtualbox c’est pas vraiment “geek” comme “virtualisation”…

Je galère mais j’y arriverais. Pour l’instant j’ai déplacé le problème en installant pfsense comme routeur sur une machine “physique” et c’est très efficace (et simple à installer/utiliser…) !

#7

[quote=“lol”]
j’ai déplacé le problème en installant pfsense comme routeur sur une machine “physique” et c’est très efficace (et simple à installer/utiliser…) ![/quote]
si tu as réussit a faire ça tu devrait réussir a faire le reste

#8

[quote=“bobzer”][quote=“lol”]
j’ai déplacé le problème en installant pfsense comme routeur sur une machine “physique” et c’est très efficace (et simple à installer/utiliser…) ![/quote]
si tu as réussit a faire ça tu devrait réussir a faire le reste[/quote]

Inch’Allah :wink:

#9

Bon,
J’ai réussi, mais pas comme je le souhaitais. Je ne suis pas satisfait d’avoir jeté l’éponge… :frowning:

Ce matin j’avais bien créé mes interfaces eth0 tap0 br0 eth1 tap1 et br1
Mais impossible de me servir de tap0 et tap1 dans VirtualBox. J’ai tout essayé… Alors que le réseau fonctionnait parfaitement dans la machine hôte, ce qui signifie que les deux bridges étaient fonctionnels.

Je me suis rabattu sur une solution plus simple. eth0 (sans IP) et eth1; VirtualBox configuré en connexion de pont sur ces deux interfaces. Ce n’est pas la solution “la plus élégante” mais ça fonctionne. J’ai perdu des dizaines d’heures avec ce truc à la c… :frowning:

Il faudrait peut-être que je regarde du côté de Qemu ou Vmware ?

#10

ben je sais pas mo perso je ne connais que vmware donc je peut pas trop t’aider

#11

Quelques observations et informations.

  1. Ton premier ifconfig montre que eth0 est UP mais pas RUNNING, avec 0 paquet émis et reçu, indiquant que l’interface n’est pas opérationnelle (câble débranché ?).

  2. Un pont entre N interfaces est équivalent à un switch virtuel à N+1 ports, dont un port (interne) est connecté à l’interface pont (br0) vue par le système, et les N autres ports (externes) sont les N interfaces pontées.

  3. Interactions entre pont et pare-feu : par défaut, les règles iptables de l’hôte s’appliquent aux trames ethernet contenant un paquet IP passant par un pont. Pour désactiver cela, il faut régler le sysctl net.bridge.bridge-nf-call-iptables à 0.

  4. Effectivement un pont regroupe au moins deux interfaces pour avoir un sens. Dans le cas d’une machine virtuelle, c’est généralement une interface physique (remplacée par le pont dans la configuration IP de l’hôte) et une interface TAP (interface virtuelle ethernet, et non une interface tunnel TUN qui n’est pas pontable car par de type ethernet) qui communique avec une interface ethernet de la machine virtuelle. Depuis le temps que je n’ai pas utilisé virtualbox je ne sais plus comment il faut faire, mais il me semble que j’avais créé (avec tunctl) et ponté les interfaces TAP a priori, puis indiqué à virtualbox d’utiliser ces interfaces TAP.

#12

Salut,

Merci pour ces précieuses précisions, certains “détails” m’avaient échappés par manque de connaissance. Mais ce n’est pas évident, je n’ai aucune formation en la matière (seulement ma petite expérience et mes tâtonnements), et trouver les infos sur le net relève de l’exploit…

Je suis un acharné, je ne laisse pas tomber aussi facilement. Mon sommeil est troublé par ces histoires depuis une semaine. Je suis étonné de ne pas y être parvenu alors que tout semblait bon.

Je ne savais pas non plus pour ta remarque n°3, je vais regarder ça, c’est peut-être la cause de mes problèmes avec Virtualbox. Après tout je suis certain que le bridge fonctionnait (au moins sur l’hôte) donc il n’y a pas de raison que sur la VM cela ne fonctionne pas, à moins que les règles iptables de l’hôte (ce que je n’ai pas vérifié) jouent les troubles fêtes.

Merci pour ta réponse, et content de te revoir ici (ça fait un moment…) ! :smiley:

#13

D’expérience, le filtrage par iptables par défaut des trames pontées est un “détail” très mal connu. Cette fonctionnalité (bridge-netfilter ou bridge-nf en abrégé) est appréciable pour réaliser un pont filtrant, mais je ne comprends pas qu’elle soit activée par défaut. Si tu veux faire encore plus de cauchemars, tu peux étudier le diagramme de cheminement des paquets dans l’enchevêtrement netfilter/iptables/ebtables qui est maintenant disponible (joie) dans l’article en français de Wikipédia consacré à iptables.

#14

Il faut être sacrément concentré pour pondre des truc comme ça !
Pour le commun (moi), à ce niveau là, même les cauchemars sont agréables…

Le schéma est “mortel” pour un non initié… Pour y voir plus clair je regardais ça xkr47.outerspace.dyndns.org/netf … cket_flow/ mais c’est du pipi de chat à côté…

Tu m’oblige à replonger… Je dois aimer ça !

#15

Ce schéma est l’oeuvre d’un contributeur particulièrement actif du projet netfilter, je pense qu’il maîtrise son sujet. En fait il y a - heureusement - une certaine logique dans l’arrangement des chaînes, mais j’ai eu quand même passé du temps à mettre des règles LOG dans toutes les tables/chaînes, à envoyer des paquets dans tous les sens et à éplucher les résultats pour bien comprendre comment ça marche, d’autant plus que des versions antérieures du document étaient erronées, et le comportement du noyau a changé dans le temps. Le schéma que tu mentionnes ne fait apparaître que le cheminement des paquets IP routés, il lui manque le cheminement des paquets ethernet pontés et donc il ne pouvait t’apporter aucune aide pour comprendre l’influence d’iptables sur ces derniers.

#16

Bof…
Je n’arrive pas à grand chose…

[code] auto eth0
iface eth0 inet manual
post-up iptables-restore < /etc/iptables.up.rules

    auto tap0
    iface tap0 inet manual
    tunctl_user laurent

    auto br0
    iface br0 inet static
    address 41.188.26.122
    netmask 255.255.255.248
    gateway 41.188.26.121
    network 41.188.26.0
    broadcast 41.188.26.248
    post-up chmod ugo+rw /dev/net/tun
    bridge-ports eth0 tap0
    bridge-ageing 7200
    bridge-fd 0

    auto eth1
    iface eth1 inet manual

    auto tap1
    iface tap1 inet manual
    tunctl_user laurent

    auto br1
    iface br1 inet dhcp
    post-up chmod ugo+rw /dev/net/tun
    bridge-ports eth1 tap1
    bridge-ageing 7200
    bridge-fd 0

[/code]

Qui me donne après un /etc/init.d/networking restart ceci :

[code]br0 Link encap:Ethernet HWaddr 00:13:74:00:5c:38
inet adr:41.188.26.122 Bcast:41.188.26.248 Masque:255.255.255.248
adr inet6: fe80::213:74ff:fe00:5c38/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:81 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:0 (0.0 B) TX bytes:8372 (8.1 KiB)

br1 Link encap:Ethernet HWaddr 00:0e:2e:f2:46:6e
inet adr:192.168.0.3 Bcast:192.168.0.255 Masque:255.255.255.0
adr inet6: fe80::20e:2eff:fef2:466e/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1156 errors:0 dropped:0 overruns:0 frame:0
TX packets:1848 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:115809 (113.0 KiB) TX bytes:2171985 (2.0 MiB)

eth0 Link encap:Ethernet HWaddr 00:13:74:00:5c:38
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:2
collisions:0 lg file transmission:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Mémoire:dffc0000-e0000000

eth1 Link encap:Ethernet HWaddr 00:0e:2e:f2:46:6e
adr inet6: fe80::20e:2eff:fef2:466e/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:217108 errors:0 dropped:0 overruns:0 frame:0
TX packets:380775 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:20072600 (19.1 MiB) TX bytes:516459205 (492.5 MiB)
Interruption:17 Adresse de base:0xec00

lo Link encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:115907 errors:0 dropped:0 overruns:0 frame:0
TX packets:115907 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:497982461 (474.9 MiB) TX bytes:497982461 (474.9 MiB)

tap0 Link encap:Ethernet HWaddr 02:61:cc:02:5d:16
adr inet6: fe80::61:ccff:fe02:5d16/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:298 overruns:0 carrier:0
collisions:0 lg file transmission:500
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

tap1 Link encap:Ethernet HWaddr 2e:80:a5:68:1e:55
adr inet6: fe80::2c80:a5ff:fe68:1e55/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:1131 overruns:0 carrier:0
collisions:0 lg file transmission:500
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)[/code]

Les deux bridges sont bien accessibles par l’hôte et mon réseau. Pas de mouvement sur eth0 le câble réseau n’est pas branché.

Bien sur VirtualBox n’arrive pas à communiquer avec tap1…

J’ai fait quelques essais…

J’ai ajouté ceci à sysctl.conf :

net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

Pas mieux…

J’ai ensuite fait ceci :

ip addr add 192.168.0.69/24 dev tap1
ip link set tap1 up

sysctl net.ipv4.ip_forward=1

route add -host 192.168.0.70 dev tap1 (IP que j’ai donné à l’interface dans la VM)

iptables --flush
iptables -t nat --flush
iptables -t nat -A POSTROUTING --out-interface eth1 -j MASQUERADE
iptables -A FORWARD --in-interface tap1 -j ACCEPT

tap1 est accéssible depuis l’hôte et le réseau.
Mais VirtualBox n’arrive toujours pas à passer au travers de l’interface (tap1)

Voici la configuration réseau de virtualbox :

Adapter 1: Intel PRO/1000 MT Desktop (Internal network, ‘tap0’)
Adapter 2: Intel PRO/1000 MT Desktop (Internal network, ‘tap1’)

J’ai redémarré la machine plusieurs fois pour être sur que les modification soient prises en compte…
J’avoue être un peu las… :mrgreen:
J’espère que c’est un truc évident que je ne vois pas… :question:

Edit : désolé pour le pavé…

#17

Encore moi,

Juste l’info pour ceux que ça intéressent.

J’ai lourdé VirtulalBox et virtualbox pour installer qemu.

Et bien ça fonctionne parfaitement… Il me crée tout seul les tap (il suffit que j’ajoute les bridges) et ça roule.

Réseau dans tous les sens…
Je pense que virtualbox n’est pas le meilleur instrument pour ce genre de montage… J’aurais du m’en douter dés le début… :blush:

#18

:smiley: j’ai jamais vraiment aimé virtualbox parceque je prefere de loin vmware
et ben maintenant j’ai une bonne raison lol