VPN ClientToClient et LAN “local" ? Mais comment ils font !?
RésoluCalimero90 Messages postés 49 Date d'inscription vendredi 18 octobre 2013 Statut Membre Dernière intervention 23 août 2024 - 23 août 2024 à 12:07
- VPN ClientToClient et LAN “local" ? Mais comment ils font !?
- Vpn gratuit - Guide
- Appdata local - Guide
- Vpn comment ça marche - Guide
- Ip local - Guide
- Local send - Télécharger - Divers Utilitaires
12 réponses
Modifié le 22 août 2024 à 19:13
Bon, voila, je pense que ce sujet est clos !
Merci beaucoup à brupala et yg_be !!!
.
Pour les intéresses, vous trouverez ma solution dans les derniers messages... (à partir de <34>)
.
Attention avec "ifconfig-pool-persist ipp.txt", selon certaines sources, le fichier risque de saturer (pool dhcp) avec des clients qui ne se connectent même plus... Moi j'ai mis un petit "#" devant ! lol !
(Je m'en fou d'avoir tjs la même adresse pour un client !)
(Sinon il y a aussi "client-config-dir /etc/openvpn/ccd" et "ifconfig-push" dans ces fichiers...)
.
J'ai bien appris ici. Je suis content de moi !
A+!
7 août 2024 à 12:25
Salut,
difficile de t'en dire plus ne connaissant pas le fonctionnement de l'administration de ces automates.
Si ils utilisent le protocole IP, (v4 ou v6), il doit être routable via une passerelle, pas de souci.
Si c'est un autre protocole ethernet non routable il faut un pont réseau, un pont distant est faisable en openvpn si le routeur en question l'a prévu et ton serveur vpn aussi.
voir aussi:
https://openmaniak.com/fr/openvpn_bridging.php
Tu parles de protocoles IOT ou domotique, là c'est autre chose, il faut souvent convertir via une passerelle.
Modifié le 7 août 2024 à 14:36
bonjour,
Tu aurais le même problème avec beaucoup d'imprimantes, qui utilisent d'autres protocoles que IP pour la découverte des appareils. Ces protocoles ne sont pas routables.
Parfois, ils est possible de travailler sans cette étape de découverte, en configurant manuellement les appareils ou applications.
.
Un pont se fait entre deux interfaces. Si je comprends bien, le pont openvpn se ferait entre l'interface virtuel vpn de PCuser et un interface (virtuel, je suppose) de ton router LAN4g. Sur cet interface virtuel, PCuser recevrait, via DHCP, une adresse IP dans le sous-réseau de LAN4g.
Restera à vérifier que les softs spécifiques ‘propriétaires’ comprendront la configuration à plusieurs interfaces de PCuser, et utiliseront le bon pour communiquer avec tes appareils.
.
On pourrait peut-être envisager d'utiliser un ordi sur LAN4g, et d'y ponter deux interfaces, un physique, et un virtuel (vpn).
.
Je me demande si il n'est pas préférable de travailler autrement:
- installer tous les softs spécifiques ‘propriétaires’ sur un ordi connecté à LAN4g
- A partir de PCuser, contrôler cer ordi à distance
7 août 2024 à 15:32
C'est vrai que ta dernière proposition serait une solution.
En effet tous les logiciels des découverte et configuration automatique, par principe, ne savent pas sortir d'un réseau local.
7 août 2024 à 15:37
Comment on fait une interface LAN4g direct sur PCuser:
- on écrit un logiciel qui ordonne à Windows de créer un interface réseau virtuel
- cet interface réseau virtuel est vu par Windows comme n'importe quel autre interface, tous les protocoles supportés par Windows (IP, TCP, DHCP, ...) peuvent l'utiliser pour en recevoir et y envoyer des données,
- cet interface réseau virtuel peut être configuré dans Windows comme tout autre interface, avec une adresse IP statique ou dynamique, ...
- cet interface réseau n'est pas lié à un interface physique, il n'utilise donc pas les logiciels habituels (drivers) qui donnent accés à un interface physique
- le driver gérant cet interface peut faire ce qu'il veut avec les données "à envoyer", et peut fournir à Windows les données qu'il veut, comme des données reçues
- ce driver va donc communiquer avec un dispositif connecté à LAN4g.
- le driver va collaborer avec ce dispositif pour faire transiter les données, comme si l'interface virtuel était connecté à LAN4g
- par exemple, si l'interface virtuel est configuré avec une adresse dynamique, Windows enverra une demande DHCP sur l'interface. Cette demande DHCP sera transférée par le driver vers le dispositif connecté à LAN4g. Ce dispositif diffusera la demande sur LAN4g, le serveur DHCP de LAN4g répondra avec une adresse IP, et le dispositif transèrera la réponse au driver, qui la passera à Windows. Windows associera alors l'adresse à l'interface virtuel.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question7 août 2024 à 16:58
un PC sur place:
Oui, j'y avais pensé en dernier recours, mettre un PC sur place et faire du Teamviewer par exemple...
Bof...
Ou utiliser le système magique mais payant...
Bof...
Merci @yg_be pour tes explications sur la creation/gestion de cette interface "magique".
Bien sûr, elle n'est pas magique, ce sont les developpeurs... Et il faut bien les remunérer !!
****************
****************
Ce système "magique" crée deux interfaces et SANS PONT !
Avec mon Routeur4G et OpenVPN connect j'ai :
Carte inconnue Connexion au réseau local :
Suffixe DNS propre à la connexion. . . :
Description. . . . . . . . . . . . . . : TAP-Windows Adapter V9 for OpenVPN Connect
Adresse physique . . . . . . . . . . . : 00-FF-96-51-47-4C
DHCP activé. . . . . . . . . . . . . . : Non
Configuration automatique activée. . . : Oui
Adresse IPv6 de liaison locale. . . . .: fe80::d392:93e5:1e7b:2f0e%49(préféré)
Adresse IPv4. . . . . . . . . . . . . .: 10.8.0.3(préféré)
Masque de sous-réseau. . . . . . . . . : 255.255.255.0
Passerelle par défaut. . . . . . . . . : 10.8.0.1
IAID DHCPv6 . . . . . . . . . . . : 822149014
DUID de client DHCPv6. . . . . . . . : 00-01-00-01-2A-7A-B1-15-B0-4F-13-E9-97-D4
NetBIOS sur Tcpip. . . . . . . . . . . : Activé
Carte inconnue OpenVPN Connect DCO Adapter :
Statut du média. . . . . . . . . . . . : Média déconnecté
Suffixe DNS propre à la connexion. . . :
Description. . . . . . . . . . . . . . : OpenVPN Data Channel Offload
Adresse physique . . . . . . . . . . . :
DHCP activé. . . . . . . . . . . . . . : Oui
Configuration automatique activée. . . : Oui
==>> Il n'y a pas qqch à faire avec cette deuxième interface "non connectée" !??
**************
**************
BON, BREF,
Je veux bien essayer encore une solution avec Pont.
(pas mal de truc à voir, mais bon...)
yg_be,
J'ai pas compris le pontage que tu proposes:
Comment je peux faire un pont entre une interface sur PCuser et une autre sur le routeur4G ?
brupala
J'ai un peu lu les liens (et bien d'autres)
C'est prometteur mais je mélange un peu:
Si je comprends, il faudrait faire un pont sur le routeur4G entre l'interface VPN et le LAN (Si c'est possible)
ET
Un Pont sur le serveurVPN (sur le VPS?) entre… quoi et quoi ?
Et peut-être sur le PCuser aussi !??
Ou alors tout se configure avec des push(?) dans les fichiers de config de OpenVPN ?
Si le routeur4G ne convient pas, peut-être que je peux transformer mon PClinux (sur le LAN4g) pour faire routeur aussi (avec un USB/4G)...
Ce serait peut-être même plus facile (Heuu, plus de de possibilités en tout cas)... Non ?
Trop compliqué ?
Vous me conseillez de payer les developpeurs !? (Plusieurs fois même, plusieurs sites, grrrr)
************
Vos avis ?
....
Ci-dessous le menu du routeur. Je ne pense pas qu'il y ai qqch pour faire un bridge...
Modifié le 7 août 2024 à 17:21
Si je comprends, il faudrait faire un pont sur le routeur4G entre l'interface VPN et le LAN (Si c'est possible) ET Un Pont sur le serveurVPN (sur le VPS?) entre… quoi et quoi ? Et peut-être sur le PCuser aussi !??
un pont sur le routeur 4G en lan ethernet et le vpn, c'est sûr.
sur le vps, je ne sais trop, peut-etre que openvpn le fait d'office, surtout en mode client to client, en tout cas les deux connexions sont dans le même réseau ip, on joue avec les lignes là.
Sur le PCuser, ça ne me parait pas utile.
Ton routeur semble permettre tun (routé) ou tap (bridge) au choix , mais je ne peux t'en dire plus.
8 août 2024 à 09:28
Le VPN est, pour le moment, configuré en mode TUN. Je pense qu'il est nécessaire de le changer en mode TAP afin de pouvoir ponter deux interfaces.
.
Je pense qu'il suffit de faire un seul pont, par exemple sur le routeur4G entre l'interface VPN et un des interfaces LAN. Ce pont pourrait aussi se faire sur un ordi connecté au VPN et au LAN, si cet ordi a un interface libre sur le LAN.
.
Si j'ai finalement compris, en mode TAP, OpenVPN crée, implicitement, un pont entre ses interfaces virtuels. Il suffit alors de créer explicitement, sur un appareil, un pont entre l'interface virtuel vpn local et un interface physique. En faisant ainsi, tous les interfaces virtuels vpn sont "présents" sur le même LAN que l'interface physique.
.
Voici un extrait (traduit et légèrement adapté) d'une discussion fur le forum openvpn, qui confirme que openvpn permet cela:
Vous disposez d'une application qui n'utilise pas de paquets IP. Et vous utilisez ce programme sur Internet, qui est avant tout un réseau IP.
Permettez-moi d'insister sur ce point : vous utilisez un programme qui n'utilise pas de paquets IP sur un réseau qui transporte des paquets IP.
Cela ne fonctionne pas. Vous avez donc recours à une solution de contournement.Ce que vous avez cependant, c'est une application qui n'utilise pas les paquets IP, mais quelque chose d'autre, qui ne fonctionnera apparemment que sur un réseau de couche 2. La couche 2 fait partie du modèle OSI qui explique le fonctionnement des couches du réseau et signifie qu'elle fonctionne à un niveau plus bas que les paquets IP de la couche 3.
Heureusement pour vous, OpenVPN2 prend cela en charge. Il peut relier des clients VPN distants à un réseau local. Il peut même relier des réseaux entiers. Les données envoyées et reçues, même s'il ne s'agit pas de paquets IP, sont encapsulées dans des paquets IP afin de pouvoir être transportées sur l'internet, ce qui permet de résoudre ou plutôt de contourner le problème que votre application rencontre au cœur même de son fonctionnement.
Le pontage OpenVPN2 est en fait une solution de contournement du problème inhérent à votre application - elle ne sait pas comment envoyer des paquets IP qui peuvent être transportés sur Internet, et vous utilisez donc la capacité de pontage d'OpenVPN2 pour contourner ce problème.
8 août 2024 à 10:09
Comme je disais,
je ne sais pas si ça change quelque chose que le serveur vpn soit tap ou pas, car il ne relie pas les connexions vpn au lan directement, uniquement les connexions vpn entre elles (dans le même réseau ip 10.8.0.0/24) et configurées en client to client, c'est peut-etre suffisant pour le ponter entre elles.
8 août 2024 à 11:55
Je pense avoir compris que, en mode TUN, OpenVPN transporte uniquement le trafic IP.
Le mode TAP est requis pour qu'il fonctionne en mode bridge, comme un switch L2.
Modifié le 8 août 2024 à 14:29
Bonjour à vous !
Je vous lis et relis, et aussi les web.
Cette histoire de TAP me parait bien mieux pour mon cas.
Si je comprends bien, faire un VPN TAP, c’est implicitement faire un pont couche 2, on s’affranchis donc des problèmes de protocole et IP (On perd en sécurité ? à voir…)
Vous êtes d’accords ou pas ?
(
TUN = réseau de tunnels sur routage de couche 3. Il existe un sous-réseau entre le client OpenVPN et le serveur qui gère la communication entre appareils (le sous-reseau c’est 10.8.0.0/24 c’est ça ?)
TAP = Lien physique de couche 2 vers l'interface à laquelle vous le reliez. Vous n’aurez pas de « route » car il n’y a pas de routage. C'est comme faire glisser un très long câble Ethernet entre deux réseaux.
)
Si le Serveur VPN sur le VPS est en TAP le client VPN (le routeur 4G) doit l’être aussi !
(Et aussi PCuser en TAP, sinon, il faut une autre instance de VPN, à voir…)
Une chose à la fois, parlons juste pour l’instant entre le LAN4g et le VPS.
(Finalité, le PCuser, à voir…)
VOICI UN ESSAI :
Rappel de mon LAN4g :
Routeur 4G : 192.168.10.1 (configuré en client VPN via fichier router.ovpn)
PClinux : 192.168.10.201 (@yg_be : 3*RJ45, au cas où…)
PLC et Drive : 192.168.10.20 / 192.168.10.21
DHCP de 192.168.10.40 à 192.168.10.80 (au cas où… Ne sert pas, il est désactivé)
(Et un bête switch)
Et je rappelle que mis à part la config pour le client VPN, je n'ai RIEN ajouter dans ce routeur... (Pas de route, forward, NAT...)
J’ai repris mes fichiers de config TUN que j’ai tuné (lol) en TAP :
J’ai mis « dev tap » sur server.conf et router.ovpn
J’ai viré « server 10.8.0.0 255.255.255.0 »
J’ai ajouté « server-bridge 192.168.10.100 255.255.255.0 192.168.10.110 192.168.10.150 »
Et j’ai viré tout ce qui concerne les routes (push route, route, iroute) dans tous les fichiers
Et donc, plus de fichier ccd, car les 10.8.0.x exit aussi…
Si j’ai bien compris mes lectures (pas sûr !) c’est ce qu’il faut faire…
Puis restart du serveur VPN et upload du new fichier router.ovpn dans le client VPN du routeur4G
Le client VPN se connecte bien (apparemment)
Ensuite il a fallu que je fasse deux trois incantations sur le VPS:
ip link set tap0 up
ip addr add 192.168.10.100/24 dev tap0
ip route add 192.168.10.0/24 dev tap0 (inutile: RTNETLINK answers: File exists)
iptables -I INPUT -i tap0 -j ACCEPT
iptables -I FORWARD -i tap0 -j ACCEPT
(et restart…)
Ce qui donne:
root@srv566162:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 82.112.241.254 0.0.0.0 UG 0 0 0 eth0
82.112.241.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0
root@srv566162:~# ip route
default via 82.112.241.254 dev eth0 onlink
82.112.241.0/24 dev eth0 proto kernel scope link src 82.112.241.69
192.168.10.0/24 dev tap0 proto kernel scope link src 192.168.10.100
root@srv566162:~# ip addr
5: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
link/ether 0a:81:2b:dd:9b:b8 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.100/24 scope global tap0
valid_lft forever preferred_lft forever
inet6 fe80::881:2bff:fedd:9bb8/64 scope link
valid_lft forever preferred_lft forever
(Je sais pas pourquoi state UNKNOWN, normal ?)
root@srv566162:~# cat /var/log/openvpn/status.log
OpenVPN CLIENT LIST
Updated,2024-08-08 11:13:23
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
GCSRouter,78.243.153.22:57622,36829,37529,2024-08-08 09:05:46
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
GLOBAL STATS
Max bcast/mcast queue length,1
***********
RESULTATS : (bin non pas WouHaaaa, pas encore !)
Le serveur VPN sur le VPS démarre bien, sans erreur.
Le routeur sur le LAN4g semble bien se connecter au VPN.
Mais, depuis le VPS, je ne peux pas atteindre (ping) les devices du réseau LAN4g.
Par exemple « ping 192.168.10.1 » (le routeur 4G) ne réponds pas
Par exemple « ping 192.168.10.201 » (le PClinux) ne réponds pas
Depuis le VPS, je peux pinger le serveur lui même:
"ping 192.168.10.100" réponds !
(C’est déjà ça, sans "ip link set tap0 up” et "ip addr add 192.168.10.100/24 dev tap0” ça pingait pas)
Et depuis le routeur 4G (diagnostic), sur le LAN4g, je ne peux pas pinger le serveur VPN
"ping 192.168.10.100" (Depuis le LAN4g) ne réponds pas !
Bref, c’est connecté niveau VPN (je crois), mais c’est tout !
GRRrrrr !
Sur le VPS, avec ou sans ping en cours, ces tcpdump ne donne rien du tout !
tcpdump icmp
tcpdump host 192.168.10.100
tcpdump net 192.168.10.0/24
tcpdump -i tap0
ces tcpdump donnent des lignes (Houhaa, je suis pas isolé !)
tcpdump
tcpdump host adr.ip.du.vps
Mais rien d’intéressant, je pense…
Allez les gars ! Trouvez quelque(s) chose(s) à redire !!!
Quoi faire ? Où ?
Je suis sûr qu’il manque un petit truc !
MERCI !
Modifié le 8 août 2024 à 14:45
As-tu fait le pont mentionné au second paragraphe de mon message du 8 août 2024 à 09:28?
.
Je pense que tu te fourvoies avec "server bridge". Le pont ne doit pas se faire sur le serveur, il doit se faire sur un appareil connecté au LAN. Un "serveur bridge" permettrait d'ajouter un interface physique du serveur au LAN virtuel VPN. Alors que tu veux ajouter un interface physique de LAN4g au LAN virtuel VPN, de façon à interconnecter les deux LAN au niveau 2, comme via un cable ou un switch.
.
Je pense qu'il ne faut rien configurer dans openvpn à propos des adresses 192.168.10. OpenVPN faisant du niveau 2, les interfaces virtuels VPN (tap) doivent être configurés pour recevoir une adresse IP dynamique.
8 août 2024 à 14:49
J'avais supposé que DHCP était actif sur LAN4G. Je découvre que non.
Je suggère de l'activer, afin de vérifier que les interfaces virtuels vpn tap sur le serveur et sur UserPC reçoivent bien chacun une adresse IP sur LAN4G.
Modifié le 8 août 2024 à 16:25
Il faudrait vérifier si côté routeur, il y a bien un bridge entre la tap et le lan
des ip nei ou arp devraient indiquer l'état du voisinage arp.
8 août 2024 à 16:05
@yg_be (et citation brupala)
Au <7> tu dis :
Le VPN est, pour le moment, configuré en mode TUN. Je pense qu'il est nécessaire de le changer en mode TAP afin de pouvoir ponter deux interfaces.
Et tu ajoutes effectivement :
Je pense qu'il suffit de faire un seul pont, par exemple sur le routeur4G entre l'interface VPN et un des interfaces LAN. Ce pont pourrait aussi se faire sur un ordi connecté au VPN et au LAN, si cet ordi a un interface libre sur le LAN.
Et tu dis :
Je pense que tu te fourvoies avec "server bridge".
ET brupala dis : je ne sais pas si ça change quelque chose que le serveur vpn soit tap ou pas…
DONC :
(Sauf erreur bien sûr)
1.
Je fais un VPN TAP ou pas ?
Parce-que si TAP, cela IMPLIQUE l’option "server bridge" (et remove de l’option « server 10.8.0.0 255.255.255.0 »)
2.
Je le fais où ce pont !?
Le pont sur « le routeur4G entre l'interface VPN et un des interfaces LAN » est fait (je pensais) par l’option dev tap dans le fichier router.ovpn qui me sert à configurer le client VPN dans le routeur.
Non ?
Sinon, je vois pas d’option « Pont » (bridge) dans les menu du routeur.
D’ailleurs, quand j’ai dis cela, brupala m’as fait remarque que, SI, il y a l’option TAP dans le client VPN du routeur (configuré pas le fichier router.ovpn dans mon cas)
3.
Tu dis encore :
Je pense qu'il ne faut rien configurer dans openvpn à propos des adresses 192.168.10. OpenVPN faisant du niveau 2, les interfaces virtuels VPN (tap) doivent être configurés pour recevoir une adresse IP dynamique.
Mais je répète, niveau 2 = TAP = "server bridge x.x.x.x " (quelle adresse alors ?)
(Je comprends pas…)
4.
Et tu ajoute :
J'avais supposé que DHCP était actif sur LAN4G. Je découvre que non.
Je suggère de l'activer, afin de vérifier que les interfaces virtuels vpn tap sur le serveur et sur UserPC reçoivent bien chacun une adresse IP sur LAN4G
Lol ! Moi je pensais que c’était « server-bridge 192.168.10.100 255.255.255.0 192.168.10.110 192.168.10.150 » qui faisait ça !
(
Bon, j’ai rien changé, j’ai réactivé ce dhcp (et il fonctionne, en local).
Redémarré serveur vpn refais le « ip link set tap0 up »
Redémarré le routeur.
Et idem…
)
Rappel :
root@srv566162:~# cat /var/log/openvpn/status.log
OpenVPN CLIENT LIST
Updated,2024-08-08 13:55:40
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
GCSRouter,78.243.64.37:5610,2364,2302,2024-08-08 13:55:10
ROUTING TABLE => VIDE ! (normal?)
Virtual Address,Common Name,Real Address,Last Ref
GLOBAL STATS
Max bcast/mcast queue length,0
BREF,
En clair, je comprends plus !
S’il te plait, peux-tu résumer, à ton avis bien sûr, ce que je dois faire / pas faire ?
Je suis désolé de vous solliciter autant !!
MERCI.
Modifié le 8 août 2024 à 16:20
Et rappel :
6: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
link/ether 0a:81:2b:dd:9b:b8 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.100/24 scope global tap0
valid_lft forever preferred_lft forever
inet6 fe80::881:2bff:fedd:9bb8/64 scope link
valid_lft forever preferred_lft forever
.
tap0 prend bien l'adresse 192.168.10.100 du serveur.conf
De plus, tap0 n'apparait pas dans /etc/network/interfaces (et 'includes')
Donc pour le mettre en dynamique... ?
(Ou via une ligne dans serveur.conf ?)
8 août 2024 à 17:17
Le pont n'a rien à voir avec openvpn, il doit être créé avec le logiciel de l'appareil dans lequel on crée le pont.
Es-tu certain de ne pas voir d’option « Pont » (bridge) dans les menus du routeur?
Comme sur d'autres appareils, le pont correspond à un nouvel interface virtuel.
As-tu regardé dans le menu "network/interfaces" du routeur, "add new interface", "create a bridge over multiple interfaces"?
Modifié le 8 août 2024 à 17:54
Oui, tu as raison et j’ai tors !
Je me suis trompé (évidement, et ouf même !)
.
J'ai trouvé une discussion ou l'on voit qu'il est possible d'utiliser dev tap ET server x.x.x.x
(sans server-bridge) et ça reste en mode bridge couche 2
https://www.debian-fr.org/t/openvpn-mode-bridge-client-to-client/31642
.
Pour le menu des options dans mon routeur je n’ai pas « add new interface »
La doc que brupala a trouvée (au <6>) est celle du USR-G806. Moi j’ai un USR-G806w, j’ai pas cette option…
.
Le menu principal est au <5> de ce sujet.
Les principales pages de conf de ce routeur sont au début de mon sujet précèdent :
https://forums.commentcamarche.net/forum/affich-38077256-lan-via-routeur-4g-et-vpn-via-vps-route-nat-forward
Le fait de mettre dev tap dans le fichier router.ovpn ne suffit pas à faire ce pont tu penses ? (le routeur l'accepte, mais je sais pas ce qu'il en fait !)
.
.
Bref,
Je vais donc (encore) revoir ma copie !
Utiliser dev tap ET server x.x.x.x
Dois-je remettre toutes les options (route, iroute, push route) et ccd, comme en mode tun ?
Dans l'attente, si vous avez d'autre conseil/infos,
je suis preneur !
8 août 2024 à 17:59
Et je remarque dans la discution mentionnée que le gars à mis (a la fin) :
server 192.168.1.0 255.255.255.0
et non pas server 10.8.0.0 ... ou quelque chose comme ca !?
Dois-je mettre 192.168.10.0 255.255.255.0 ?
au lieu de 10.8.0.0 255.255.255.0
8 août 2024 à 19:06
"dev tap" dans la config de OpenVPN fait fonctionner le VPN en mode "bridge", cela forme un LAN, LANvpn, de niveau 2 entre les interfaces virtuel tap des différents participants au vpn.
.
Ton souci, c'est que tu veux faire communiquer PCuser, qui est bien connecté à LANvpn, avec d'autres appareils qui ne sont pas connectés à LANvpn, qui sont uniquement connectés à LAN4g.
.
Tu dois donc relier, au niveau 2, LANvpn et LAN4g. Pour cela, tu dois créer, sur un appareil relié aux deux LAN, un pont entre un interface relié à LANvpn et un interface relié à LAN4g.
.
Ton routeur ne semble pas capable de créer un tel pont.
.
Moi j'essaierais alors avec PClinux. Fonctionne-t-il comme client du VPN?
.
L'étape suivante sera, en oubliant temporairement OpenVPN, de ponter, sur PCLinux, l'interface LAN4g et l'interface LANvpn.
.
Cette page contient pas mal d'infos utiles, mais elle est extrèmement confuse, car ell parle en même temps d'un pont sur le serveur VPN et d'un pont sur un client VPN, seul ce dernier te concernant.
9 août 2024 à 09:13
Merci pour ces infos.
C'est du boulot tous ca hein !! Je vais voir tout ça...
.
@yg_be-<25>
tu dis :
Il n'y a pas de route à faire (tant mieux!), car cela crée un LAN, LANvpn, comme si, par analogie, tu avais mis un cable entre enp1S0 de PClinux et le tap vpn de PCuser.
Tu as bien dis PCuser ?
Mais on utilise quand même (en via) le OpenVPN serveur sur le VPS ?
Pour bien que je pige, c'est donc deux cables virtuels: PClinux/tap0 <=1=> VPS(tap0) <=2=> PCuser(tap)
les trois (clien PClinux, serveur VPS, client PCuser) sont bien en "dev TAP", OK ?
Puis-je imager que les trois sont sur un switch virtuel, ensemble qui forme, comme tu l'as nommé "LANvpn" ?
Et le routeur sur ce switch virtuel LANvpn serait... PClinux ou VPS ?
.
Merci !
.
.
Parenthèse:
Et, heu... L2TP ? (lol, je découvre)
Ca pourait être plus simple ou c'est trop obsolète (sécurité) et je délire ?
9 août 2024 à 10:20
On peut imaginer un pont comme un switch virtuel, ou comme un LAN de niveau 2:
- tu as donc un switch virtuel auxquels sont connectés enp1s0 et tap0 sur PClinux
- tu as donc un autre switch virtuel (LANvpn) auquels sont connectés les taps vpn de tous les participants au "TAP"
- tu as aussi ton LAN LAN4g
- ces trois LANs sont interconnectés, deux via enp1s0 de PClinux, deux via tap0 de PClinux
- tous ceux qui sont connectés sur un des ces trois LAN sont donc, virtuellement, interconnectés comme via un câble Ethernet
.
Il n'est pas nécessaire d'avoir un routeur sur chaque switch virtuel, pas plus que tu n'as de routeur sur ton switch physique présent sur LAN4g.
Un routeur est nécessaire pour connecter le LAN à l'extérieur, à tout ce qui est hors du LAN.
Il n'est sans doute pas souhaitable que les tap vpn sur PCuser et sur le VPS utilisent le routeur 4G pour communiquer avec Internet. C'est probablement une bonne raison d'éviter de les laisser utiliser DHCP, et qu'il est préférable de leur assigner une adresse statique, sans gateway.
9 août 2024 à 10:56
Tu proposes d'utiliser un logiciel utilisant L2TP, à la place, ou en complément de OpenVPN?
Quel logiciel?
9 août 2024 à 11:19
@bg_be <28>
Non, ça aurait été à la place !
Mais laisse tomber, mauvaise idée je pense...
Et puis je commence à connaitre un peu OpenVPN...
.
LOL au <25> tu me mettait pourtant bien en garde...
4. activer ce pont virtuel, ce qui risque de couper PClinux du lan4g, donc éviter de faire tout cela à distance
j'avais compris A DISTANCE (via Internet)
mais oui, ok, ca "coupe" enp1s0 de ma connexion ssh ! lol !
Bon, clavier et écran sur PClinux ! Moins confortable...
Et je vais me faire une autre connexion ssh (provisoire ou pas) sur enp3s0...
A plus.
Modifié le 10 août 2024 à 09:28
BON, J'AVANCE UN PEU...
(Et j'apprends énormément)
.
.Rappel : Le Routeur 4G n'est plus client du VPN, c'est PClinux maintenant
(J'ai juste garder le même nom de fichier de client: GCSRouter)
.
RESULTAT:
.
root@srv566162:~# cat /var/log/openvpn/status.log
OpenVPN CLIENT LIST
Updated,2024-08-09 11:34:09
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
DaGwin,91.nn.nn.nn:35593,55758,4070,2024-08-09 11:32:11
GCSRouter,78.242.24.68:54601,4026,56142,2024-08-09 11:29:08
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
2a:4c:2f:aa:e8:1c@0,GCSRouter,78.242.24.68:54601,2024-08-09 11:29:09
00:ff:b6:e9:1b:b0@0,DaGwin,91.nn.nn.nn:35593,2024-08-09 11:33:07
GLOBAL STATS
Max bcast/mcast queue length,2
.
PClinux, VPS et PCuser se connectent bien à OpenVPN mode TAP
PCuser ping 10.8.0.1 et .12(lui même) mais pas .11
VPS ping 10.8.0.1(lui même) et .12 mais pas .11
Personne ne ping 192.168.10.201 (le PClinux) (sauf lui même bien sûr)
Personne ne ping 192.168.10.1 (oui même PClinux !!??!!)
(Sur PClinux, je suis en ssh via enp3s0... Que lui est un PCtest hors tout, sans gw, liaison cable direct. rien à voir je pense)
.
.
SUR LE VPS J'AI FAIS CA:
.
server.conf:
dev tap
server 10.8.0.0 255.255.255.0
client-to-client
route 192.168.10.0 255.255.255.0
push "route 192.168.10.0 255.255.255.0"
.
ccd/GCSRouter: (le PClinux mainteant)
ifconfig-push 10.8.0.11 255.255.255.0
iroute 192.168.10.0 255.255.255.0
.
ccd/DaGwin: (le PCuser)
ifconfig-push 10.8.0.12 255.255.255.0
.
les .ovpn des deux client sont inchangés (avec dev tap, bien sûr)
.
.
j'ai aussi fait iptables blablabla qui donnent ca:
root@srv566162:~# iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
1987 497K ACCEPT udp -- eth0 any anywhere anywhere udp dpt:44090
0 0 ACCEPT all -- tun0 any anywhere anywhere
75 9707 ACCEPT all -- tap0 any anywhere anywhere
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- tun0 eth0 anywhere anywhere
0 0 ACCEPT all -- eth0 tun0 anywhere anywhere
0 0 ACCEPT all -- tap0 tap0 anywhere anywhere
0 0 ACCEPT all -- any any 10.8.0.0/24 10.8.0.0/24
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
17 1380 ACCEPT all -- any tap0 anywhere anywhere
.
.
.
SUR PCLINUX J'AI FAIS CA:
.
sudo openvpn --config /home/kwh/vpn/GCSRouter.ovpn
.
sudo brctl addbr br0
sudo brctl addif br0 tap0
sudo brctl addif br0 enp1s0
.
sudo ip addr add 192.168.10.210/24 dev br0
sudo ip route add default via 192.168.10.1
sudo ip link set dev br0 up
.
et aussi nft blablabla qui donnent ca:
kwh@gcs01:~$ sudo nft list ruleset
table ip filter {
chain input {
type filter hook input priority filter; policy accept;
iifname "tap0" accept
}
chain output {
type filter hook output priority filter; policy accept;
oifname "tap0" accept
}
chain forward {
type filter hook forward priority filter; policy accept;
iifname "tap0" oifname "tap0" accept
ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 accept
}
}
.
.
ET J'AI TOUT CA:
.
kwh@gcs01:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
link/ether 78:d0:04:33:95:c7 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.201/24 brd 192.168.10.255 scope global enp1s0
valid_lft forever preferred_lft forever
inet6 fe80::7ad0:4ff:fe33:95c7/64 scope link
valid_lft forever preferred_lft forever
3: enp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 78:d0:04:33:95:c8 brd ff:ff:ff:ff:ff:ff
4: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 78:d0:04:33:0b:37 brd ff:ff:ff:ff:ff:ff
inet 192.168.30.201/24 brd 192.168.30.255 scope global enp3s0
valid_lft forever preferred_lft forever
inet6 fe80::7ad0:4ff:fe33:b37/64 scope link
valid_lft forever preferred_lft forever
7: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UNKNOWN group default qlen 1000
link/ether 2a:4c:2f:aa:e8:1c brd ff:ff:ff:ff:ff:ff
inet 10.8.0.11/24 scope global tap0
valid_lft forever preferred_lft forever
inet6 fe80::10f1:7aff:fe8a:6769/64 scope link
valid_lft forever preferred_lft forever
8: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 76:e0:76:33:48:ee brd ff:ff:ff:ff:ff:ff
inet 192.168.10.210/24 scope global br0
valid_lft forever preferred_lft forever
inet6 fe80::74e0:76ff:fe33:48ee/64 scope link
valid_lft forever preferred_lft forever
.
kwh@gcs01:~$ sudo route
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
default 192.168.10.1 0.0.0.0 UG 0 0 0 enp1s0
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 enp3s0
192.168.10.0 10.8.0.1 255.255.255.0 UG 0 0 0 tap0
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 enp1s0
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
192.168.30.0 0.0.0.0 255.255.255.0 U 0 0 0 enp3s0
.
kwh@gcs01:~$ sudo ip route
default via 192.168.10.1 dev enp1s0 onlink
10.8.0.0/24 dev tap0 proto kernel scope link src 10.8.0.11
169.254.0.0/16 dev enp3s0 scope link metric 1000
192.168.10.0/24 via 10.8.0.1 dev tap0
192.168.10.0/24 dev enp1s0 proto kernel scope link src 192.168.10.201
192.168.10.0/24 dev br0 proto kernel scope link src 192.168.10.210
192.168.30.0/24 dev enp3s0 proto kernel scope link src 192.168.30.201
kwh@gcs01:~$
.
kwh@gcs01:~$ ping 10.8.0.1 -> ko
kwh@gcs01:~$ ping 10.8.0.11 -> OK(lui même)
kwh@gcs01:~$ ping 10.8.0.12 -> ko
.
.
Au lancement du client VPN sur PClinux j'ai plein de traces... (Je peux vous les donner...)
Apparemment, pas d'erreur, seule la première ligne, pas grave je pense...
kwh@gcs01:~$ sudo openvpn --config /home/kwh/vpn/GCSRouter.ovpn
2024-08-09 13:29:08 Unrecognized option or missing or extra parameter(s) in /home/kwh/vpn/GCSRouter.ovpn:19: block-outside-dns (2.6.3)
2024-08-09 13:29:08 Note: dev-type not tun, disabling data channel offload.
2024-08-09 13:29:08 OpenVPN 2.6.3 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
....
Et une erreur fréquente:
2024-08-09 13:30:55 read UDPv4 [EHOSTUNREACH]: No route to host (fd=3,code=113)
2024-08-09 13:31:06 read UDPv4 [EHOSTUNREACH]: No route to host (fd=3,code=113)
2024-08-09 13:31:16 read UDPv4 [EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH]: No route to host (fd=3,code=113)
2024-08-09 13:31:22 read UDPv4 [EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH]: No route to host (fd=3,code=113)
2024-08-09 13:31:32 read UDPv4 [EHOSTUNREACH|EHOSTUNREACH]: No route to host (fd=3,code=113)
2024-08-09 13:31:38 read UDPv4 [EHOSTUNREACH|EHOSTUNREACH]: No route to host (fd=3,code=113)
2024-08-09 13:31:41 read UDPv4 [EHOSTUNREACH]: No route to host (fd=3,code=113)
2024-08-09 13:31:51 read UDPv4 [EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH]: No route to host (fd=3,code=113)
2024-08-09 13:31:58 read UDPv4 [EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH]: No route to host (fd=3,code=113)
2024-08-09 13:32:10 read UDPv4 [EHOSTUNREACH]: No route to host (fd=3,code=113)
2024-08-09 13:32:14 read UDPv4 [EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH]: No route to host (fd=3,code=113)
2024-08-09 13:32:17 read UDPv4 [EHOSTUNREACH]: No route to host (fd=3,code=113)
2024-08-09 13:32:27 read UDPv4 [EHOSTUNREACH]: No route to host (fd=3,code=113)
2024-08-09 13:32:33 read UDPv4 [EHOSTUNREACH|EHOSTUNREACH|EHOSTUNREACH]: No route to host (fd=3,code=113)
2024-08-09 13:32:44 read UDPv4 [EHOSTUNREACH]: No route to host (fd=3,code=113)
2024-08-09 13:32:55 read UDPv4 [EHOSTUNREACH]: No route to host (fd=3,code=113)
.
C'est le problème ?
Ou autre(s) ?
.
.
.
CONCLUSION (provisoire):
J'ai zapper un truc ?
(J'espère oui !)
.
Ha tien !! J'ai plus Internet quand PCuser est sur le VPN...
(Ca, on verra plus tard)
.
Bon, là je vais faire mes courses (il faut bien que je miammiam de t en t...)
Je m'y remet ensuite. (Avec vos réponses j'espère, Merci !!!!!)
Ensuite, je bosse pas trop ce soir, j'ai un rencart (il faut bien que je ...vive de t en t...)
MERCI !!
9 août 2024 à 15:14
- gcs01, c'est PClinux?
- Que donne ipconfig/all de PCuser? Il a bien une adresse IP 192.168.10 sur son tap vpn?
- Je ne vois pas trop à quoi servent les adresses 10.8.0 dans notre mode TAP (et plus TUN)
- Inquiétant que PClinux ne pinge plus le routeur local sur lan4g.
- Si je comprends, tu as "192.168.10.0/24 via 10.8.0.1 dev tap0" comme route sur PClinux. D'où vient cette route? Elle est en conflit avec l'adresse 192.168.10.210/24 assignée à br0
- Tu as un PC Windows de disponible? Si j'avais su, j'aurais suggéré de l'utiliser au lieu de PClinux (parce que connais mieux Windows)
9 août 2024 à 16:53
Merci yb_be,
Ce serait bien plus dure tout seul !!
1. gcs01, c'est PClinux?
Oui !
2. Que donne ipconfig/all de PCuser? Il a bien une adresse IP 192.168.10 sur son tap vpn?
en fin de ce post
3. Je ne vois pas trop à quoi servent les adresses 10.8.0 dans notre mode TAP (et plus TUN)
Ha ? je vire "server 10.8.0.0 255.255.255.0" de server.conf ? et les "ifconfig-push 10.8.0.11 255.255.255.0" des ccd ?
4. Inquiétant que PClinux ne pinge plus le routeur local sur lan4g.
Oui...
5. Si je comprends, tu as "192.168.10.0/24 via 10.8.0.1 dev tap0" comme route sur PClinux.
D'où vient cette route? Elle est en conflit avec l'adresse 192.168.10.210/24 assignée à br0
Ha ok ! Je vire aussi les "route", "iroute" et "push route" dans les fichier de conf et ccd ? (voir plus haut ces fichiers)
(Il va plus rester grand chose...)
6. Tu as un PC Windows de disponible?
Si j'avais su, j'aurais suggéré de l'utiliser au lieu de PClinux (parce que connais mieux Windows)
Oui... Mais à terme c'est que PClinux... plus de PCtest...
Si j'y arrive pas avec PClinux, on verra avec PCtest...
.
.
Bon, là je suis HS ! Je vois ca demain...
(Mais tu peu me répondre)
;)
Merci
.
.
J'ai refais le test complet (reboot, redo...)
Tout pareil...
.
PS C:\Users\Damien> ipconfig /all
Configuration IP de Windows
Nom de l’hôte . . . . . . . . . . : DESKTOP-6H43BPU
Suffixe DNS principal . . . . . . :
Type de noeud. . . . . . . . . . : Hybride
Routage IP activé . . . . . . . . : Non
Proxy WINS activé . . . . . . . . : Non
Carte inconnue OpenVPN TAP-Windows6 :
Suffixe DNS propre à la connexion. . . :
Description. . . . . . . . . . . . . . : TAP-Windows Adapter V9
Adresse physique . . . . . . . . . . . : 00-FF-B6-E9-1B-B0
DHCP activé. . . . . . . . . . . . . . : Oui
Configuration automatique activée. . . : Oui
Adresse IPv6 de liaison locale. . . . .: fe80::8f55:9cab:f2ff:dfbc%49(préféré)
Adresse IPv4. . . . . . . . . . . . . .: 10.8.0.12(préféré)
Masque de sous-réseau. . . . . . . . . : 255.255.255.0
Bail obtenu. . . . . . . . . . . . . . : vendredi 9 août 2024 16:43:36
Bail expirant. . . . . . . . . . . . . : samedi 9 août 2025 16:43:35
Passerelle par défaut. . . . . . . . . :
Serveur DHCP . . . . . . . . . . . . . : 10.8.0.0
IAID DHCPv6 . . . . . . . . . . . : 822149046
DUID de client DHCPv6. . . . . . . . : 00-01-00-01-2A-7A-B1-15-B0-4F-13-E9-97-D4
NetBIOS sur Tcpip. . . . . . . . . . . : Activé
Carte inconnue OpenVPN Wintun :
Statut du média. . . . . . . . . . . . : Média déconnecté
Suffixe DNS propre à la connexion. . . :
Description. . . . . . . . . . . . . . : Wintun Userspace Tunnel
Adresse physique . . . . . . . . . . . :
DHCP activé. . . . . . . . . . . . . . : Non
Configuration automatique activée. . . : Oui
Carte Ethernet vEthernet (Default Switch) :
Suffixe DNS propre à la connexion. . . :
Description. . . . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter
Adresse physique . . . . . . . . . . . : 00-15-5D-14-C4-CE
DHCP activé. . . . . . . . . . . . . . : Non
Configuration automatique activée. . . : Oui
Adresse IPv6 de liaison locale. . . . .: fe80::150d:b628:e301:ee5e%24(préféré)
Adresse IPv4. . . . . . . . . . . . . .: 172.25.144.1(préféré)
Masque de sous-réseau. . . . . . . . . : 255.255.240.0
Passerelle par défaut. . . . . . . . . :
IAID DHCPv6 . . . . . . . . . . . : 402658653
DUID de client DHCPv6. . . . . . . . : 00-01-00-01-2A-7A-B1-15-B0-4F-13-E9-97-D4
NetBIOS sur Tcpip. . . . . . . . . . . : Activé
Carte réseau sans fil Wi-Fi :
Statut du média. . . . . . . . . . . . : Média déconnecté
Suffixe DNS propre à la connexion. . . :
Description. . . . . . . . . . . . . . : Intel(R) Wi-Fi 6 AX201 160MHz
Adresse physique . . . . . . . . . . . : F8-9E-94-CE-A8-42
DHCP activé. . . . . . . . . . . . . . : Oui
Configuration automatique activée. . . : Oui
Carte inconnue OpenVPN Data Channel Offload :
Statut du média. . . . . . . . . . . . : Média déconnecté
Suffixe DNS propre à la connexion. . . :
Description. . . . . . . . . . . . . . : OpenVPN Data Channel Offload
Adresse physique . . . . . . . . . . . :
DHCP activé. . . . . . . . . . . . . . : Oui
Configuration automatique activée. . . : Oui
Carte réseau sans fil Connexion au réseau local* 1 :
Statut du média. . . . . . . . . . . . : Média déconnecté
Suffixe DNS propre à la connexion. . . :
Description. . . . . . . . . . . . . . : Microsoft Wi-Fi Direct Virtual Adapter
Adresse physique . . . . . . . . . . . : F8-9E-94-CE-A8-43
DHCP activé. . . . . . . . . . . . . . : Oui
Configuration automatique activée. . . : Oui
Carte réseau sans fil Connexion au réseau local* 2 :
Statut du média. . . . . . . . . . . . : Média déconnecté
Suffixe DNS propre à la connexion. . . :
Description. . . . . . . . . . . . . . : Microsoft Wi-Fi Direct Virtual Adapter #2
Adresse physique . . . . . . . . . . . : FA-9E-94-CE-A8-42
DHCP activé. . . . . . . . . . . . . . : Non
Configuration automatique activée. . . : Oui
Carte Ethernet Ethernet :
Suffixe DNS propre à la connexion. . . :
Description. . . . . . . . . . . . . . : Realtek USB FE Family Controller
Adresse physique . . . . . . . . . . . : D0-C0-BF-2D-8E-20
DHCP activé. . . . . . . . . . . . . . : Oui
Configuration automatique activée. . . : Oui
Adresse IPv6. . . . . . . . . . . . . .: 2a01:e0a:1b7:b7a0:4ce6:a0e5:b94a:a70e(préféré)
Adresse IPv6 temporaire . . . . . . . .: 2a01:e0a:1b7:b7a0:1d6:b3c0:701f:8f88(préféré)
Adresse IPv6 de liaison locale. . . . .: fe80::9399:1f24:d29e:5c4f%68(préféré)
Adresse IPv4. . . . . . . . . . . . . .: 192.168.1.85(préféré)
Masque de sous-réseau. . . . . . . . . : 255.255.255.0
Bail obtenu. . . . . . . . . . . . . . : mercredi 7 août 2024 10:44:18
Bail expirant. . . . . . . . . . . . . : vendredi 9 août 2024 22:45:28
Passerelle par défaut. . . . . . . . . : fe80::2266:cfff:fe76:a567%68
192.168.1.254
Serveur DHCP . . . . . . . . . . . . . : 192.168.1.254
IAID DHCPv6 . . . . . . . . . . . : 1154531519
DUID de client DHCPv6. . . . . . . . : 00-01-00-01-2A-7A-B1-15-B0-4F-13-E9-97-D4
Serveurs DNS. . . . . . . . . . . . . : 192.168.1.254
8.8.8.8
NetBIOS sur Tcpip. . . . . . . . . . . : Activé
Modifié le 9 août 2024 à 18:40
Le tap vpn de PCuser reçoit par DHCP une adresse IP 10.8.0.12/24. Il lui manque une adresse IP sur LAN4g.
Carte inconnue OpenVPN TAP-Windows6 : Suffixe DNS propre à la connexion. . . : Description. . . . . . . . . . . . . . : TAP-Windows Adapter V9 Adresse physique . . . . . . . . . . . : 00-FF-B6-E9-1B-B0 DHCP activé. . . . . . . . . . . . . . : Oui Configuration automatique activée. . . : Oui Adresse IPv6 de liaison locale. . . . .: fe80::8f55:9cab:f2ff:dfbc%49(préféré) Adresse IPv4. . . . . . . . . . . . . .: 10.8.0.12(préféré) Masque de sous-réseau. . . . . . . . . : 255.255.255.0 Bail obtenu. . . . . . . . . . . . . . : vendredi 9 août 2024 16:43:36 Bail expirant. . . . . . . . . . . . . : samedi 9 août 2025 16:43:35 Passerelle par défaut. . . . . . . . . : Serveur DHCP . . . . . . . . . . . . . : 10.8.0.0 IAID DHCPv6 . . . . . . . . . . . : 822149046 DUID de client DHCPv6. . . . . . . . : 00-01-00-01-2A-7A-B1-15-B0-4F-13-E9-97-D4 NetBIOS sur Tcpip. . . . . . . . . . . : Activé
Modifie l'interface (sur PCuser, à la main, dans Windows) pour lui assigner une adresse statique de lan4g, /24 comme masque, pas de passerelle.
Essaie ensuite, sur PCuser, de pinger PClinux (10.168.10.nnn) et le routeur de lan4g.
Si, sauf miracle, cela ne fonctionne pas, partage ce que donnent, sur PCuser, "ipconfig/all", "arp -a" et "route print".
21 août 2024 à 23:35
Ça y est !! J’y suis enfin arrivé !!! (J’y ai mis le temps !)
Je suis grand maintenant !!!
Rappel du besoin :
Soit un VPS (Debian11) sur lequel est installé un serveur OpenVPN qui crée un LAN "LANvpn",
à configurer en TAP (couche 2) pour que tous les protocoles passent, pas seulement TCP/IP (couche 3)
Soit un LAN distant "LAN4G"(192.168.10.0/24) pas d'ip public.
Ce LAN4G est composé d'un switch sur lequel sont connectés :
- Un routeur 4G en 192.168.10.254 (qui fait aussi serveur DHCP pour ce LAN4G de .40 à .80)
- Un PC Debian12 "PClinux", client VPN, en 192.168.10.201 sur l'interface enp1s0
- 2 autres organes en 192.168.10.20 et 192.168.10.21 QUI COMUNIQUENT EN COUCHE 2 (découverte réseau)
Soit un LAN "LANuser" quelconque pas d'ip fixe.
Sur ce LANuser est connecté un PC Windows11 "PCuser", client VPN
Je veux que PCuser puisse se connecter à l'ensemble de organes du LAN4G comme s’il était en local (couche 2)
(Pour qu'il voit : 192.168.10.254, 192.168.10.201, 192.168.10.20, 192.168.10.21)
Résolution : (Toute remarque/amélioration est bienvenue)
Configuration du serveur VPN (server.conf) : (Dans les grandes lignes, hors crypto, tls et tout ça)
mode server
port 12345
proto udp4
tun-mtu 1500
dev tap
client-to-client
ifconfig 192.168.10.1 255.255.255.0
ifconfig-pool 192.168.10.2 192.168.10.32 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.10.0 255.255.255.0 192.168.10.1"
…
Attention, le "serveur DHCP" du serveur VPN fourni les adresses de .1 à .32 pour les clients VPN (LANvpn). Le serveur DHCP du Routeur de LAN4G fourni les adresses des devices locaux du LAN4G...
Une autre possibilité, fonctionne idem, mais moins configurable au niveau des adresses fournie par le serveur aux clients :
port 12345
proto udp4
tun-mtu 1500
dev tap
topology subnet
server 192.168.10.0 255.255.255.0
push "route 192.168.10.0 255.255.255.0 192.168.10.1"
client-to-client
…
Configuration des clients:
client
proto udp4
remote 82.xxx.xxx.xxx 12345
tun-mtu 1500
dev tap
pull
…
Coté PClinux :
Le client VPN va créer une interface tap0.
Pour que PCuser (de LANuser) voit tous les organes du LAN4G, en passant par le lien LANvpn de PClinux,
il faut créer, sur PClinux, un pont virtuel br0 lié avec tap0 et enp1s0 pour atteindre le Routeur 4G de LAN4G.
ip link add name br0 type bridge
ip addr flush dev tap0
ip link set dev tap0 master br0
ip addr flush dev enp1s0
ip link set dev enp1s0 master br0
ip addr add 192.168.10.201/24 brd + dev br0
ip link set dev br0 up
ip route add default via 192.168.10.254 dev br0
Evidemment, il faut démarrer le client vpn avant et faire tout ça dans un bash…
Coté PCuser :
Ras !
Juste choisir un client VPN compatible mode TAP !
"OpenVPN GUI" pour moi…
-------------------------------------
Bon, tout ça marche, M A I S :
-------------------------------------
Point UN :
Malgré les option "tun-mtu 1500"
J’ai cette erreur coté serveur VPN :
WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1532', remote='tun-mtu 1500'
C’est pas clean ça!... Si quelqu’un à une idée…
Point DEUX : Plus gênant.
Le PCuser (Windows11), (192.168.1.222/24) accède correctement à Internet en local (via sa passerelle 192.168.1.254/24).
Mais quand il est connecté en client VPN (192.168.10.3) au serveur VPN (192.168.10.1), configuré sans les options
push "redirect-gateway..." ni push "dhcp-option..."
le PC accède bien à Internet en local (via sa passerelle 192.168.1.254),
mais les noms DNS ne sont pas résolus !
J'ai forcé le serveur DNS local en 1.1.1.1, mais rien n'y fait !
Voici plus de détails, si vous avez une idée, je suis preneur !
ping 1.1.1.1 ou 8.8.8.8 ou autres répond OK. PCuser vois bien Internet.
ipconfig /all
Carte inconnue Connexion au réseau local :
Suffixe DNS propre à la connexion. . . :
Description. . . . . . . . . . . . . . : TAP-Windows Adapter V9 #2
Adresse physique . . . . . . . . . . . : 00-FF-0F-1A-33-47
DHCP activé. . . . . . . . . . . . . . : Oui
Configuration automatique activée. . . : Oui
Adresse IPv6 de liaison locale. . . . .: fe80::9325:a46b:e3cb:a08c%37(préféré)
Adresse IPv4. . . . . . . . . . . . . .: 192.168.10.3(préféré)
Masque de sous-réseau. . . . . . . . . : 255.255.255.0
Bail obtenu. . . . . . . . . . . . . . : mercredi 21 août 2024 21:45:40
Bail expirant. . . . . . . . . . . . . : jeudi 21 août 2025 21:45:39
Passerelle par défaut. . . . . . . . . :
Serveur DHCP . . . . . . . . . . . . . : 192.168.10.0
IAID DHCPv6 . . . . . . . . . . . : 620822287
DUID de client DHCPv6. . . . . . . . : 00-01-00-01-2A-7A-B1-15-B0-4F-13-E9-97-D4
Serveurs DNS. . . . . . . . . . . . . : 1.1.1.1
NetBIOS sur Tcpip. . . . . . . . . . . : Activé
Carte Ethernet Ethernet :
Suffixe DNS propre à la connexion. . . :
Description. . . . . . . . . . . . . . : Realtek USB FE Family Controller
Adresse physique . . . . . . . . . . . : D0-C0-BF-2D-8E-20
DHCP activé. . . . . . . . . . . . . . : Non
Configuration automatique activée. . . : Oui
Adresse IPv6. . . . . . . . . . . . . .: 2a01:e0a:1b7:b7a0:4ce6:a0e5:b94a:a70e(préféré)
Adresse IPv6 temporaire . . . . . . . .: 2a01:e0a:1b7:b7a0:1c10:1e4d:1d4f:d9d9(préféré)
Adresse IPv6 de liaison locale. . . . .: fe80::9399:1f24:d29e:5c4f%20(préféré)
Adresse IPv4. . . . . . . . . . . . . .: 192.168.1.222(préféré)
Masque de sous-réseau. . . . . . . . . : 255.255.255.0
Passerelle par défaut. . . . . . . . . : fe80::2266:cfff:fe76:a567%20
192.168.1.254
IAID DHCPv6 . . . . . . . . . . . : 1154531519
DUID de client DHCPv6. . . . . . . . : 00-01-00-01-2A-7A-B1-15-B0-4F-13-E9-97-D4
Serveurs DNS. . . . . . . . . . . . . : 8.8.8.8
1.1.1.1
NetBIOS sur Tcpip. . . . . . . . . . . : Activé
(J'ai aussi essayé avec 192.168.1.254 en serveur DNS...)
nslookup www.google.fr
DNS request timed out.
timeout was 2 seconds.
Serveur : UnKnown
Address: 1.1.1.1
DNS request timed out.
timeout was 2 seconds.
...
*** Le délai de la requête sur UnKnown est dépassé.
wget www.google.fr
wget : Le nom distant n'a pas pu être résolu: 'www.google.fr'
Au caractère Ligne:1 : 1
+ wget www.google.fr
+ ~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation : (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
tracert 8.8.8.8 (idem pour 1.1.1.1)
Détermination de l’itinéraire vers 8.8.8.8 avec un maximum de 30 sauts.
1 1 ms 1 ms 1 ms 192.168.1.254
2 11 ms * * 194.149.174.110
3 12 ms * 11 ms 194.149.174.100
4 * * * Délai d’attente de la demande dépassé.
5 12 ms 12 ms 11 ms 62.115.174.29
6 12 ms 12 ms 12 ms 216.239.40.73
7 13 ms 12 ms 12 ms 142.250.224.93
8 12 ms 11 ms 12 ms 8.8.8.8
route print
===========================================================================
Liste d'Interfaces
37...00 ff 0f 1a 33 47 ......TAP-Windows Adapter V9 #2
25...........................Wintun Userspace Tunnel
19...00 ff b6 e9 1b b0 ......TAP-Windows Adapter V9
3...........................OpenVPN Data Channel Offload
49...00 ff d9 b1 06 f4 ......TAP-Windows Adapter V9 #3
54...00 ff 6a 12 7f 06 ......TAP-Windows Adapter V9 #4
20...d0 c0 bf 2d 8e 20 ......Realtek USB FE Family Controller
12...f8 9e 94 ce a8 46 ......Bluetooth Device (Personal Area Network)
1...........................Software Loopback Interface 1
44...00 15 5d 76 97 67 ......Hyper-V Virtual Ethernet Adapter
===========================================================================
IPv4 Table de routage
===========================================================================
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique
0.0.0.0 0.0.0.0 192.168.1.254 192.168.1.222 291
127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
172.26.0.0 255.255.240.0 On-link 172.26.0.1 5256
172.26.0.1 255.255.255.255 On-link 172.26.0.1 5256
172.26.15.255 255.255.255.255 On-link 172.26.0.1 5256
192.168.1.0 255.255.255.0 On-link 192.168.1.222 291
192.168.1.222 255.255.255.255 On-link 192.168.1.222 291
192.168.1.255 255.255.255.255 On-link 192.168.1.222 291
192.168.10.0 255.255.255.0 On-link 192.168.10.3 259
192.168.10.0 255.255.255.0 192.168.10.1 192.168.10.3 259
192.168.10.3 255.255.255.255 On-link 192.168.10.3 259
192.168.10.255 255.255.255.255 On-link 192.168.10.3 259
224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
224.0.0.0 240.0.0.0 On-link 192.168.1.222 291
224.0.0.0 240.0.0.0 On-link 172.26.0.1 5256
224.0.0.0 240.0.0.0 On-link 192.168.10.3 259
255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
255.255.255.255 255.255.255.255 On-link 192.168.1.222 291
255.255.255.255 255.255.255.255 On-link 172.26.0.1 5256
255.255.255.255 255.255.255.255 On-link 192.168.10.3 259
===========================================================================
Itinéraires persistants :
Adresse réseau Masque réseau Adresse passerelle Métrique
0.0.0.0 0.0.0.0 192.168.192.254 Par défaut
0.0.0.0 0.0.0.0 192.168.1.254 Par défaut
===========================================================================
arp -a
Interface : 192.168.1.222 --- 0x14
Adresse Internet Adresse physique Type
192.168.1.5 20-66-cf-79-52-db dynamique
192.168.1.8 f8-da-0c-7a-cc-54 dynamique
192.168.1.151 00-0c-29-24-48-d3 dynamique
192.168.1.254 20-66-cf-76-a5-67 dynamique
192.168.1.255 ff-ff-ff-ff-ff-ff statique
224.0.0.2 01-00-5e-00-00-02 statique
224.0.0.22 01-00-5e-00-00-16 statique
224.0.0.251 01-00-5e-00-00-fb statique
224.0.0.252 01-00-5e-00-00-fc statique
239.255.255.250 01-00-5e-7f-ff-fa statique
239.255.255.253 01-00-5e-7f-ff-fd statique
Interface : 192.168.10.3 --- 0x25
Adresse Internet Adresse physique Type
192.168.10.1 0a-81-2b-dd-9b-b8 dynamique
192.168.10.255 ff-ff-ff-ff-ff-ff statique
224.0.0.2 01-00-5e-00-00-02 statique
224.0.0.22 01-00-5e-00-00-16 statique
224.0.0.251 01-00-5e-00-00-fb statique
224.0.0.252 01-00-5e-00-00-fc statique
239.255.255.250 01-00-5e-7f-ff-fa statique
239.255.255.253 01-00-5e-7f-ff-fd statique
255.255.255.255 ff-ff-ff-ff-ff-ff statique
Interface : 172.26.0.1 --- 0x2c
Adresse Internet Adresse physique Type
172.26.15.255 ff-ff-ff-ff-ff-ff statique
224.0.0.2 01-00-5e-00-00-02 statique
224.0.0.22 01-00-5e-00-00-16 statique
224.0.0.251 01-00-5e-00-00-fb statique
239.255.255.250 01-00-5e-7f-ff-fa statique
239.255.255.253 01-00-5e-7f-ff-fd statique
255.255.255.255 ff-ff-ff-ff-ff-ff statique
MERCI !
Modifié le 22 août 2024 à 10:41
Je suis étonné par tes adresses 192.168.10.20, 192.168.10.21. Ce sont des adresses attribuées par le serveur DHCP du VPS?
.
Pour le souci DNS sur PCuser:
- as tu essayé nslookup vers 8.8.8.8?
- bizarre d'avoir un serveur DNS (1.1.1.1) sur l'interface du tap
- peux-tu pinger 1.1.1.1 via le tap et via Ethernet? (en utilisant l'option -S)
Modifié le 22 août 2024 à 10:37
(
@yg_be:
Merci d'être encore là avec moi !
Les .20 et .21 sont en dure dans ces devices sur LAN4G (rappel: ce sont mes fameux PLC et drives en couche 2)
T'inquiet, j'ai corrigé le problème de DNS (pas un problème dhcp) et plus de serveur DNS sur le TAP client (c'etait pour test)
)
.
(
Oups ! En effet, petit problème: mon serveur DHCP du VPN est en plein dans la plage des .20 et .21 ! LOL.
Mais je vais refaire tout ca bien après !!
)
.
Bon,
.
Pour l'accès DNS (Point 2) c'est ok.
Il suffisait (dans le fichier client VPN Windows) de supprimer l'option "setenv opt block-outside-dns"
Du coup supprimer aussi "ignore-unknown-option block-outside-dns"
.
Cette option "block-outside-dns" ne sert que dans le cas de Windows pour résoudre des problème de DNS.
Mais dans mon cas (TAP et Internet hors VPN) il ne faut pas cette option "anti-problème" qui cause des problèmes !! lol !
.
Pour le MTU (Point 2) :
Bin... J'ai joué avec tun-mtu, link-mtu, mssfix et la doc...
Rien n'y fait ! j'ai toujours coté serveur:
"WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1532', remote='tun-mtu 1500'"
.
Et c'est idem pour le client PClinux !
.
Help ! (bon ok, ça marche, mais c'est pas propre non ?)
22 août 2024 à 10:54
Je ne m'inquiéterais pas de l'avertissement à propos des mtu, tant que le trafic fonctionne.
.
Tu peux utiliser "ping -l 2000" pour vérifier que de "longs" messages transitent bien entre chacun.
22 août 2024 à 10:43
Salut,
super ....
je pense que ceci:
Itinéraires persistants :
Adresse réseau Masque réseau Adresse passerelle Métrique
0.0.0.0 0.0.0.0 192.168.192.254 Par défaut
0.0.0.0 0.0.0.0 192.168.1.254 Par défaut
est à supprimer, surtout le premier, mais le second aussi si le PC est destiné à voyager.
Les push route aussi ne servent à rien (interfaces directement connectées) et sont contre productifs en tap .
l'histoire de MTU, il vaut mieux ne rien indiquer, je suppose, surtout qu'un MTU de 1500 ça n'existe pas sur le WAN, ce sera toujours moins, en fait je n'ai aucune idée des MTU sur un réseau mobile.
22 août 2024 à 13:03
Bon, ok, je laisse tomber ce problème de MTU...
(J'ai le warning même sans rien mettre)
ping -l 5000 192.168.10.xxx fonctionnent bien !
.
@brupala
Merci aussi d'être resté avec moi pendant ces dures heures de labeur !
.
Pour les Itinéraires persistants :
0.0.0.0 0.0.0.0 192.168.192.254 Par défaut
0.0.0.0 0.0.0.0 192.168.1.254 Par défaut
C'est sur mon PCuser ! J'y suis pour rien moi ! Si ?
Je pense que c'est mon PC qui se promème tantôt au boulot (192.168.192.254) tantôt chez moi (192.168.1.254) qui fait que j'ai ça !
Ce dois être lié à la passerelle définie pour l'interface réseau selon l'endroit où je me trouve (dhcp ou fixe...)
Et d'abord, comment je supprimerai ça ?
.
Oui, le push route ne sert à rien, je confirme !
.
.
.
Bon, encore une question (z'inquietez pas, j'approche du "résolu")!
.
Pour mes tests, j'ai tout supprimer les pare-feux.
Que faut-il faire pour securiser à minima ?
J'en ai un peu marre là ! Si vous avez des commande toutes prêtes... !! lol !
en iptables ou nft, je suis pas du tout expert, mais je sais convertir (bon pas moi, un gentil robot...)
On est via un VPN et du 4G, donc pas trop de faille je suppose...
.
Merci encore!
22 août 2024 à 13:20
"On est via un VPN et du 4G, donc pas trop de faille je suppose..."
effectivement, c'est déjà deux mondes à part, le point faible c'est le VPS je dirais, mais ça n'est pas le plus visible non plus, si on lui dit de ne laisser entrer que openvpn et ssh, ça devrai aller, avec un petit fail2ban pour les casse bonbon.
c'est peut-etre le domaine qui ajoute les routes persistantes, ça ne vient pas tout seul, par défaut elles ne le sont pas, un petit route del -p devrait les supprimer.
22 août 2024 à 21:17
Heureux aussi de rencontrer un visiteur aussi volontaire, curieux et performant au final, ça n'est pas souvent et ça élève le niveau de ce forum, qui a plus souvent tendance à évoluer vers zéro, un grand merci à toi pour tes retours de tests et tes explications, ça fait effectivement avancer tout le monde, je me suis moi même posé des questions qui ne me seraient jamais venues à l'idée :-)
Espérons que , malgré que le sujet soit très particulier, ça servira un jour ou l'autre à un visiteur, de toute façon, on a navigué dans cette discussion et celle qui a précédé sur pas mal de concepts et outils plus génériques.
un éclat de soleil cette discussion, certainement que peu de gens peuvent la suivre, mais ils ont beaucoup d'éléments pour comprendre avec un peu de recherches :-)
23 août 2024 à 12:07
Merci !