Pour mieux comprendre, peux tu me décrire brièvement ce que j’aurais eu a faire coté client si j’avais eu du Debian ?
merci
Est-ce que tu as pris le temps de lire l’article de la Wikipedia sur le Host Model ? 
–
AnonymousCoward
Oui, Linux utilise le Weak host j’ai lu, et je me suis peut etre mal expliqué :
Sous linux il y a quoi comme configuration a faire au niveau client pour qu’il nat ? vraiment rien du tout ?
Que tu prennes “serveur 1” ou “serveur 2”, tu as éventuellement de Source NAT sur l’interface WAN pour que les VMs qu’ils hébergent puisse aller sur Internet. Est-ce que c’est cela dont tu parles ?
Parce-qu’il ne faut surtout pas que tu mettes de SNAT en place sur les interfaces réseau VPN. Cela empêcherait que “Client 1” puisse joindre une IP en 192.168.100.0/24 , de la même manière qu’une machine sur Internet ne peut pas ping directement une machine derrière une box qui fait du SNAT (sans relais de port / port-forwarding).
–
AnonymousCoward
Ah d’accord, après les VM (sauf le DC) ont toutes une IP publiques et se servent seulement de la passerelle de l’hôte pour sortir avec leurs propres IP.
Par contre c’est quand même fou que je trouve absolument aucune doc qui parle de ce souci de strong host model, les seuls endroit ou ça en parle c’est des postes et docs qui ont des années et qui parlent d’OS obsolètes (2008-2012)… c’est pour ça que je t’ai dit tout a l’heure que ça m’étonnais que ça vienne de là, je suis quand même pas le SEUL a avoir ce souci.
Surtout que maintenant que j’y repense, a un moment a force de tests j’arrivais a ping mon interface 192.168.100.1 depuis le serveur Debian et j’arrivais meme a ping mon DC depuis mon Debian.
Mais j’ai tellement testé de choses que ça ne marche plus
Mais du coup comme ça a marché un temps c’est bien que le problème est dans ma conf Debian non ?
Tu as du voir dans les quelques documentations à ce sujet qu’il existe une commande avec netsh sous Windows pour passer en “weak Host Model”.
Je te suggère d’essayer cela pour voir si cela règle le problème. Ainsi, tu pourras être assuré de l’origine du problème.
Tu peux aussi louer une VM “sandbox” sur le cloud d’OVH ou chez un des nombreux autres “fournisseurs de cloud”, y installer Debian, mettre en place un client OpenVPN avec la même configuration que tes hyperviseurs Windows puis d’utiliser sudo modprobe dummy pour créer l’interface réseau dummy0 puis lui assigner une adresse IP “interne” que tu essaieras de ping depuis tes hyperviseurs.
Pour une poignée d’heures le temps de faire les tests, ça ne coûte qu’une poignée de cacahuètes.
–
AnonymousCoward
J’ai testé avec un client 3 avec le serveur debian d’un ami et j’avais le même souci
J’avais un ping de 10.8.0.20(client 3 Debian) vers 10.8.0.1(serveur Openvpn) et 10.8.0.100(client1 Windows)
Mais impossible de ping de 192.168.100.1 vers le client Debian en 192.168.10.1
J’ai aussi testé avec comme serveur un OpenVPN sous Windows avec le rôle Routage activé, et ça fonctionne…
Mais j’ai pas envie de claquer une licence Windows pour juste faire serveur VPN d’un truc fait pour Linux…
J’ai IP forwarding d’activé, les routes sont la… Mais ça marche pas sur le serveur Debian
En repartant de la conf du serveur Openvpn windows qui marche voici le fichier de conf que j’ai :
port 1194
proto tcp
dev tun
ca /etc/openvpn/vpnserv/keys/ca.crt
cert /etc/openvpn/vpnserv/keys/vpnserv.crt
key /etc/openvpn/vpnserv/keys/vpnserv.key # This file should be kept secret
dh /etc/openvpn/vpnserv/keys/dh-4096.pem
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route add 192.168.100.0 255.255.255.0 10.8.0.100"
push "route add 192.168.10.0 255.255.255.0 10.8.0.10"
push "redirect-gateway def1 bypass-dhcp"
client-config-dir /etc/openvpn/cdd/
client-to-client
keepalive 10 120
tls-auth /etc/openvpn/vpnserv/keys/ta.key 0 # This file is secret
cipher AES-256-CBC
auth SHA512
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA
max-clients 2
persist-key
persist-tun
status openvpn-status.log
verb 6
A noter que quand je met le push “redirect-gateway def1 bypass-dhcp” Le serveur client se connecte bien en 10.8.0.100 mais perds la connexion a internet, le redirect gateway redirige la mauvaise carte.
je remet également ma config reseau sur le routeur OpenVPN
ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet IPPUBLIQUE netmask 255.255.255.255 broadcast 213.30.70.244
inet6 fe80::f816:3eff:fe76:1250 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:76:12:50 txqueuelen 1000 (Ethernet)
RX packets 208604 bytes 18290618 (17.4 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 211730 bytes 24609367 (23.4 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
inet6 ::1 prefixlen 128 scopeid 0x10<host>
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
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.8.0.1 netmask 255.255.255.0 destination 10.8.0.1
inet6 fe80::71f5:e3df:569a:991e prefixlen 64 scopeid 0x20<link>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC)
RX packets 1 bytes 60 (60.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 17 bytes 1080 (1.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Et pour finir les routes :
root@vps:/etc/openvpn# ip route
default via IPPUBLIQUE dev ens3
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
192.168.100.0/24 via 10.8.0.100 dev tun0
192.168.10.0/24 via 10.8.0.10 dev tun0
IPPUBLIQUE dev ens3 scope linkFinalement j’avais un conflit entre le fichier ipp.txt et les fichiers dans CDD/clientX
J’ai commenté la ligne ipp.txt et j’ai mis ca dans les fichiers CDD/ClientX :
ifconfig-push 10.8.0.100 255.255.255.0
iroute 192.168.100.0 255.255.255.0
Tout fonctionne sauf une seule chose
Quand je restart le service OpenVPN il me vire les routes de Tun0
il suffit de la remettre en mettant ces deux commandes :
route add -net 192.168.100.0/24 gw 10.8.0.100 dev tun0
route add -net 192.168.10.0/24 gw 10.8.0.10 dev tun0
Mais a chaque redémarrage les routes sautent
J’ai mis les routes dans /etc/network/interfaces mais au démarrage du service networking, tun0 n’est pas actif et le reçoit donc pas la route
dans le fichier de conf du serveur, j’ai tenté deux commandes differentes en vain :
push "route add 192.168.100.0 255.255.255.0 10.8.0.100"
et
push "route add -net 192.168.100.0/24 gw 10.8.0.100 dev tun0"
Que je les commente ou pas, elles n’ont aucune incidence
Comment placer les routes en auto au démarrage du service Openvpn ?
Merci