Accéder à un appareil réseau via un autre réseau
Fermé
bleu_0842
Messages postés
5
Date d'inscription
dimanche 24 mai 2020
Statut
Membre
Dernière intervention
25 mai 2020
-
24 mai 2020 à 17:05
brupala Messages postés 110751 Date d'inscription lundi 16 juillet 2001 Statut Membre Dernière intervention 7 janvier 2025 - 25 mai 2020 à 16:10
brupala Messages postés 110751 Date d'inscription lundi 16 juillet 2001 Statut Membre Dernière intervention 7 janvier 2025 - 25 mai 2020 à 16:10
A voir également:
- Accéder à un appareil réseau via un autre réseau
- Entrer les informations d'identification reseau - Guide
- Comment s'appelle l’adresse qui est attribuée à un appareil quand il se connecte à internet et qui permet de l'identifier sur le réseau ? - Guide
- Cable reseau du player freebox - Forum Freebox
- Appareil connecté facebook - Guide
3 réponses
avion-f16
Messages postés
19250
Date d'inscription
dimanche 17 février 2008
Statut
Contributeur
Dernière intervention
22 décembre 2024
4 505
Modifié le 25 mai 2020 à 00:48
Modifié le 25 mai 2020 à 00:48
Bonjour,
Sur le routeur #1, n'as-tu pas la possibilité de changer le sous-réseau du LAN ?
Il faut pour cela modifier la configuration IP du routeur sur son interface LAN, mais aussi adapter les paramètres du serveur DHCP afin que les ordinateurs prennent une IP dans la nouveau sous-réseau.
Cela simplifierait grandement le problème...
Sinon, il y a moyen de s'en sortir mais c'est du bidouillage (NETMAP avec iptables).
Une fois le problème du sous-réseau commun résolu :
Cas A: full tunneling
Dans cette configuration, le client (PC Windows côté routeur 2) voit sa table de routage adaptée comme suit :
- 192.168.2.0/24 via son NIC physique
- IPVPN/32 via 192.168.2.1
- Tout le reste via 10.0.0.1 dev tun0
=> Selon cette table, alors 192.168.1.5 passe via tun0 (VPN)
Cas B: split tunneling
La table de routage du client VPN reste presque inchangée :
- default via 192.168.2.1
- 192.168.2.0/24 via dev eth0
- 10.0.0.0/24 via dev tun0
- On ajoute : 192.168.1.0/24 via 10.0.0.1 dev tun0
=> 192.168.1.5 sera également routé via le VPN
Dans les deux cas : il faut aussi assurer le chemin inverse : du DSP vers le client VPN 10.0.0.x.
Un choix, trois possibilités :
1) Sur le RPI, configurer un NAT (MASQUERADE) afin que tous les paquets provenant de 10.0.0.0/24 et sortant du RPi apparaissent sur le LAN #2 comme provenant du RPi (IP source 192.168.1.5). Ainsi, le DSP pourra répondre au client VPN en envoyant des paquets vers l'IP 192.168.1.5.
Dans cette configuration, le RPi permet la communication entre le client VPN et le DSP de la même manière qu'un routeur/NAT permet la communication entre un serveur sur Internet et un ordinateur avec une IP locale => le client VPN peut ouvrir une connexion vers le DSP, mais l'inverse n'est pas possible. Si tu ne souhaites pas que le DSP contacte le client VPN de sa propre initiative, alors cette solution peut être considérée sans problème.
2) Configurer une route statique "10.0.0.0/24 via 192.168.1.4" sur le routeur 2 et alors désactiver le NAT effectué par le RPi pour ses clients VPN
=> Puisque le DSP utilise le routeur 2 comme passerelle par défaut, et puisque le routeur 2 connaît une route pour le sous-réseau du client VPN, et puisque le client VPN a déjà une route vers le DSP, alors les communications entre les deux sous-réseau est possible sans entre les deux.
Cette solution est idéale si tu souhaites une connexion initialisée par le DSP vers le client VPN, sans devoir configurer des redirections de port sur le RPi à cause du NAT.
3) Configurer le DSP afin qu'il utilise le RPi comme passerelle par défaut. Le RPi connait déjà les routes pour 10.0.0.0/24, pour 192.168.1.0/24 ainsi que la route pour le reste (Internet) et peut donc être un candidat pour jouer le rôle de routeur/passerelle.
J'ai sûrement glissé 2-3 sottises, désolé brupala :(
Sur le routeur #1, n'as-tu pas la possibilité de changer le sous-réseau du LAN ?
Il faut pour cela modifier la configuration IP du routeur sur son interface LAN, mais aussi adapter les paramètres du serveur DHCP afin que les ordinateurs prennent une IP dans la nouveau sous-réseau.
Cela simplifierait grandement le problème...
Sinon, il y a moyen de s'en sortir mais c'est du bidouillage (NETMAP avec iptables).
Une fois le problème du sous-réseau commun résolu :
Cas A: full tunneling
Dans cette configuration, le client (PC Windows côté routeur 2) voit sa table de routage adaptée comme suit :
- 192.168.2.0/24 via son NIC physique
- IPVPN/32 via 192.168.2.1
- Tout le reste via 10.0.0.1 dev tun0
=> Selon cette table, alors 192.168.1.5 passe via tun0 (VPN)
Cas B: split tunneling
La table de routage du client VPN reste presque inchangée :
- default via 192.168.2.1
- 192.168.2.0/24 via dev eth0
- 10.0.0.0/24 via dev tun0
- On ajoute : 192.168.1.0/24 via 10.0.0.1 dev tun0
=> 192.168.1.5 sera également routé via le VPN
Dans les deux cas : il faut aussi assurer le chemin inverse : du DSP vers le client VPN 10.0.0.x.
Un choix, trois possibilités :
1) Sur le RPI, configurer un NAT (MASQUERADE) afin que tous les paquets provenant de 10.0.0.0/24 et sortant du RPi apparaissent sur le LAN #2 comme provenant du RPi (IP source 192.168.1.5). Ainsi, le DSP pourra répondre au client VPN en envoyant des paquets vers l'IP 192.168.1.5.
Dans cette configuration, le RPi permet la communication entre le client VPN et le DSP de la même manière qu'un routeur/NAT permet la communication entre un serveur sur Internet et un ordinateur avec une IP locale => le client VPN peut ouvrir une connexion vers le DSP, mais l'inverse n'est pas possible. Si tu ne souhaites pas que le DSP contacte le client VPN de sa propre initiative, alors cette solution peut être considérée sans problème.
2) Configurer une route statique "10.0.0.0/24 via 192.168.1.4" sur le routeur 2 et alors désactiver le NAT effectué par le RPi pour ses clients VPN
=> Puisque le DSP utilise le routeur 2 comme passerelle par défaut, et puisque le routeur 2 connaît une route pour le sous-réseau du client VPN, et puisque le client VPN a déjà une route vers le DSP, alors les communications entre les deux sous-réseau est possible sans entre les deux.
Cette solution est idéale si tu souhaites une connexion initialisée par le DSP vers le client VPN, sans devoir configurer des redirections de port sur le RPi à cause du NAT.
3) Configurer le DSP afin qu'il utilise le RPi comme passerelle par défaut. Le RPi connait déjà les routes pour 10.0.0.0/24, pour 192.168.1.0/24 ainsi que la route pour le reste (Internet) et peut donc être un candidat pour jouer le rôle de routeur/passerelle.
J'ai sûrement glissé 2-3 sottises, désolé brupala :(
brupala
Messages postés
110751
Date d'inscription
lundi 16 juillet 2001
Statut
Membre
Dernière intervention
7 janvier 2025
13 889
24 mai 2020 à 18:36
24 mai 2020 à 18:36
Salut,
le VPN (pour une fois qu'on parle d'un vrai, ça fait plaisir) devrait se trouver en priorité entre les deux routeurs.
Si ils ne gèrent pas,
la framboise n'a qu'un port ethernet, mais il peut gérer des vlans et couplé à un switch qui les gère aussi, ça peut faire beaucoup de ports, de plus il a 4 USB et on doit pouvoir coller des adaptateurs USB/ethernet dessus.
le VPN (pour une fois qu'on parle d'un vrai, ça fait plaisir) devrait se trouver en priorité entre les deux routeurs.
Si ils ne gèrent pas,
la framboise n'a qu'un port ethernet, mais il peut gérer des vlans et couplé à un switch qui les gère aussi, ça peut faire beaucoup de ports, de plus il a 4 USB et on doit pouvoir coller des adaptateurs USB/ethernet dessus.
bleu_0842
Messages postés
5
Date d'inscription
dimanche 24 mai 2020
Statut
Membre
Dernière intervention
25 mai 2020
Modifié par bleu_0842 le 24/05/2020 à 19:57
Modifié par bleu_0842 le 24/05/2020 à 19:57
Je vois, merci avant tout pour votre réponse si rapide ! :)
Donc si je suis vos conseil, il n'y a pas moyen d'accéder à mon DSP via un autre réseau dans cette configuration.
Le DSP doit impérativement être derrière le VPN ?
Il n'y à donc pas moyen ( faible connaissance ) de :
- Se connecter au vpn à partir de mon réseau distant
- De router/traduire/transforme via un quelconque moyen ma requête ( ip en 10.0.0.x ) sur le réseau local distant ( en 192.168.x.x ) via le Raspberry ?
Donc si je suis vos conseil, il n'y a pas moyen d'accéder à mon DSP via un autre réseau dans cette configuration.
Le DSP doit impérativement être derrière le VPN ?
Il n'y à donc pas moyen ( faible connaissance ) de :
- Se connecter au vpn à partir de mon réseau distant
- De router/traduire/transforme via un quelconque moyen ma requête ( ip en 10.0.0.x ) sur le réseau local distant ( en 192.168.x.x ) via le Raspberry ?
brupala
Messages postés
110751
Date d'inscription
lundi 16 juillet 2001
Statut
Membre
Dernière intervention
7 janvier 2025
13 889
>
bleu_0842
Messages postés
5
Date d'inscription
dimanche 24 mai 2020
Statut
Membre
Dernière intervention
25 mai 2020
24 mai 2020 à 20:05
24 mai 2020 à 20:05
Là je ne comprends plus rien à ce que tu racontes,
la journée a été chargée ?
autant la question était claire, autant là ça devient flou.
surtout que là:
Donc si je suis vos conseil, il n'y a pas moyen d'accéder à mon DSP via un autre réseau dans cette configuration.
tu me prêtes des termes que je n'ai pas écrits, donc, tu m'inquiètes.
la journée a été chargée ?
autant la question était claire, autant là ça devient flou.
surtout que là:
Donc si je suis vos conseil, il n'y a pas moyen d'accéder à mon DSP via un autre réseau dans cette configuration.
tu me prêtes des termes que je n'ai pas écrits, donc, tu m'inquiètes.
bleu_0842
Messages postés
5
Date d'inscription
dimanche 24 mai 2020
Statut
Membre
Dernière intervention
25 mai 2020
>
brupala
Messages postés
110751
Date d'inscription
lundi 16 juillet 2001
Statut
Membre
Dernière intervention
7 janvier 2025
Modifié le 24 mai 2020 à 20:31
Modifié le 24 mai 2020 à 20:31
Désolé , je vais tenté d'être plus claire à l'aide d'un autre diagramme.
C'est le meilleur moyen d'arriver à joindre mon dispositif ?
C'est le meilleur moyen d'arriver à joindre mon dispositif ?
brupala
Messages postés
110751
Date d'inscription
lundi 16 juillet 2001
Statut
Membre
Dernière intervention
7 janvier 2025
13 889
>
bleu_0842
Messages postés
5
Date d'inscription
dimanche 24 mai 2020
Statut
Membre
Dernière intervention
25 mai 2020
Modifié le 24 mai 2020 à 22:15
Modifié le 24 mai 2020 à 22:15
Désolé , je vais tenté d'être plus claire
mâle ou femelle ou les deux ou juste pas à cheval sur l'orthografe ?
adresse ipv4 en 678.90 pas fameux non plus, mais bon je pense que c'était juste histoire d'aligner des chiffres, mais bon globalement le plan de numérotation convient, sauf que 2 réseaux locaux distant dans le même réseau ip, ça n'est pas bien gérable, surtout à travers un VPN routé, il faudrait bridger ou changer la numérotation, sans oublier le petit switch manageable entre framboise et DSP.
mâle ou femelle ou les deux ou juste pas à cheval sur l'orthografe ?
adresse ipv4 en 678.90 pas fameux non plus, mais bon je pense que c'était juste histoire d'aligner des chiffres, mais bon globalement le plan de numérotation convient, sauf que 2 réseaux locaux distant dans le même réseau ip, ça n'est pas bien gérable, surtout à travers un VPN routé, il faudrait bridger ou changer la numérotation, sans oublier le petit switch manageable entre framboise et DSP.
bleu_0842
Messages postés
5
Date d'inscription
dimanche 24 mai 2020
Statut
Membre
Dernière intervention
25 mai 2020
>
brupala
Messages postés
110751
Date d'inscription
lundi 16 juillet 2001
Statut
Membre
Dernière intervention
7 janvier 2025
24 mai 2020 à 22:37
24 mai 2020 à 22:37
Désolé , je vais tenté d'être plus claire
Un peu distrait !
adresse ipv4 en 678.90 pas fameux non plus,
Oui, les adresses sont seulement là pour illuster.
sans oublier le petit switch manageable entre framboise et DSP.
Je pense que je vais prendre un adaptateur USB/ethernet plutôt qu'un switch, car je n'aurai que ce DSP à mettre et rien d'autre
Il ne me reste donc plus qu'à me renseigner sur comment bridger mon VPN et ça devrait être bon !
Un peu distrait !
adresse ipv4 en 678.90 pas fameux non plus,
Oui, les adresses sont seulement là pour illuster.
sans oublier le petit switch manageable entre framboise et DSP.
Je pense que je vais prendre un adaptateur USB/ethernet plutôt qu'un switch, car je n'aurai que ce DSP à mettre et rien d'autre
Il ne me reste donc plus qu'à me renseigner sur comment bridger mon VPN et ça devrait être bon !
bleu_0842
Messages postés
5
Date d'inscription
dimanche 24 mai 2020
Statut
Membre
Dernière intervention
25 mai 2020
25 mai 2020 à 00:48
25 mai 2020 à 00:48
Je test tout ça demain, et je reviens vers vous, merci !
25 mai 2020 à 09:05
Il route entre openvpn et le lan, c'est tout.
Il faudra qu'il soit passerelle par défaut du fdp,
Le rpi le routant soit vers le lan soit vers le vpn.
Ah, oui tu veux dire le nat au cas où on ne pourrait pas rajouter de route statique aux machines du lan qui devraient joindre le dsp ?
25 mai 2020 à 15:54
> Oui, juste que je ne vois pas bien intérêt d'un nat sur le raspi.
C'est simple : certains sont sado-maso et aiment mettre des NAT partout ;)
Plus sérieusement : je ne sais pas comment bleu_0842 a installé son serveur OpenVPN, mais il y a de fortes chances qu'un NAT ait été configuré s'il a utilisé un script auto-install ou s'il a suivi des tutoriels (car le cas le plus fréquent est d'utiliser le serveur VPN pour l'accès à Internet), donc autant en profiter si c'est déjà en place :)
Je ne sais pas ce qu'est un DSP, j'ai supposé que le DSP est un périphérique "passif", on y accède au besoin mais lui ne prend pas l'initiative d'ouvrir des connexions, donc le RPi en NAT ne me semble pas une si mauvaise idée si c'est déjà en place, en plus du fait qu'aucune modification du coté du LAN #2 n'est nécessaire : pas de route à ajouter sur le routeur #2, le routeur #2 reste le gateway par défaut pour le RPi et le DSP, donc le LAN #2 (incluant le RPi) peut continuer à accéder au DSP, et les clients VPN peuvent joindre le DSP via le RPi en NAT. Finalement, c'est pas si mal :)
> Ah, oui tu veux dire le nat au cas où on ne pourrait pas rajouter de route statique aux machines du lan qui devraient joindre le dsp ?
Si le DSP utilise le RPi comme passerelle (et donc peut joindre les clients VPN), ne reste-t-il pas accessible par le LAN #2 sachant qu'il reste sur le même segment couche 2 dans le même sous-réseau 192.168.1.0/24 ?
25 mai 2020 à 16:10
Je n'avais pas l'impression que le serveur openvpn était déjà installé sur la framboise.