Réseau : garder son IP sans être relié à un réseau

Support Debian
#1

Bonjour à tous,

Je suis passé dernièrement sur Jessie pour voir un peu (entre autre) le fameux systemd et je me suis rendu compte d’un souci “un peu” particulier !

Sous wheezy, on peut activer une interface réseau sans pour autant être relié (de quelque façon que ce soit) à un réseau.
C’est très pratique par exemple pour atteindre en ssh/scp et Cie une machine virtuelle installée sur un portable.

Sous jessie, ce n’est plus possible : dès lors que l’on se déconnecte du réseau (qu’on débranche le câble, quoi) l’interface reste up mais n’a plus d’IP d’attribuée !
Du coup, impossible de joindre ma MV par le réseau… :017

=> Un sale coup de NetworkManager ? systemd ?? (ça fait pareil sur une Fedora, pour info)
Quelqu’un aurait une idée d’où ça viendrait et comment y remédier, svp ?

Merci d’avance,
Eric

#2

J’avance doucement dans mon histoire car j’arrive à “retrouver” mon IP en la passant en paramètre lorsque j’active mon interface réseau : (câble débranché)

# ifconfig eth0 192.168.x.y upmais je ne ping toujours pas ma MV ! :cry:

Personne pour m’aider un peu, svp ?

#3

Ton problème ne viendrait-il pas du fait que tu configures ton IP sur l’interface eth0 ? Dans ce cas, le ping essaie de sortir sur cette interface… Essaie d’utiliser plutôt l’interface lo. Mais changer l’adresse de lo de localhost vers autre chose me paraît un peu bizarre.

#4

Merci pour ta réponse Dunatotatos.

Alors j’ai fait quelques manips avec une config de test : (câble réseau débranché)

[ul]Host
eth0 = 192.168.1.2/24 (gw = 192.168.1.1)
lo = 127.0.0.1[/ul]

et

[ul]MV
eth0 = 192.168.1.3/24 (gw = 192.168.1.1)
lo = 127.0.0.1[/ul]

Si j’attribue l’IP 192.168.1.2 à l’interface lo du host :root@host:~# ifconfig lo 192.168.1.2 upj’arrive à pinguer ma MV.
Par contre, de la MV je ne ping pas le host.

J’ai fait ensuite la même manip sur la MV :root@mv:~# ifconfig lo 192.168.1.3 upet maintenant tout le monde à priori se ping.

Sauf que, si je tente une connexion ssh du host vers la MV ça ne fonctionne pas :root@host:~# ssh -vvv user@192.168.1.3 OpenSSH_6.4, OpenSSL 1.0.1e-fips 11 Feb 2013 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 51: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.1.3 [192.168.1.3] port 22. debug1: connect to address 192.168.1.3 port 22: Connection refused ssh: connect to host 192.168.1.3 port 22: Connection refused(pour info, en config normale et câble branché, la connexion ssh fonctionne parfaitement)

:cry:

#5

En fait, c’est bizarre qu’en attribuant une IP à lo sur ton host et à eth0 sur ta VM que le ping ne se fasse que dans un sens.
Ta deuxième tentative en configurant une adresse sur les deux interfaces lo est forcément vouée à l’échec. Ta VM pense devoir passer par son interface eth0 pour contacter quelqu’un d’autre. Donc configurer lo en autre chose que 127.0.0.1 me semble inutile (et encore une fois bizarre…)

Pour pouvoir faire des tests, peux-tu m dire quelle gestionnaire de VM tu utilises ? Je veux bien aussi des infos supplémentaires sur la configuration du réseau de ta VM : comment le gestionnaire virtualise-t-il le réseau ? Pont, réseau local, routeur, … ?

#6

Ah c’est cool de bien vouloir prendre du temps pour m’aider : merci Dunatotatos !

J’utilise VirtualBox v4.3.24 installé actuellement sur une Fedora 20. (donc systemd + NetworkManager)
Mais le pb est exactement le même sur une Debian Wheezy (donc SysV + NetworkManager ou networking service) ou sur une Jessie. (donc sysmtemd + NetworManager ou networking service)

Ma VM est une Wheezy 7.8 configurée en accès par pont. (si je la configure en NAT, le réseau ne fonctionne pas du tout : je ne peux ni pinguer une autre VM, ni surfer)

