Le serveur VPN Windows peut parler aux clients VPN, mais n'enverra pas de paquets de son réseau local aux clients VPN

8

Je souhaite configurer Windows Server 2012 et ses clients VPN Windows 7 et Windows 8 avec un VPN SSTP qui utilise la tunnellisation fractionnée et l'adressage hors sous-réseau, mais je rencontre un problème: le serveur RRAS n'enverra pas de paquets au VPN clients de toute machine autre que lui-même.

Mon serveur VPN fonctionne sur le "Cloud privé virtuel" d'Amazon, il n'a donc qu'une seule carte réseau avec une adresse IP sur un réseau privé RFC1918 partagé avec tous mes autres serveurs Amazon VPC et une adresse IP publique qui transfère tout le trafic vers cette adresse privée. via NAT (Amazon appelle cela "Elastic IP").

J'ai installé RRAS et mis en place un VPN. Le sous-réseau privé sur Amazon est 172.16.0.0/17 (c'est ce que j'appelle le "Amazon LAN"), mais je veux que tous les clients VPN utilisent la plage 10.128.0.0/20 (ce que j'appelle le " VPN LAN ").

Dans mon panneau de configuration Amazon, j'ai fait ce qui suit:

  • Désactivé la vérification source / destination pour le serveur VPN
  • Ajout d'une entrée dans les tables de routage pour le pool 10.128.0.0/20 qui pointe vers l'interface réseau du serveur VPN.

Dans la MMC Routage et accès distant, dans le menu des propriétés du nom du serveur, j'ai fait ce qui suit:

  • Onglet Général -> Routeur IPv4 (coché), activé pour le LAN et le routage à la demande
  • Onglet Général -> Serveur d'accès à distance IPv4 (coché)
  • Onglet IPv4 -> Activer le transfert IPv4 (coché)
  • Onglet IPv4 -> Pool d'adresses statiques, et spécifiez 10.128.0.1-10.128.15.154

Sur mon client et tous mes serveurs, je me suis assuré que ICMP est explicitement autorisé dans le pare-feu, ou que le pare-feu est entièrement désactivé (pas le plan permanent, bien sûr).

Sur le client, pour activer le tunneling fractionné, je suis allé dans les propriétés de la connexion VPN -> Réseau -> IPv4 -> Propriétés -> Avancé -> onglet Paramètres IP, et décochez la case "Utiliser la passerelle par défaut sur le réseau distant", et coché "Désactiver l'ajout d'itinéraire basé sur la classe".

À ce stade, mes clients peuvent se connecter à l'aide du client VPN Windows 7/8. Une IP leur est attribuée à partir du pool 10.128.0.0/20, mais comme ils ne définissent pas automatiquement de route, ils ne peuvent pas parler au réseau distant. Je peux définir des itinéraires vers le réseau distant et vers le réseau VPN, comme ceci (sur le client):

route add 172.16.0.0/17 <VPN IP ADDRESS> 
route add 10.128.0.0/20 <VPN IP ADDRESS>

Le client peut maintenant envoyer une requête ping à l'adresse LAN VPN du serveur VPN (10.128.0.1), ainsi qu'à son adresse LAN Amazon (172.16.1.32). Cela pose cependant un problème lorsque vous essayez de parler à d'autres machines sur le réseau local Amazon: les pings ne reçoivent pas de réponses.

Ainsi, par exemple, si le client essaie d'envoyer une requête ping à un système dont je sais qu'il est en place et répond à des pings comme 172.16.0.113, il ne verra pas ces réponses (il indique "La demande a expiré"). Wireshark sur le serveur VPN confirme qu'il voit le ping du client, et il voit même une réponse envoyée à partir du 172.16.0.113, mais cette réponse ne revient apparemment jamais au client.

De plus, si je cingle l'adresse LAN VPN du client à partir de 172.16.0.113, Wireshark sur le serveur VPN voit le ping, mais ne voit pas de réponse.

