Le serveur OpenVPN ne peut pas faire de ping aux clients

J'ai installé OpenVPN sur un serveur Debian. Les clients peuvent se connecter et les clients peuvent effectuer un ping et accéder à des ressources (partage Samba et intranet) sur le serveur.

Cependant, le serveur ne peut pas faire de ping sur le client – il est juste éteint.

Diagramme

Client OpenVPN assigned IP: 10.67.15.26 ↓ UDP on 1194 Internet ↓ Router port-forwards 1194 to server ↓ Server LAN IP: 10.67.5.1 

Serveur OpenVPN config (bits pertinents)

 port 1194 proto udp dev tun server 10.67.15.0 255.255.255.0 push "route 10.67.5.0 255.255.255.0" 

Table de routage du serveur

 Destination Gateway Genmask Flags Metric Ref Use Iface 10.67.15.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 10.67.15.0 10.67.15.2 255.255.255.0 UG 0 0 0 tun0 10.67.5.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 0.0.0.0 10.67.5.254 0.0.0.0 UG 0 0 0 eth1 

Pare-feu serveur

J'ai désactivé temporairement le pare-feu du serveur, toutes les règles des chaînes sont ACCEPTES et tous les drapeaux de renvoi sont définis:

 1 : /proc/sys/net/ipv4/conf/all/forwarding 1 : /proc/sys/net/ipv4/conf/default/forwarding 1 : /proc/sys/net/ipv4/conf/lo/forwarding 1 : /proc/sys/net/ipv4/conf/eth1/forwarding 1 : /proc/sys/net/ipv4/conf/tun0/forwarding 1 : /proc/sys/net/ipv4/ip_forward 

Cas d'essai:

Client: ping 10.67.5.1 fonctionne, tout comme d'autres ressources.

Serveur: ping 10.67.15.26 fois.

En comparant deux clients différents, j'ai pu identifier et réparer 2 problèmes.

Problème 1: routage

Pour une raison quelconque (et je ne suis pas sûr de l'avoir résolu), la table de routage du serveur a toujours oublié la route vers son LAN (10.67.5.0/24). Cela faisait en sorte que tout le trafic LAN sortant traversait sa passerelle principale, qui ne passera pas vers le réseau local OpenVPN (10.67.15.0/24). Cela entravait le trafic du réseau OpenVPN destiné au LAN à échouer à la passerelle principale; Ainsi, les pings étaient envoyés, mais la réponse a été abandonnée.

Modifier: Malheureusement, je ne sais pas ce qui faisait tomber cette route; Comme vous pouvez le constater dans le tableau de routage ci-dessus. J'ai essayé d'ajouter une commande d'itinéraire dans / etc / network / interfaces, mais j'ai fini par deux routes identiques et en double, donc je l'ai repris. C'était ma configuration de fwbuilder qui faisait tomber cette voie: lors de la configuration de l'adaptateur eth1, j'avais donné un masque de réseau / 32 (c'est-à-dire un hôte) au lieu de / 24 (pour le LAN).

En testant un client Debian, j'ai pu retrouver celui-ci, après cela, cela a fonctionné, mais le client Windows 7 ne l'a pas fait.

Problème 2: pare-feu / config de Windows 7

Il y a eu deux problèmes avec Windows installé.

Windows doit avoir le jeu de profils privé "Travail" pour l'adaptateur TAP

Le crédit pour cette section va à kalwi

Dans le "Réseau et Centre de partage", vous devriez voir (au moins) 2 "réseaux actifs". J'avais le réseau sans fil et ensuite un «réseau non identifié». Ce dernier est le dispositif OpenVPN TAP, et il avait une icône de banc de parc, ce qui signifie qu'il a été traité comme public, sans confiance. Pour pouvoir modifier cela, vous devez ajouter une passerelle par défaut pour l'adaptateur.

Démarrez un terminal DOS / Cygwin en tant qu'administrateur . (Start Orb> recherche de CMD> cliquez avec le bouton droit de la souris sur> exécuter en tant qu'administrateur).

Ensuite, faites route print -4 . Vous verrez une liste d'interface. Chaque ligne commence par un nombre et à droite, vous verrez le nom. Identifiez le numéro d'interface de l'adaptateur TAP-Win32. Le mien avait 17 ans.

Ajoutez maintenant l'itinéraire:

 route -p add 0.0.0.0 mask 0.0.0.0 1.2.3.4 metric 500 if 17 

Lorsque 1.2.3.4 doit être l'IP de votre passerelle OpenVPN (révélé dans la colonne de la passerelle dans la sortie de la commande précédente) et 17 doit être votre numéro d'interface TAP. L'option -p rend l'itinéraire permanent. Je l'ai fait sans cela d'abord, pour tester. Cela suppose que l'IP de passerelle OpenVPN du client ne changera pas entre les connexions .

Une fois que vous avez fait qu'une boîte de dialogue devrait apparaître et vous demander de classer le nouveau réseau. Choisissez Travail .

À ce stade, j'ai pu envoyer du trafic de LAN de mon entreprise au client (testé via netcat), mais les pings étaient encore sans réponse.

Dites à Windows d'autoriser pings (ICMPv4)

Start Orb> Pare-feu Windows avec sécurité avancée Ensuite, passez aux règles entrantes et à la nouvelle règle …

  • Règle personnalisée
  • Tous les programmes
  • Protocole: ICMPv4
  • Autoriser la connexion
  • Postuler au profil privé
  • Nomme le.

Enfin, les pings ont été retournés.