1 votes

Mêmes routes sous VPN - comment contourner le problème ?

Je n'ai qu'une expérience de base avec les VPN (principalement OpenVPN) et surtout théorique, mais je veux maintenant mettre en place quelque chose de plus complexe et j'évalue les problèmes possibles auxquels je pourrais être confronté. Je vais essayer de représenter la situation hypothétique à l'aide d'exemples. Supposons qu'il s'agisse d'OpenVPN pour cette configuration.

J'ai un serveur principal qui exécutera le client OpenVPN et différents sites distants qui auront différents serveurs OpenVPN. J'ouvrirai différents tunnels en même temps depuis le serveur principal vers ces sites distants. Disons que j'aurai dix tunnels différents ouverts en même temps.

Chacun des tunnels aura une adresse IP locale attribuée au client, par exemple :

10.0.0.2/24 (tunnel A)

10.0.1.2/24 (tunnel B)

10.0.2.2/24 (tunnel C)

...

Ainsi, par exemple, le serveur OpenVPN dans le tunnel A serait 10.0.0.1/24 . Si je veux accéder à une ressource à l'intérieur du réseau local du tunnel A - par exemple, un Apache tournant sur 172.16.0.50 Je n'aurais qu'à entrer l'IP dans l'ordinateur de mon client VPN et j'atteindrais le serveur web (en supposant que toutes les routes soient correctes).

Mon principal souci est d'avoir différents tunnels en même temps et plusieurs services fonctionnant sous la même IP locale. Prenons l'exemple ci-dessus :

Tunnel A : serveur 10.0.0.1/24, client 10.0.0.2/24, Apache 172.16.0.50

Tunnel B : serveur 10.0.1.1/24, client 10.0.1.2/24, Apache 172.16.0.50

Dans cet exemple particulier, nous avons deux instances Apache fonctionnant sur des réseaux différents mais partageant la même adresse IP locale. 172.16.0.50 alors que les deux tunnels sont actifs, je suppose qu'il échouera.

Je ne suis pas sûr que ma supposition soit juste, mais je parie que cette situation n'est pas si atypique. Quelqu'un peut-il m'expliquer ce qu'il faudrait faire dans cette situation ?

EDITAR: Je vous prie de m'excuser si je n'ai pas été assez clair - je vais simplifier le problème en procédant par étapes simples :

  • Deux serveurs VPN (VPN1 & VPN2) et un client VPN
  • VPN1 et VPN2 partagent les mêmes IP LAN pour leurs services internes : 172.16.0.0/24
  • VPN1 et VPN2 ont tous deux un Apache fonctionnant sous 172.16.0.50.
  • Le client VPN se connecte aux deux serveurs VPN (VPN1 et VPN2).
  • Problème -> Les deux ont le même numéro de réseau local (172.16.0.0/24) et Apache tourne exactement sous la même adresse IP.
  • Question -> Y a-t-il un moyen de résoudre ce problème à part changer le LAN (et donc l'IP d'Apache) dans l'un des serveurs VPN ?

1voto

MadHatter Points 77602

Non, il n'existe pas de méthode convaincante et sans problème pour y parvenir.

Au niveau de la couche 3, une fois que les deux tunnels sont en place, le client n'a absolument aucun moyen de distinguer 172.16.0.50-via-tunnel-1 de 172.16.0.50-via-tunnel-2 L'IP ne permet tout simplement pas ce type de prise de décision (à l'exception du routage à la source, qui sera très pénible et mal pris en charge).

Il est possible d'utiliser des moyens détournés : le client pourrait avoir recours à la NAT pour superposer deux plages RFC1918 différentes sur les deux réseaux similaires, et utiliser le routage basé sur des règles pour rendre le trafic plus fluide.

Mais vous devrez alors réécrire tout ce qui fait référence à des adresses de la plage qui se chevauche, en fonction du tunnel par lequel il passe.

Honnêtement, il sera moins pénible de ré-IPer l'un des deux réseaux de destination. Cela aura l'avantage pratique de vous permettre de relier directement les deux réseaux - et s'il est souhaitable pour un client de contacter les deux réseaux, ce n'est qu'une question de temps avant qu'il ne soit souhaitable pour l'entreprise de les interconnecter directement.

Editer : dans la configuration actuelle, le même problème se pose dans cette situation : pour les jede Si une adresse donnée se trouve dans la plage de chevauchement, le client n'a aucun moyen de savoir vers quel tunnel il doit être acheminé. Vous pourriez résoudre ce problème en seulement en donnant des itinéraires aux 172.16.0.50 via le tunnel 1, et 172.16.0.51 via le tunnel 2. Cependant, cette méthode ne sera pas très efficace, à moins que tous les hôtes intéressants d'un réseau local ne se trouvent dans le tunnel 172.16.0.0/25 et tous ceux qui se trouvent dans l'autre sont dans 172.16.0.128/25 . Dans ce cas, le re-IPing ne devrait pas être plus douloureux que de changer le masque de réseau partout.

0voto

marcolz Points 135

Si le trafic est acheminé par le VPN1 par défaut et le VPN2 comme sauvegarde, le fait de diviser la route poussée en 2 plages /25 sur le VPN1 et de pousser le /24 complet sur le VPN2, résoudrait le problème.

Si le VPN1 est en panne et que les 2 routes /25 sont supprimées, il dispose toujours de la route /24 du VPN2, ce qui permet d'obtenir une haute disponibilité, bien que sans équilibrage de la charge.

Ainsi, sur VPN1, vous pourriez faire :

push "route 172.16.0.0 255.255.255.128"
push "route 172.16.0.128 255.255.255.128"

alors que sur VPN2 vous le feriez :

push "route 172.16.0.0 255.255.255.0"

La route la plus "étroite" étant prioritaire, le client préférera VPN1 à VPN2.

Vous pouvez également spécifier une autre méthode côté client, à savoir route-metric dans les configurations des clients, par exemple dans la configuration du client pour VPN1 :

route-metric 200

et dans celui de VPN2 :

route-metric 201

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X