Donc, pour récapituler:

  • Le serveur VPN peut envoyer une requête ping à d'autres machines sur le réseau local Amazon (172.16.0.0/17) et recevoir des réponses, et d'autres machines sur ce réseau peuvent faire de même.
  • Un client VPN peut envoyer une requête ping à l'adresse LAN d'Amazon du serveur et recevoir des réponses, une fois que les clients ont ajouté l'itinéraire approprié comme décrit précédemment.
  • Un client VPN peut envoyer une requête ping à l'adresse LAN VPN du serveur de 10.128.0.1, et le serveur VPN peut envoyer une requête ping à l'adresse LAN VPN du client dans la plage 10.128.0.0/20, après que le client a ajouté la route appropriée comme décrit précédemment.
  • Un client VPN peut envoyer des pings à une machine sur le réseau local Amazon, mais lorsque ces machines envoient des réponses, elles s'arrêtent sur le serveur VPN - elles ne sont pas transmises au client, ce qui entraîne des messages de «délai d'expiration» sur le client . À l'inverse, lorsqu'une machine sur le réseau local d'Amazon essaie d'envoyer une requête ping à l'adresse LAN VPN 10.128.0.0/20 du client, le serveur VPN voit le ping, mais le client ne le fait jamais et ne génère donc pas de réponse.

Pourquoi le serveur VPN n'envoie-t-il pas de paquets depuis le réseau local d'Amazon vers ses clients sur le réseau local VPN? Il peut certainement parler aux clients sur le réseau local VPN, et le routage est activé, et il est prêt à acheminer les paquets à partir du réseau local VPN -> Amazon LAN, mais pas l'inverse. Qu'est-ce que j'oublie ici?

Itinéraires

Voici les tables de routage d'un client VPN. Le client est une machine virtuelle VirtualBox exécutant Windows 8. L'adresse IP de l'adaptateur vbox est 10.0.2.15 sur a / 24. Ce client est derrière NAT (en fait, il est derrière double-NAT, car l'adaptateur vbox est NAT à mon réseau local, qui est NAT à Internet). Cette table de routage est de après l' ajout manuel des routes à 10.128.0.0/20 et 172.16.0.0/17.

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0         10.0.2.2        10.0.2.15     10
         10.0.2.0    255.255.255.0         On-link         10.0.2.15    266
        10.0.2.15  255.255.255.255         On-link         10.0.2.15    266
       10.0.2.255  255.255.255.255         On-link         10.0.2.15    266
       10.128.0.0    255.255.240.0         On-link        10.128.0.3     15
       10.128.0.3  255.255.255.255         On-link        10.128.0.3    266
    10.128.15.255  255.255.255.255         On-link        10.128.0.3    266
    54.213.67.179  255.255.255.255         10.0.2.2        10.0.2.15     11
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
       172.16.0.0    255.255.128.0         On-link        10.128.0.3     15
   172.16.127.255  255.255.255.255         On-link        10.128.0.3    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link         10.0.2.15    266
        224.0.0.0        240.0.0.0         On-link        10.128.0.3    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link         10.0.2.15    266
  255.255.255.255  255.255.255.255         On-link        10.128.0.3    266
===========================================================================
Persistent Routes:
  None

Voici les tables de routage du serveur RRAS, qui exécute Windows Server 2012. Ce serveur est également derrière NAT, comme indiqué ci-dessus. Il n'a qu'un seul NIC. Son adresse IP privée est 172.16.1.32, sur un / 23 (qui fait lui-même partie d'un plus grand réseau / 17; je pense qu'il est juste d'ignorer les parties du / 17 en dehors du / 23, car d'autres machines sur le / 23 ne peut pas atteindre ou être atteint par les clients VPN non plus).

L'adaptateur virtuel VPN a sa propre adresse, 10.128.0.1, qui est attribuée automatiquement lors de la première connexion d'un client. Les routes pour 10.128.0.1 (vers lui-même) et 10.128.0.2 (vers son seul client) que vous voyez sont également ajoutées automatiquement à ce moment-là. Aucun itinéraire n'est ajouté au serveur VPN manuellement. 

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       172.16.0.1      172.16.1.32     10
       10.128.0.1  255.255.255.255         On-link        10.128.0.1    286
       10.128.0.2  255.255.255.255       10.128.0.2       10.128.0.1     31
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  169.254.169.250  255.255.255.255       172.16.0.1      172.16.1.32     10
  169.254.169.251  255.255.255.255       172.16.0.1      172.16.1.32     10
  169.254.169.254  255.255.255.255       172.16.0.1      172.16.1.32     10
       172.16.0.0    255.255.254.0         On-link       172.16.1.32     11
      172.16.1.32  255.255.255.255         On-link       172.16.1.32    266
     172.16.1.255  255.255.255.255         On-link       172.16.1.32    266
       172.16.2.0    255.255.254.0      172.168.0.1      172.16.1.32     11
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link       172.16.1.32    266
        224.0.0.0        240.0.0.0         On-link        10.128.0.1    286
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link       172.16.1.32    266
  255.255.255.255  255.255.255.255         On-link        10.128.0.1    286