Sinon, j’ai remarqué une chose avec ethtool sur l’interface du host : quand je débranche le câble, “Link detected” passe de yes à no. (ce qui est logique)
Est-ce qu’il n’y aurait pas un moyen, soit de bypasser cette détection, soit à l’aide d’un utilitaire ou d’une config, de forcer son état ?

#7

Si tu n’as pas d’équipement branché sur ton port physique (eth0 sur ton hôte), il semble normal que le mode Bridge ne fonctionne pas. Ton hôte sert de pont vers un routeur … qui n’est pas joignable. Au passage, le mode NAT ne fonctionne pas non plus.

Dans ton cas, configure le réseau en “réseau privé hôte”. Sachant qu’il faut configurer une interface virtuelle, je te laisse lire un tuto mieux fait que ce que je pourrais expliquer : http://www.it-connect.fr/gestion-des-reseaux-host-only-sous-virtualbox/

Cette méthode est beaucoup plus propre que tout ce que tu pourrais faire autrement. Je pense par exemple à une solution à base de routes modifiées, mais c’est dégueu.

Bon courage :slightly_smiling:

#8

Ça y est : ça fonctionne ! (non sans mal, par contre)
Merci Dunatotatos pour ta précieuse aide ! :clap:

J’ai suivi tes conseils et consulté le tuto que tu m’as indiqué. (je ne connaissais pas du tout ce type de config réseau sur VirtualBox, ou autre hyperviseur)
J’ai donc ajouté un réseau privé sur mon host et configuré mes VM en “Réseau privé hôte” et testé tout ça… malheureusement, configuré de cette façon ça ne fonctionne toujours pas !

En fait, il faut obligatoirement faire 2 manips sur le host pour que tout le monde puisse se pinguer et surtout que ssh fonctionne :

1°) activer l’interface réseau du host : (logique)ifconfig eth0 192.168.1.2 up
2°) effacer la route qui s’est crée lors de la précédente manip : route del -net 192.168.1.0 netmask 255.255.255.0 dev eth0car c’est la même route que celle crée automatiquement par l’interface virtuelle vboxnet0 de VirtualBox, mais surtout elle a la même métrique ! (sinon le réseau est hyper lent !)

Et là maintenant, tout fonctionne ! :033

Pour revenir en config normale (et donc pouvoir utiliser de nouveau Internet à partir du host) il faut juste effacer la route vboxnet0. (la route vers eth0 doit normalement se recréer dès apparition du lien avec la passerelle)

Encore merci pour ton aide Dunatotatos !
A+
Eric

#9

Quel immonde bidouillage. Tu as deux interfaces distinctes reliées à deux réseaux distincts (le virtuel et le physique) qui devraient avoir des sous-réseaux IP distincts : 192.168.1.0/24 sur le physique, et autre chose (par exemple 192.168.2.0/24) sur le virtuel.

#10

Merci Pascal, tu m’ôtes les mots de la bouche ^^

S’il n’y a pas de câble branché sur eth0, il n’y a aucune raison pour que cette interface soit “up”, et surtout pas avec la même IP que ton interface virtuelle.

#11

Je ne comprends pas les deux dernières interventions.

Jusqu’ici ça n’a choqué personne que les interfaces physique et virtuelle soient sur le même réseau :[quote=“Eric75”] Host
eth0 = 192.168.1.2/24 (gw = 192.168.1.1)
lo = 127.0.0.1

et

MV
eth0 = 192.168.1.3/24 (gw = 192.168.1.1)
lo = 127.0.0.1[/quote]et maintenant, c'est devenu une hérésie.  <img src="/uploads/default/original/1X/0287f377b0e103e172422ffbbe8c639fd3e12c9e.gif" width="15" height="15" alt=":119" title="vertige"/>

Pouvez-vous m’expliquer pourquoi il ne faut surtout pas faire ça, svp ?

Ok, je peux modifier le réseau virtuel et le positionner comme le propose PascalHambourg, pas de souci.
Par contre, comment je fais maintenant pour relier ces deux réseaux ?
Il faut bien un routeur entre les deux, non ? (ou alors il y a quelque chose que j’ai vraiment pas compris)

#12

Ce n’est pas une hérésie, juste une magouille pas très propre ^^
Je n’ai rien dit avant parce-que tu cherchais à résoudre ton problème via des magouilles, justement. Mais dans le tuto, je ne crois pas que des instructions soient données dans ce sens.

Parce-que si aucune câble n’est branché sur l’interface eth0, il n’y a aucun moyen ni d’envoyer des paquets sur cette interface ni d’en recevoir, et donc aucune raison de la configurer en “up”.

