Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Il y a très probablement un pb. au niveau du routeur B (IP forward, masquerade...) mais où ???
J'ai lu des pages et des pages web sans trouver une solution pertinente... vérifié trois fois les divers paramètres...
Là, j'avoue, je ne vois plus rien, ça doit être tout bête mais il me faut un regard extérieur ! 
NB: toutes les copies d'écran ci-dessous ont été faites sur (B), sauf la dernière, faite sur (A).
NB: à partir de A, ping 8.8.8.8 ne répond pas.
Voyez-vous d'où peut venir le problème ?
A votre dispo pour tout complément d'info.
Merci par avance.
@+
Steve.
Dernière modification par St3v3 (07-02-2023 00:24:08)
Hors ligne
Si tu as un retour, il te faudra vérifier que le resolv.conf est bien pris en charge. Sinon côté parefeu (dns, http, https).
courage : )
Ps: Au lieu des images, tu peux mettre les retours en textuel (copier/coller) dans les balises prévues pour.
Un petit lien pour rappel Utilisation des balises BBCode et de la coloration syntaxique sur le forum.
Dernière modification par kawer (07-02-2023 03:27:26)
ThinkPad T530 - Debian - CoreBoot
Hors ligne
Dernière modification par St3v3 (08-02-2023 00:51:53)
Hors ligne
Je ne peux hélas pas faire de copier/coller à partir de la VM B
Et la VM A ?
Enregistrer la sortie dans un fichier et le transférer vers l'hôte ?
Ou bien se connecter en SSH ?
par contre la résolution de nom est KO
As-tu essayé avec la commande "host" en spécifiant l'adresse du serveur DNS à interroger ?
Vérifie aussi les règles iptables.
Il vaut mieux montrer que raconter.
Hors ligne
Je n'ai jamais réussi à rendre la route default gw 10.0.60.1 persistante malgré de nombreux essais dans /etc/network/interfaces :
Je ne comprends pas d'où sort l'addresse IP 169.254.17.168/16 ???
NB: avahi désinstallé, pas de service DHCP, network-manager non utilisé
Bref, je suis lassé, ce qui devait être un petit montage amusant devient carrément ch!ant...
Quelques idées lumineuses pour sauver cette VM d'un décommissionnement certain ? 
A dispo pour toute info complémentaire.
@+
Steve.
Hors ligne
ensuite, on installe du NAT pour cacher le futur sous-réseau, comme ça tous les paquets sembleront venir de la passerelle :
On ajoute la communication par les interfaces dans les deux sens :
On sauvegarde les règles iptalbes :
Et on les réinjecte au redémarrage via /etc/network/interfaces :
Enfin, sur la machine cliente (192.168.1.y) , on ajoute une route statique pour accéder au réseau 10.0.60.0/24 (pour debian):
Je ne sais plus où j'ai trouvé ça mais ça fonctionne.
En espérant que ça t'aidera.
Dernière modification par Papadakis (18-02-2023 12:17:24)
Le désordre, c'est l'ordre, moins le pouvoir.
Hors ligne
sur la passerelle, dans /etc/sysctl.conf pour transférer tous les paquets
Pas tous, seulement les paquets IPv4.
on installe du NAT pour cacher le futur sous-réseau, comme ça tous les paquets sembleront venir de la passerelle
Inutile si le routage est correct.
On ajoute la communication par les interfaces dans les deux sens
Ces règles n'autorisent pas la communication dans les deux sens. Elles autorisent seulement les connexions unicast dans un sens, et rien dans l'autre.
iptables-save -> /etc/iptables_rules.save
Syntaxe incorrecte.
on les réinjecte au redémarrage via /etc/network/interfaces
Ça dépend du reste du contenu du fichier.
sur la machine cliente (192.168.1.y) , on ajoute une route statique pour accéder au réseau 10.0.60.0/24
Avec tes règles iptables, cette route ne sert à rien.
Dernière modification par raleur (18-02-2023 12:55:43)
Il vaut mieux montrer que raconter.
Hors ligne
Avec tes règles iptables, cette route ne sert à rien.
Désolé mais le pc va chercher 10.0.60.0/24 sur sa passerelle par défaut (la box) sans cette route.
Le désordre, c'est l'ordre, moins le pouvoir.
Hors ligne
Dernière modification par raleur (18-02-2023 16:43:01)
Il vaut mieux montrer que raconter.
Hors ligne
Le désordre, c'est l'ordre, moins le pouvoir.
Hors ligne
les règles iptables de la "passerelle" bloquent les connexions entrantes
Ah non, j'ai mal lu, c'est l'inverse, seules les connexions entrantes sont acceptées et les connexions sortantes sont bloquées. Du coup à quoi sert la règle de masquerading qui ne s'applique qu'aux connexions sortantes ?
Dernière modification par raleur (18-02-2023 16:44:27)
Il vaut mieux montrer que raconter.
Hors ligne
Pas moyen de rendre cette route persistante dans /etc/interfaces
Du coup j'ai essayé de lancer cette commande dans rc.local , ça veut pas marcher !
Au démarrage de la VM, j'ai:
"Failed to start /etc/rc.local Compatibility"
En commentaires, tous les essais infructueux menés:
rc.local s'exécute bien d'après ma trace mais plante justement sur l'ajout de la default gateway !!!
Avez-voue une idée pour faire avancer le schimilibilik ?
Raleur peut-être ?
J'avoue que ça me pète grave les burettes !
Merci.
Steve.
Hors ligne
Le désordre, c'est l'ordre, moins le pouvoir.
Hors ligne
Juste après démarage de la VM (pas reboot, qui des fois ne suffit pas à prendre en compte une modif. !) :
Dans rc.local la commande d'ajout de la default gateway est apparemment OK
d'après ma trace :
Au niveau routage, "c'est la fête du slip" 
:
On voit bien la route, ça devrait passer, non ?
...et non ! 
Seule solution, taper à la mano (exactement ce que j'ai mis dans le rc.local !):
Là, j'avoue, je ne sais plus quoi faire...
Tu es sous Debian 10 ou 11?
En VM (VMware, Virtualbox...) ?
Tu peux STP me copier le fichier interfaces de ton client avec la ligne de creation de la default gateway ?
Quelle gueule a ta table de routage sur le client ?
Merci.
@+
Steve
Hors ligne
Aucune route ajoutée :
Et pas de rc.local.
Si ça ne fonctionne pas avec ça, c'est que c'est la passerelle qui est mal configurée.
Le désordre, c'est l'ordre, moins le pouvoir.
Hors ligne