Accès internet aléatoire sur mes machines virtuelles

network-king · 11 nov. 2017, 20:08

lol a écrit : 03 nov. 2017, 06:15 Salut,
J'ai du mal à comprendre le montage:
Les VM sont en mode pont avec l'interface WIFI de la machine Hôte, c'est ça ?
Qui fournit les IP ? L'interface Wifi de la machine Hôte ?
Je ne pensais pas que ce soit possible (et ça à l'air pas si simple...).

Virtualbox n'a pas râlé au moment de l'instalation de l'interface réseau virtualle ?

Ce sont mes montages aussi: mode bridge + mon routeur WIFI est en mode dhcp et distribue les adresses sur demande de mes VM et ca fait des mois que je suis sur la meme infrastructure. Mais il est vrai que je suis en

Code : Tout sélectionner

managed=false

@ungars

Essaie en simplifiant ton

Code : Tout sélectionner

interfaces

comme ca:

tu auras:

Ca suffit dans mon cas sur debian

12 nov. 2017, 07:14

ungars a écrit : 11 nov. 2017, 19:59 Je ne peux pas pinguer Google :
Code : Tout sélectionner
 ping -c5 www.google.fr
ping: unknown host www.google.fr
Par contre je peux pinguer Google ! :
Code : Tout sélectionner
ping -c5 209.85.203.94

C'est clairement un problème de résolution DNS.

ungars a écrit :Voici mon network interfaces :
Code : Tout sélectionner
auto eth0
    iface eth0 inet static
        address 192.168.1.15
        netmask 255.255.255.0
        gateway 192.168.1.1
Manque t' il quelque chose ?

dns-namerserers X.X.X.X

network-king · 12 nov. 2017, 08:02

PascalHambourg a écrit : 03 nov. 2017, 00:23 En fait c'est étonnant que ça ait bien marché jusqu'ici.

Le format normal des trames wifi à 3 adresses MAC (point d'accès, station, source ou destination derrière le point d'accès) ne permet pas le pontage d'une interface wifi par une station, seulement par un point d'accès puisqu'il n'y pas de place pour transmettre l'adresse MAC de la machine source ou destination derrière la station. Pour que le pontage fonctionne, il faut utiliser un format de trame spécial à 4 adresses MAC utilisé par les ponts wifi. C'est pourquoi dans le noyau Linux le pontage d'une interface wifi n'est plus autorisé si l'interface est en mode infrastructure (managed) ou ad-hoc, mais seulement si elle est en mode point d'accès (master) ou à 4 adresses.

Je suggèrerais soit de passer en ethernet, soit de remplacer le pontage par du routage.

Salut Pascal, je ne comprends pas cette dichotomie que tu fais entre une trame 802.11 qui aurait "3 adresses" et une autre qui en aurait "4" car j'ai toujours appris le format suivant.

Peux tu m'expliquer ce que tu veux dire? edit: car selon les cas la 4eme est utilisée ou pas mais elle reste "paddée",non?

network-king · 12 nov. 2017, 08:13

franb a écrit : 04 nov. 2017, 12:41 Pas tout à fait, il suggère juste mettre le mode accès réseau en «NAT» (si c'est virtualbox), et ça devrait aller.

Je ne pense pas qu'il fut nécessaire de basculer du mode bridge en NAT ou même de changer son fichier interfaces en static...dommage j'aurais souhaité qu'il essaie quand même ce que je lui avais proposé pour voir, car après tout c'etait sa config initiale

12 nov. 2017, 08:31

network-king a écrit : 12 nov. 2017, 08:13Je ne pense pas qu'il fut nécessaire de basculer du mode bridge en NAT ou même de changer son fichier interfaces en static...dommage j'aurais souhaité qu'il essaie quand même ce que je lui avais proposé pour voir, car après tout c'etait sa config initiale

Prends la peine de relire. Il est toujours en mode pont...
Il est juste passé de dhcp à static.

12 nov. 2017, 20:34

network-king a écrit : Salut Pascal, je ne comprends pas cette dichotomie que tu fais entre une trame 802.11 qui aurait "3 adresses" et une autre qui en aurait "4" car j'ai toujours appris le format suivant.
Peux tu m'expliquer ce que tu veux dire? edit: car selon les cas la 4eme est utilisée ou pas mais elle reste "paddée",non?

Je ne connais pas grand-chose au format des trames wifi. Je me réfère à l'explication ci-dessous accompagnant le changement du noyau 2.6.33 qui a interdit le pontage d'une interface wifi en mode managed (infrastructure) ou ad-hoc conventionnel. Le format de trame prévoit peut-être de la place pour 4 adresses, mais comme tu le dis et comme le montre ton tableau, la 4e adresse n'est utilisée qu'en mode WDS ou en mode "4-address" qui ne sont pas les modes normaux de communication entre une station et son point d'accès, et si j'ai bien compris, nécessitent une configuration spécifique des deux côtés et ne sont pas supportés par tous les matériels.

commit ad4bb6f8883a13bb0f65b194dae36c62a02ac779
Author: Johannes Berg <johannes@sipsolutions.net>
Date: Thu Nov 19 00:56:30 2009 +0100

cfg80211: disallow bridging managed/adhoc interfaces

A number of people have tried to add a wireless interface
(in managed mode) to a bridge and then complained that it
doesn't work. It cannot work, however, because in 802.11
networks all packets need to be acknowledged and as such
need to be sent to the right address. Promiscuous doesn't
help here. The wireless address format used for these
links has only space for three addresses, the
* transmitter, which must be equal to the sender (origin)
* receiver (on the wireless medium), which is the AP in
the case of managed mode
* the recipient (destination), which is on the APs local
network segment

In an IBSS, it is similar, but the receiver and recipient
must match and the third address is used as the BSSID.

To avoid such mistakes in the future, disallow adding a
wireless interface to a bridge.

Felix has recently added a four-address mode to the AP
and client side that can be used (after negotiating that
it is possible, which must happen out-of-band by setting
up both sides) for bridging, so allow that case.

ungars · 12 nov. 2017, 22:05

Bonsoir et merci de m' aider.
Pour network-king j' ai donc modifié mon network/interfaces :

Code : Tout sélectionner

# The loopback network interface
auto lo
iface lo inet loopback

Mais j' ai le même problème (après avoir stoppé et redémarré mon réseau) :

Code : Tout sélectionner

 ping -c5 www.google.fr
ping: unknown host www.google.fr

Puis :

Code : Tout sélectionner

 ping -c5 216.58.205.131
PING 216.58.205.131 (216.58.205.131) 56(84) bytes of data.
64 bytes from 216.58.205.131: icmp_seq=1 ttl=51 time=71.9 ms
64 bytes from 216.58.205.131: icmp_seq=2 ttl=51 time=71.6 ms
64 bytes from 216.58.205.131: icmp_seq=3 ttl=51 time=79.9 ms
64 bytes from 216.58.205.131: icmp_seq=4 ttl=51 time=71.5 ms
64 bytes from 216.58.205.131: icmp_seq=5 ttl=51 time=73.2 ms

--- 216.58.205.131 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 71.548/73.671/79.905/3.179 ms

Je me retrouve parfois avec ça :

Code : Tout sélectionner

ping -c5 216.58.205.131
PING 216.58.205.131 (216.58.205.131) 56(84) bytes of data.
64 bytes from 216.58.205.131: icmp_seq=2 ttl=51 time=74.5 ms
64 bytes from 216.58.205.131: icmp_seq=3 ttl=51 time=71.1 ms
64 bytes from 216.58.205.131: icmp_seq=4 ttl=51 time=73.4 ms
64 bytes from 216.58.205.131: icmp_seq=5 ttl=51 time=71.6 ms

--- 216.58.205.131 ping statistics ---
5 packets transmitted, 4 received, 20% packet loss, time 4008ms
rtt min/avg/max/mdev = 71.140/72.704/74.542/1.371 ms

Voire même :

Code : Tout sélectionner

ping -c5 216.58.205.131
PING 216.58.205.131 (216.58.205.131) 56(84) bytes of data.

--- 216.58.205.131 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4018ms

Tout ça à quelques secondes d' intervalles. J' avais déjà ce problème en ip statique

Pour lol tu me suggère de rajouter les dns de mon Fai dans mon resolv.conf c' est ça ? Si je le regarde j' ai ça à l' intérieur :

Code : Tout sélectionner

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

Que dois je faire ?
Effectivement, si je regarde le même fichier sur ma debian, j' ai bien les dns de mon Fai qui y figurent.

Merci beaucoup, bonne soirée.

13 nov. 2017, 00:14

C'est sûr que sans DNS configuré dans /etc/resolv.conf, la résolution de noms va beaucoup moins bien marcher.

Avec quoi gères-tu le réseau sur cette machine ? NetworkManager ? Qu'as-tu configuré dans les paramètres IPv4 de l'interface ?

13 nov. 2017, 06:07

ungars a écrit : 12 nov. 2017, 22:05 Pour lol tu me suggère de rajouter les dns de mon Fai dans mon resolv.conf c' est ça ? Si je le regarde j' ai ça à l' intérieur :
Code : Tout sélectionner
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
Que dois je faire ?
Effectivement, si je regarde le même fichier sur ma debian, j' ai bien les dns de mon Fai qui y figurent.

Merci beaucoup, bonne soirée.

Salut,
Non je suggerais de fixer le dns dans ton fichier /etc/network/interfaces. Le fichier resolv.conf à la facheuse habitude d'être écrasé... ;-)
Tu peux mettre l'IP de ta passerelle (Box/Routeur...) ou ceux de ton FAI.
Je prefère mettre comme DNS la passerelle, si elle fait bien son boulot tu gagne en vitesse de résolution (C'est quand même plus près que les DNS de ton FAI...).

network-king · 13 nov. 2017, 09:10

@Pascal

To avoid such mistakes in the future, disallow adding a
wireless interface to a bridge

Je ne comprends pas comment cela peut concerner le cas qui nous préoccupe car si j'ai bien compris il s'agit de configuration bridge en virtualisation et pas d'un vrai bridge avec N+1 cartes reseaux

ungars · 13 nov. 2017, 21:51

Bonsoir,
Il est vrai que l' on peut se mélanger les pinceaux avec mon histoire. Pour résumer :
- Du jour au lendemain je n' ai plus eu accès à internet sur mes machines virtuelles, lorsqu' elles étaient en Dhcp et un pont réalisé depuis la machine hôte sur la carte wifi.
- Apparement j' ai contourné le problème, en attribuant une adresse ip statique à mes machines, une debian fonctionne, reste à trouver la solution pour un serveur Ubuntu qui a seulement accès au lan.

C'est sûr que sans DNS configuré dans /etc/resolv.conf, la résolution de noms va beaucoup moins bien marcher.

Avec quoi gères-tu le réseau sur cette machine ? NetworkManager ? Qu'as-tu configuré dans les paramètres IPv4 de l'interface ?

A vrai dire je ne me suis jamais occupé de ce fichier, du moins sur mes machines virtuelles, sur ma Debian avec laquelle je vous réponds ce soir je pense que le fichier s' est rempli de lui même, du moins je n' ai pas souvenir de l' avoir touché. Pour la gestion réseau, ma machine hôte est sous Windows, le serveur Ubuntu récalcitrant n' a pas de bureau d' installé, donc tout se passe en modifiant les fichiers via une connexion ssh. Que veux tu dire avec "Qu'as-tu configuré dans les paramètres IPv4 de l'interface ?"

Salut,
Non je suggerais de fixer le dns dans ton fichier /etc/network/interfaces. Le fichier resolv.conf à la facheuse habitude d'être écrasé... ;-)
Tu peux mettre l'IP de ta passerelle (Box/Routeur...) ou ceux de ton FAI.
Je prefère mettre comme DNS la passerelle, si elle fait bien son boulot tu gagne en vitesse de résolution (C'est quand même plus près que les DNS de ton FAI...).

J' ai mis l' adresse ip de ma passerelle dans /etc/network/interfaces , redémarré mon réseau (networking stop / start) , mais je ne peux toujours pas pinguer.

Code : Tout sélectionner

auto eth0
    iface eth0 inet static
        address 192.168.1.15
        netmask 255.255.255.0
        gateway 192.168.1.1
        dns-nameservers 192.168.1.1

Par contre cela fonctionne si je mets les dns de mon Fai, je peux pinguer. La syntaxe que j' ai mis plus haut est bonne ?

Bonne soirée et merci pour tout.

13 nov. 2017, 22:22

network-king a écrit : 13 nov. 2017, 09:10
To avoid such mistakes in the future, disallow adding a
wireless interface to a bridge
Je ne comprends pas comment cela peut concerner le cas qui nous préoccupe car si j'ai bien compris il s'agit de configuration bridge en virtualisation et pas d'un vrai bridge avec N+1 cartes reseaux

Certes dans notre cas le pontage est réalisé par virtualbox et non par le noyau (c'est pourquoi il est autorisé - mais ne fonctionne pas mieux), mais le principe reste le même : il s'agit d'envoyer par l'interface wifi des trames dont elle n'est pas la source originelle et de recevoir des trames dont elle n'est pas la destination finale. La même limitation avec les trames en mode infrastructure qui n'utilisent que trois adresses MAC s'applique dans les deux cas.

ungars a écrit : sur ma Debian avec laquelle je vous réponds ce soir je pense que le fichier (/etc/resolv.conf) s' est rempli de lui même, du moins je n' ai pas souvenir de l' avoir touché.

Si resolvconf n'est pas installé sur cette VM, le fichier a dû être créé par le client DHCP et laissé tel quel quand le DHCP n'a plus fonctionné. Avec resolvconf, le fichier est recréé à chaque démarrage.

ungars a écrit : Que veux tu dire avec "Qu'as-tu configuré dans les paramètres IPv4 de l'interface ?"

Je veux dire quels paramètres as-tu défini : adresse, masque, passerelle, DNS ? Si tu as oublié de définir les DNS, il n'est pas anormal que le fichier resolv.conf n'en contienne pas.

ungars a écrit : J' ai mis l' adresse ip de ma passerelle dans /etc/network/interfaces , redémarré mon réseau (networking stop / start) , mais je ne peux toujours pas pinguer.

Tu veux dire que tu as mis l'adresse de la passerelle comme nameserver et que la résolution de nom ne fonctionne pas (unknow host) ? Dans ce cas il est probable que cette passerelle ne fait pas serveur DNS.

ungars a écrit :La syntaxe que j' ai mis plus haut est bonne ?

Pas tout-à-fait : il n'y a aucune raison d'indenter "iface" par rapport à "auto".

Note : l'option dns-nameserver(s) n'a d'effet que si resolvconf est installé.

network-king · 14 nov. 2017, 09:47

Certes dans notre cas le pontage est réalisé par virtualbox et non par le noyau (c'est pourquoi il est autorisé - mais ne fonctionne pas mieux), mais le principe reste le même : il s'agit d'envoyer par l'interface wifi des trames dont elle n'est pas la source originelle et de recevoir des trames dont elle n'est pas la destination finale. La même limitation avec les trames en mode infrastructure qui n'utilisent que trois adresses MAC s'applique dans les deux cas.

Ok, je regarderai ca dans la journée avec Wireshark

ungars · 14 nov. 2017, 11:58

Bonjour à tous,

Si resolvconf n'est pas installé sur cette VM, le fichier a dû être créé par le client DHCP et laissé tel quel quand le DHCP n'a plus fonctionné. Avec resolvconf, le fichier est recréé à chaque démarrage.

Ok pour l' explication.

Je veux dire quels paramètres as-tu défini : adresse, masque, passerelle, DNS ? Si tu as oublié de définir les DNS, il n'est pas anormal que le fichier resolv.conf n'en contienne pas.

Mon network/interfaces contient désormais cela :

Code : Tout sélectionner

auto eth0
    iface eth0 inet static
        address 192.168.1.15
        netmask 255.255.255.0
        gateway 192.168.1.1
        dns-nameservers 192.168.1.1

Pour faire fonctionner ce serveur Ubuntu, je me suis basé sur les fichiers équivalents de ma debian virtualisée, qui ne contient pas de dns-nameservers pour le netowrk/interfaces, mais qui en revanche a un resolv.conf contenant les dns (contrairement à mon serveur Ubuntu). Je n' ai pas souvenir de les avoir renseignées, mais peut etre qu' elles y étaient restées du temps ou j' étais en Dhcp.

Pas tout-à-fait : il n'y a aucune raison d'indenter "iface" par rapport à "auto".

Du coup, que dois je ecrire ?

Merci beaucoup pour le temps que vous me consacrez, bonne journée.

14 nov. 2017, 17:42

Hello,

ungars a écrit : 14 nov. 2017, 11:58
Code : Tout sélectionner
auto eth0
    iface eth0 inet static
        address 192.168.1.15
        netmask 255.255.255.0
        gateway 192.168.1.1
        dns-nameservers 192.168.1.1
Pas tout-à-fait : il n'y a aucune raison d'indenter "iface" par rapport à "auto".
Du coup, que dois je ecrire ?

Code : Tout sélectionner

auto eth0
iface eth0 inet static
        address 192.168.1.15
        netmask 255.255.255.0
        gateway 192.168.1.1
        dns-nameservers 192.168.1.1 (Ou IP de ton FAI si ta passerelle ne fournit pas de DNS)

ungars · 15 nov. 2017, 13:09

Bonjour, ok je n' avais pas saisi, je ne pensais pas que l' espace que j' avais mis devant iface pouvait avoir de l' influence sur mon fichier. Du coup, cela fait quoi en pratique.

Pour résumer, j' ai contourner mon problème initial en attribuant une adresse ip fixe à mes machines virtuelles. Reste à savoir pourquoi cela a fonctionné pendant plus de 3 ans sans encombre et pourquoi avec une adresse ip non fixe cela m' a posé des problème subitement. J' ai bien compris que ma configuration en wifi n' était pas l' idéal, mais je voudrais écarter le problème venant éventuellement de ma Freebox.
Donc je vais repasser en dhcp, voir ce que cela donne d' ici quelques jours. Dans deux semaines, je serai en déplacement, j' aurai pendant 2 jours une Livebox à disposition, je pourrai faire quelques essais.

En vous remerciant une nouvelle fois pour votre aide, bonne journée.

franb · 25 déc. 2017, 11:15

Y-a-t-il d'autres machines sur le reseau?
Notamment que donne
netdiscover -r 192.168.1.0/24

Est ce que quand ça coince, changer d'ip (via un ifconfig eth0 down, ifconfig eth0 192.168.1.123 up ) change quelque chose?

ungars · 26 déc. 2017, 09:31

Bonjour,
Merci pour ta réponse.
Je pense de plus en plus que c' était un problème avec le serveur DHCP de ma box, peut etre du à une mise à jour problématique :
- Le problème est arrivé avec toutes mes machines en Dhcp du jour au lendemain.
- Et en attribuant une adresse ip fixe, le problème était reglé (via ifconfig ou /network/interfaces)

Entre temps, j' ai installé une Kali Linux en Dhcp, et je n' ai pu ce problème.

Pour répondre à ta question :

Code : Tout sélectionner

Currently scanning: Finished!   |   Screen View: Unique Hosts                 
                                                                               
 12 Captured ARP Req/Rep packets, from 2 hosts.   Total size: 720              
 _____________________________________________________________________________
   IP            At MAC Address     Count     Len  MAC Vendor / Hostname      
 -----------------------------------------------------------------------------
 192.168.1.1     00:24:d4:c0:5e:b6      7     420  FREEBOX SAS                 
 192.168.1.10    a4:17:31:93:23:89      5     300  Unknown vendor

Reste à savoir pourquoi je n' ai eu ce problème qu' avec les machines virtuelles.... Avec ma machine hôte, ou ma tablette / téléphone portable, je n' ai pas été embété.

Du coup je vais passer le sujet en résolu.

Bonne journée.

Accès internet aléatoire sur mes machines virtuelles Le sujet est résolu