J’imagine que ne pas mettre eth0 en “up” et se contenter de l’interface vboxnet doit être suffisant pour faire communiquer ton hôte et ton invité (non testé). C’est plus ou moins ce que tu fais en supprimant la route associée à eth0 : plus aucun paquet n’est envoyé sur cette interface. Par contre, la route créée par VirtualBox envoie tous les paquets concernés sur l’interface vboxnet. Ça revient à ne configurer que cette dernière interface (en gros !).

#13

Désolé de ne répondre que maintenant mais je n’avais pas mon portable sous la main.

[quote=“Dunatotatos”]J’imagine que ne pas mettre eth0 en “up” et se contenter de l’interface vboxnet doit être suffisant pour faire communiquer ton hôte et ton invité (non testé).[/quote]Oui et non.

Oui, parce qu’en configurant comme vous m’avez tous les deux conseillé, j’arrive à me connecter en ssh sur ma machine virtuelle depuis l’hôte.
Non, parce que depuis la MV je n’arrive pas à pinguer le host.

De plus, lorsque je rebranche le câble LAN, mon host continue de pouvoir se connecter en ssh sur la MV (et peut surfer, bien-sur) mais la mv n’a toujours pas accès au réseau de l’hôte et ne peut donc toujours pas surfer. (pour des màj par ex)
Or, si j’ai bien compris ce qui est expliqué dans le lien que tu m’as fourni Dunatotatos, ça devrait pourtant être possible avec un réseau “Host-only” :[quote]Les réseaux de types “Host-only” sont un de ces type de réseaux, ils permettent une communication entre les machines virtuelles et leurs hôtes par l’intermédiaire de cette carte et permettent également aux machines virtuelles connectées sur une même carte réseaux “Host-Only” de communiquer entre elles.[/quote]Si, depuis la MV je pouvais pinguer le réseau hôte, j’aurais accès à ma passerelle et donc je pourrais surfer et faire mes màj…

#14

[quote=“Eric75”]Oui, parce qu’en configurant comme vous m’avez tous les deux conseillé, j’arrive à me connecter en ssh sur ma machine virtuelle depuis l’hôte.
Non, parce que depuis la MV je n’arrive pas à pinguer le host.[/quote]

L’établissement d’une connexion SSH nécessite l’envoi de paquets dans les deux sens. Donc si SSH fonctionne, le ping devrait passer.
Après, il semblerait qu’il y ait des sortes de “routes automatiques” pour les connexions en statut “ESTABLISHED”. Du coup, ce sont certainement les routes au sein de ton OS invité qui ne sont pas bonnes. Tu peux nous donner le résultat de la commande “route -n” dans ton invité ?

Exactement. Ta machine hôte sert de passerelle, en fait.

#15

[quote=“Dunatotatos”]Donc si SSH fonctionne, le ping devrait passer.[/quote]C’est ce que je pensais aussi mais malheureusement…

A partir de la MV :

root@debian1:~# route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 0.0.0.0 192.168.2.254 0.0.0.0 UG 0 0 0 eth0 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0Ce que je déduis de ce résultat, c’est qu’il n’existe aucune route vers le réseau 192.168.1.0.
D’où mon ping qui ne fonctionne pas.
Et l’ajout d’une route vers ce dernier (je sais pas si c’est propre de faire ça, mais j’ai voulu essayer) ne résoud pas le pb : je ping uniquement le host et pas la gateway.

Pour info sur le système hôte :user@host:~$ route -n Table de routage IP du noyau Destination Passerelle Genmask Indic Metric Ref Use Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 1024 0 0 p3p1 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 p3p1 192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 vboxnet0

#16

Elle vient d’où, cette adresse de passerelle 192.168.2.254 ?

#17

C’est l’adresse IP de la carte réseau “Host-Only” (vboxnet0) de l’hôte. (je me suis basé sur les explications du lien donné par Dunatotatos)

#18

Que donne le ping, ssh… depuis la MV vers cette adresse ? Je ne veux pas de “ça marche pas” mais la sortie exacte.

#19

Voici les différents résultats :

  • ping MV -> passerelle vboxnet0 :