===========================================================================
Persistent Routes:
  None

Voici les tables de routage pour une autre machine sur le réseau privé du serveur, exécutant également le serveur 2012. Il possède une carte réseau, qui a une adresse IP privée de 172.16.1.177 - ce qui signifie que c'est sur le même / 23 que le serveur VPN. (Notez que la route vers le 10.128.0.0/20 est définie sur la passerelle, qui est contrôlée par Amazon, donc vous ne le verrez pas ici. J'ai ajouté la route correcte vers Amazon, comme en témoigne le fait que Wireshark sur le Le serveur VPN voit les paquets.)

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       172.16.0.1     172.16.1.177     10
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  169.254.169.250  255.255.255.255       172.16.0.1     172.16.1.177     10
  169.254.169.251  255.255.255.255       172.16.0.1     172.16.1.177     10
  169.254.169.254  255.255.255.255       172.16.0.1     172.16.1.177     10
       172.16.0.0    255.255.254.0         On-link      172.16.1.177    266
     172.16.1.177  255.255.255.255         On-link      172.16.1.177    266
     172.16.1.255  255.255.255.255         On-link      172.16.1.177    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link      172.16.1.177    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link      172.16.1.177    266
===========================================================================
Persistent Routes:
  None

Voici les itinéraires dans la console Amazon. Je ne pense que ce sont corrects - le trafic est rend au serveur VPN, après tout, pour disparaître à l' intérieur de celui - ci - mais au cas où quelqu'un veut les voir, ils sont là. (Amazon fait des choses un peu bizarres. Fait eni-2f3e8244 / i-77e26440référence à la carte réseau sur le serveur VPN, et igw-d4bc27bcfait référence à la passerelle / NAT Internet contrôlée par Amazon que toutes mes instances utilisent pour parler à Internet.)

10.128.0.0/20   eni-2f3e8244 / i-77e26440   
172.16.0.0/17   local   
0.0.0.0/0       igw-d4bc27bc
vpn routing windows-server-2012 rras Micah R Ledbetter
la source
2
J'ai déjà utilisé une configuration presque identique à la vôtre et je ne me souviens pas vraiment de ce que vous faites de mal. Pouvez-vous publier la sortie ROUTE PRINT du client, du serveur et d'un hôte sur le réseau 172.16? (Je suppose que les hôtes du réseau 176.16 n'ont pas la bonne route)
Dusan Bajic
testez également avec tracert depuis l'un des 172.16 hôtes vers le client vpn - est-ce qu'il atteint le serveur vpn?
Dusan Bajic
J'ai ajouté les informations demandées - route printet la tracertsortie - et j'ai apporté une correction importante à certaines informations que j'ai ajoutées plus tôt. (Merci de votre aide!)
Micah R Ledbetter
1
Bizarre. Comment votre pool d'adresses statiques pour les clients VPN est-il configuré exactement?
Dusan Bajic
@ dusan.bajic Adresse IP de début: 10.128.0.0; Adresse IP de fin: 10.128.15.255; Nombre d'adresses: 4096.
Micah R Ledbetter

Réponses:

1

Que se passe-t-il si vous ajoutez une route statique sur vos serveurs en leur disant que pour atteindre 10.128.0.0/20, ils doivent passer par l'adresse LAN du serveur VPN?

route add 10.128.0.0 mask 255.255.240.0 a.b.c.d

Remplacez abcd par l'adresse LAN du serveur VPN.

Cela éliminera au moins les problèmes de routage d'Amazon.

Silvio Massina
la source