Routage avec VPN OpenVPN.
Fermé
Kilou
-
25 août 2015 à 15:21
brupala Messages postés 109453 Date d'inscription lundi 16 juillet 2001 Statut Membre Dernière intervention 25 avril 2024 - 27 août 2015 à 10:12
brupala Messages postés 109453 Date d'inscription lundi 16 juillet 2001 Statut Membre Dernière intervention 25 avril 2024 - 27 août 2015 à 10:12
A voir également:
- Routage avec VPN OpenVPN.
- Vpn gratuit - Guide
- Vpn comment ça marche - Guide
- Bright vpn - Télécharger - Confidentialité
- Tuxler vpn - Télécharger - Confidentialité
- Vpn edge - Guide
2 réponses
brupala
Messages postés
109453
Date d'inscription
lundi 16 juillet 2001
Statut
Membre
Dernière intervention
25 avril 2024
13 623
Modifié par brupala le 26/08/2015 à 10:18
Modifié par brupala le 26/08/2015 à 10:18
Salut,
oui, c'est le bon moyen si c'est le DC qui contrôle aussi l'accès à internet.
configure ton serveur openvpn pour qu'il envoie l'adresse du contrôleur de domaine en dns et passerelle par défaut aux postes nomades, pas sa propre adresse.
ils faut que les pstes nomades soient configurés comme si il étaient dans le lan, mais sur le réseau 10
Mais, je verrais plutôt 2 vpn:
1 premier entre le DC et le serveur openvpn, réseau ip différent de ceux des postes nomades, qui seraient dans un autre réseau IP.
ça permettrait de garder le serveur vpn en routeur, de toute façon, les paquets passent toujours par lui.
et ... Voili Voilou Voila !
oui, c'est le bon moyen si c'est le DC qui contrôle aussi l'accès à internet.
configure ton serveur openvpn pour qu'il envoie l'adresse du contrôleur de domaine en dns et passerelle par défaut aux postes nomades, pas sa propre adresse.
ils faut que les pstes nomades soient configurés comme si il étaient dans le lan, mais sur le réseau 10
Mais, je verrais plutôt 2 vpn:
1 premier entre le DC et le serveur openvpn, réseau ip différent de ceux des postes nomades, qui seraient dans un autre réseau IP.
ça permettrait de garder le serveur vpn en routeur, de toute façon, les paquets passent toujours par lui.
et ... Voili Voilou Voila !
kelux
Messages postés
3065
Date d'inscription
vendredi 18 juin 2004
Statut
Contributeur
Dernière intervention
20 janvier 2023
432
Modifié par kelux le 26/08/2015 à 12:14
Modifié par kelux le 26/08/2015 à 12:14
Hello,
Je réponds rapidement, je reviendrai ici plus tard.
Un Domain Controller ne doit pas porter plusieurs IPs, et par conséquent ne doit pas faire non plus routeur, et encore moins être client VPN ou passerelle VPN.
Le DC doit avoir une seule IP et ne doit faire rien d'autre que DC+DNS
(le DC va être vu par quelle IP ? celle VPN ou celle du LAN ? comment ça se bricole coté DNS, vu que AD est basé sur DNS, le DC renvoit quelle IP lors d'une requete DNS sur le nom de domaine ? 172.x ou 10.x ? quel comportement pour les machines en VPN et machines locales dans l'un et/ou l'autre des cas .... ? ) ;-)
Il faut revoir l'architecture au moins pour cette partie, vu que c'est le sujet "intégrer des machines clientes mobile dans AD au travers d'un VPN". Jouer avec le fichier Host est à oublier au plus vite également, surtout dans un monde AD, ce n'est pas pérenne du tout.
Il faut faire un VPN en Lan-to-lan (fixe) entre les deux "datacenters", et gérer l'accès des mobiles en "RoadWarrior" (je ne sais pas si ce terme existe toujours).
Le schéma est à revoir, et à préciser notamment avec les routeurs impliqués, plus de détails sur ce qu'est une "IP dédiée" -> privée/publique...
@+
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
Je réponds rapidement, je reviendrai ici plus tard.
Un Domain Controller ne doit pas porter plusieurs IPs, et par conséquent ne doit pas faire non plus routeur, et encore moins être client VPN ou passerelle VPN.
Le DC doit avoir une seule IP et ne doit faire rien d'autre que DC+DNS
(le DC va être vu par quelle IP ? celle VPN ou celle du LAN ? comment ça se bricole coté DNS, vu que AD est basé sur DNS, le DC renvoit quelle IP lors d'une requete DNS sur le nom de domaine ? 172.x ou 10.x ? quel comportement pour les machines en VPN et machines locales dans l'un et/ou l'autre des cas .... ? ) ;-)
Il faut revoir l'architecture au moins pour cette partie, vu que c'est le sujet "intégrer des machines clientes mobile dans AD au travers d'un VPN". Jouer avec le fichier Host est à oublier au plus vite également, surtout dans un monde AD, ce n'est pas pérenne du tout.
Il faut faire un VPN en Lan-to-lan (fixe) entre les deux "datacenters", et gérer l'accès des mobiles en "RoadWarrior" (je ne sais pas si ce terme existe toujours).
Le schéma est à revoir, et à préciser notamment avec les routeurs impliqués, plus de détails sur ce qu'est une "IP dédiée" -> privée/publique...
@+
Using a registry "compactor" on top of a registry "cleaner" would be equivalent to rinsing your throat with a swig of Jack Daniels after swallowing a pint of snake oil....
brupala
Messages postés
109453
Date d'inscription
lundi 16 juillet 2001
Statut
Membre
Dernière intervention
25 avril 2024
13 623
26 août 2015 à 12:17
26 août 2015 à 12:17
Salut,
tu peux nous expliquer pourquoi un DC ne DOIT pas être routeur ?
Personnellement,
je ne vois pas de raison à priori.
tu peux nous expliquer pourquoi un DC ne DOIT pas être routeur ?
Personnellement,
je ne vois pas de raison à priori.
kelux
Messages postés
3065
Date d'inscription
vendredi 18 juin 2004
Statut
Contributeur
Dernière intervention
20 janvier 2023
432
Modifié par kelux le 26/08/2015 à 14:41
Modifié par kelux le 26/08/2015 à 14:41
Oui bien sur, j'allais le faire, en prenant le temps ;-)
Le fait d'avoir plusieurs IPs sur un DC s'appelle du multi-homing en anglais. Il y a pas mal d'articles qui présentent les problèmes rencontrés et des contournements dans certains cas très spécifiques. Le fait de le rendre routeur dans cet exemple, va faire que le DC aura plusieurs IPs.
En gros le multihome apporte plus de problèmes qu'il ne permet d'en résoudre, et complexifie la configuration du DC.
La principale raison vient des problèmes de résolution DNS. Le DC avec deux IPs va vouloir enregistrer ses 2 IPs pour son nom (son record A, qui permet de trouver les NS de la zone, et le SOA, ainsi que les CNAME dans la zone _MSDCS).
Prenons, DC01 qui est contrôleur de test.local. Son FQDN est DC01.test.local.
Il a 2 IPs, 192.168.0.1 et 10.1.0.1, sur deux cartes réseaux (et/ou sur la même...)
Le DCs va tout seul, enregistrer ses IPs dans le DNS, de manière automatique.
Mais quelle va être l'IP qui sera retournée lors de la résolution DNS de DC01.test.local ?
192.168.0.1 ou 10.1.0.1 ?
Si un client sur le LAN 192.168.0.x reçoit 10.1.0.1 comme réponse DNS, il cherchera à joindre le DC sur cette IP (pour s'authentifier notamment ...), est ce que le réseau 10.1.0.x est bien routable et accessible par le client ? C'est pas sur du tout.
Malgré tout si le client avait obtenu l'adresse en 192.168.0.1 en réponse, étant sur le même réseau, il aurait pu contacter le DC sans problème.
- même remarque pour un client sur le réseau en 10.x.x.x qui obtient 192.168.0.1 en résolution DNS pour le domaine/DC, est il capable de le joindre, routage/filtrage .... sachant que que le filtrage est un point essentiel lorsque l'on connait tous les ports AD requis dans un firewall.
Le souci c'est qu'à tour de rôle les IPs du DCs seront enregistrées dans le DNS (et l'on remercie le service Netlogon qui aide :p ), un coup ça sera 192.168.0.1 et le coup d'après 10.1.0.1 ; il n'y a pas moyen de choisir quelle réponse sera donnée en fonction du client ou du réseau source.
Il y a le même type de problème avec d'autres DCs, qui chercheraient à répliquer avec ce DC à plusieurs IPs, si les DCs obtiennent 10.1.0.1, sont ils capables de taper dessus directement ?
Cela va causer de sérieux soucis pour les autres contrôleurs de domaine qui tenteront de joindre le DC en question avec les autres IPs, qui peuvent être filtrées ou simplement non routables.
Exemple, on installe VMWare sur le DC01 (il ne faut pas le faire hein, c'est un exemple).
On a 2 réseaux virtuels dans VMware pour du test et on mets des VMS dedans, ça va créer des cartes LAN supplémentaires et on "devrait" y paramétrer des IPs, le DC va avoir plusieurs IPs.
DC01 :
LAN01 : 192.168.0.1 (LAN PROD)
LAN02 : 10.1.0.1 (LAN VM)
LAN03 : 10.2.0.1 (LAN TEST VM)
Imaginons ensuite DC02, qui lui est configuré normalement avec son IP de PROD sur 192.168.0.2.
Il essaie de répliquer avec DC01 "les data Active Directory", il va d'abord résoudre son nom en IP avec une résolution DNS directe. (nslookup dc01.test.local)
Il obtient l'IP 10.2.0.1 pour sa requête (pas de bol)
Il tente ensuite de se connecter sur 10.2.0.1, timeout car non routable -> erreur.
Il faut imaginer que cela pose aussi problème lors des mises à jour des zones DNS qui seront répliquées via AD.
D'après mon expérience, 75% des problèmes liés à AD sont liés à des problèmes DNS. Le multihome ne fait qu'augmenter cette probabilité.
-
C'est un peu vieux comme lien, mais toujours applicable ...
https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/active-directory-communication-fails
https://support.microsoft.com/en-us/help/832478
-
Il y a des contournements à faire mais c'est très spécifique (LAN de backup ou d'admin par exemple; mais Interface VPN ça ne s'applique pas ici, car on suppose que les clients VPN utiliseront l'adresse remote du DC pour communiquer avec lui, ce qui n'est pas forcément vrai à cause des requetes DNS...)
Le fait d'avoir plusieurs IPs sur un DC s'appelle du multi-homing en anglais. Il y a pas mal d'articles qui présentent les problèmes rencontrés et des contournements dans certains cas très spécifiques. Le fait de le rendre routeur dans cet exemple, va faire que le DC aura plusieurs IPs.
En gros le multihome apporte plus de problèmes qu'il ne permet d'en résoudre, et complexifie la configuration du DC.
La principale raison vient des problèmes de résolution DNS. Le DC avec deux IPs va vouloir enregistrer ses 2 IPs pour son nom (son record A, qui permet de trouver les NS de la zone, et le SOA, ainsi que les CNAME dans la zone _MSDCS).
Prenons, DC01 qui est contrôleur de test.local. Son FQDN est DC01.test.local.
Il a 2 IPs, 192.168.0.1 et 10.1.0.1, sur deux cartes réseaux (et/ou sur la même...)
Le DCs va tout seul, enregistrer ses IPs dans le DNS, de manière automatique.
Mais quelle va être l'IP qui sera retournée lors de la résolution DNS de DC01.test.local ?
192.168.0.1 ou 10.1.0.1 ?
Si un client sur le LAN 192.168.0.x reçoit 10.1.0.1 comme réponse DNS, il cherchera à joindre le DC sur cette IP (pour s'authentifier notamment ...), est ce que le réseau 10.1.0.x est bien routable et accessible par le client ? C'est pas sur du tout.
Malgré tout si le client avait obtenu l'adresse en 192.168.0.1 en réponse, étant sur le même réseau, il aurait pu contacter le DC sans problème.
- même remarque pour un client sur le réseau en 10.x.x.x qui obtient 192.168.0.1 en résolution DNS pour le domaine/DC, est il capable de le joindre, routage/filtrage .... sachant que que le filtrage est un point essentiel lorsque l'on connait tous les ports AD requis dans un firewall.
Le souci c'est qu'à tour de rôle les IPs du DCs seront enregistrées dans le DNS (et l'on remercie le service Netlogon qui aide :p ), un coup ça sera 192.168.0.1 et le coup d'après 10.1.0.1 ; il n'y a pas moyen de choisir quelle réponse sera donnée en fonction du client ou du réseau source.
Il y a le même type de problème avec d'autres DCs, qui chercheraient à répliquer avec ce DC à plusieurs IPs, si les DCs obtiennent 10.1.0.1, sont ils capables de taper dessus directement ?
Cela va causer de sérieux soucis pour les autres contrôleurs de domaine qui tenteront de joindre le DC en question avec les autres IPs, qui peuvent être filtrées ou simplement non routables.
Exemple, on installe VMWare sur le DC01 (il ne faut pas le faire hein, c'est un exemple).
On a 2 réseaux virtuels dans VMware pour du test et on mets des VMS dedans, ça va créer des cartes LAN supplémentaires et on "devrait" y paramétrer des IPs, le DC va avoir plusieurs IPs.
DC01 :
LAN01 : 192.168.0.1 (LAN PROD)
LAN02 : 10.1.0.1 (LAN VM)
LAN03 : 10.2.0.1 (LAN TEST VM)
Imaginons ensuite DC02, qui lui est configuré normalement avec son IP de PROD sur 192.168.0.2.
Il essaie de répliquer avec DC01 "les data Active Directory", il va d'abord résoudre son nom en IP avec une résolution DNS directe. (nslookup dc01.test.local)
Il obtient l'IP 10.2.0.1 pour sa requête (pas de bol)
Il tente ensuite de se connecter sur 10.2.0.1, timeout car non routable -> erreur.
Il faut imaginer que cela pose aussi problème lors des mises à jour des zones DNS qui seront répliquées via AD.
D'après mon expérience, 75% des problèmes liés à AD sont liés à des problèmes DNS. Le multihome ne fait qu'augmenter cette probabilité.
-
C'est un peu vieux comme lien, mais toujours applicable ...
https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/active-directory-communication-fails
https://support.microsoft.com/en-us/help/832478
-
Il y a des contournements à faire mais c'est très spécifique (LAN de backup ou d'admin par exemple; mais Interface VPN ça ne s'applique pas ici, car on suppose que les clients VPN utiliseront l'adresse remote du DC pour communiquer avec lui, ce qui n'est pas forcément vrai à cause des requetes DNS...)
brupala
Messages postés
109453
Date d'inscription
lundi 16 juillet 2001
Statut
Membre
Dernière intervention
25 avril 2024
13 623
>
kelux
Messages postés
3065
Date d'inscription
vendredi 18 juin 2004
Statut
Contributeur
Dernière intervention
20 janvier 2023
26 août 2015 à 15:04
26 août 2015 à 15:04
OK, merci.
Autant j'admet la chose dans le cas de vmware (ou autre hyperviseur) qui va générer des adresses en host only à la pelle.
Autant ça me parait gérable en empêchant les inscriptions automatiques au dns, donc une seule adresse bien fixe pour le DC, bien routée et pas filtrée pour les autres connexions.
On peut toujours contrôler les inscriptions automatiques au dns, ou pas ?
Autant j'admet la chose dans le cas de vmware (ou autre hyperviseur) qui va générer des adresses en host only à la pelle.
Autant ça me parait gérable en empêchant les inscriptions automatiques au dns, donc une seule adresse bien fixe pour le DC, bien routée et pas filtrée pour les autres connexions.
On peut toujours contrôler les inscriptions automatiques au dns, ou pas ?
kelux
Messages postés
3065
Date d'inscription
vendredi 18 juin 2004
Statut
Contributeur
Dernière intervention
20 janvier 2023
432
Modifié par kelux le 26/08/2015 à 16:05
Modifié par kelux le 26/08/2015 à 16:05
Oui on peut le faire, mais "parfois" netlogon en fait à sa tête et enregistre toutes les IPs des cartes réseaux ...
Vu la complexité de configurer d'une part les cartes réseaux pour désactiver la mise à jour auto, et d'autre part la configuration du service DNS (il faut que seule l'ip de Prod bind pour le service DNS) ; on ajoute du complexe pour rien ... sans pour autant avoir la garantie que ce soit pérenne.
Même si dans les faits et selon certains critères , on peut faire du multihome, Microsoft "ne supporte pas" cette solution (disons "ne préconise pas"), il tolère juste.
Vu la complexité de configurer d'une part les cartes réseaux pour désactiver la mise à jour auto, et d'autre part la configuration du service DNS (il faut que seule l'ip de Prod bind pour le service DNS) ; on ajoute du complexe pour rien ... sans pour autant avoir la garantie que ce soit pérenne.
Même si dans les faits et selon certains critères , on peut faire du multihome, Microsoft "ne supporte pas" cette solution (disons "ne préconise pas"), il tolère juste.
Merci pour vos réponses, ca va pal mal m'aider :)
Donc en effet y'avait pas mal de problème avec le DNS comme souligné par kelux notamment par rapport au DC et l'auto_discover de l'exchange , du coup je pense simplement partir sur une machine dédié a la passerelle DNS, donc un client OpenVPN qui fait le routage entre 10.x.x.x et 172.16.x.x.
http://www.hostingpics.net/viewer.php?id=202457vpn.jpg
Pourquoi serait il intéressant de faire 2 VPN (un entre la passerelle et le serveur et un pour les clients VPN)?
Pour les clients je pensais leurs mettre une route statique 172.16.x.x en passant par l'adresse VPN de la passerelle, c'est bon?
merci beaucoup en tout cas :)
Donc en effet y'avait pas mal de problème avec le DNS comme souligné par kelux notamment par rapport au DC et l'auto_discover de l'exchange , du coup je pense simplement partir sur une machine dédié a la passerelle DNS, donc un client OpenVPN qui fait le routage entre 10.x.x.x et 172.16.x.x.
http://www.hostingpics.net/viewer.php?id=202457vpn.jpg
Pourquoi serait il intéressant de faire 2 VPN (un entre la passerelle et le serveur et un pour les clients VPN)?
Pour les clients je pensais leurs mettre une route statique 172.16.x.x en passant par l'adresse VPN de la passerelle, c'est bon?
merci beaucoup en tout cas :)