root@debian1:~# ping 192.168.2.254 PING 192.168.2.254 (192.168.2.254) 56(84) bytes of data. 64 bytes from 192.168.2.254: icmp_req=1 ttl=64 time=0.079 ms 64 bytes from 192.168.2.254: icmp_req=2 ttl=64 time=0.123 ms 64 bytes from 192.168.2.254: icmp_req=3 ttl=64 time=0.122 ms 64 bytes from 192.168.2.254: icmp_req=4 ttl=64 time=0.116 ms 64 bytes from 192.168.2.254: icmp_req=5 ttl=64 time=0.117 ms ^C --- 192.168.2.254 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 3999ms rtt min/avg/max/mdev = 0.079/0.111/0.123/0.018 ms

  • ssh MV -> passerelle vboxnet0 : (+ ping vers l’extérieur)

root@debian1:~# ssh 192.168.2.254 root@192.168.2.254's password: Last login Mon Mar 30 11:54:57 2015 from 192.168.2.1 root@fedora1:~# root@fedora1:~# ping www.yahoo.fr PING src.g03.yahoodns.net (77.238.184.150) 56(84) bytes of data. 64 bytes from dailyquiz.yahoo.net (77.238.184.150): icmp_seq=1 ttl=53 time=56.4 ms 64 bytes from dailyquiz.yahoo.net (77.238.184.150): icmp_seq=2 ttl=53 time=62.1 ms 64 bytes from dailyquiz.yahoo.net (77.238.184.150): icmp_seq=3 ttl=53 time=58.8 ms ^C --- src.g03.yahoodns.net ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 56.436/59.156/62.193/2.369 msJ’atteris bien sur mon host. (et normal, j’arrive à surfer.)

Sinon, quelques autres tests :

  • ping MV -> host :

root@debian1:~# ping 192.168.1.2 PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data. 64 bytes from 192.168.1.2: icmp_req=1 ttl=64 time=0.098 ms 64 bytes from 192.168.1.2: icmp_req=2 ttl=64 time=0.143 ms 64 bytes from 192.168.1.2: icmp_req=3 ttl=64 time=0.130 ms 64 bytes from 192.168.1.2: icmp_req=4 ttl=64 time=0.114 ms 64 bytes from 192.168.1.2: icmp_req=5 ttl=64 time=0.116 ms ^C --- 192.168.1.2 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 3996ms rtt min/avg/max/mdev = 0.098/0.120/0.143/0.016 ms

  • ping MV -> default gateway host :root@debian1:~# ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. ^C --- 192.168.1.1 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 3999msLà, j’ai du mal à comprendre pourquoi ça ne fonctionne pas : j’arrive à pinguer le host (192.168.1.2) mais pas sa default gw (192.168.1.1) située sur le même réseau ! :open_mouth:

Et donc forcément :root@debian1:~# ping www.yahoo.fr ping: unknown host www.yahoo.fravec :[code]root@debian1:~# cat /etc/resolv.conf

carte réseau virtuelle vboxnet0 (VirtualBox)

nameserver 192.168.2.254

default gw host

#nameserver 192.168.1.1[/code]
J’ai essayé en décommentant la dernière ligne (et aussi en la mettant en 1ère position) mais ça ne résout pas le pb.
Par contre ça ralentit considérablement mon réseau.

#20

Il y a une différence : 192.168.1.2 est directement accessible sur la machine hôte, alors que 192.168.1.1 est au-delà. Or pour aller au-delà, il faut remplir deux conditions :

  1. Que la machine hôte fonctionne en routeur IP (ip_forward=1).
  2. Que les machines du réseau local sachent comment répondre à la MV. Au choix :
    2a) Que les machines du réseau local 192.168.1.0/24 ou leur passerelle par défaut aient une route pour le sous-réseau de la machine virtuelle 192.168.2.0/24 avec comme adresse de passerelle (routeur) 192.168.1.2, l’adresse de la machine hôte qui joue le rôle de routeur.
    2b) Que la machine hôte fasse du “masquerading” (NAT source) pour les communications du réseau virtuel vers le réseau local, imitant le fonctionnement d’une box internet.

Mais cela ne permet que les communications des MV vers le LAN, pas dans l’autre sens. Pour cela, il faut ajouter des règles de “port formwarding” (NAT destination) vers la MV pour les ports considérés, comme avec une box internet. Par exemple :

Evidemment, tu ne peux pas rediriger les ports déjà ouverts par l’hôte, sinon ils ne seront plus accessibles. Le NAT, c’est sale et compliqué. A éviter autant que possible.

Il faut encore régler quelques détails comme la résolution DNS (ne pas désigner comme nameserver dans resolv.conf une machine qui n’est pas DNS récursif) mais tu devrais t’en sortir.