Comment puis-je empêcher TCP Connection gèle sur un réseau OpenVPN?
Nouveaux détails ajoutés à la fin de cette question; Il est possible que je me concentre sur la cause.
J'ai une configuration VPN basée sur UDP OpenVPN en mode tap (j'ai besoin de tap parce que j'ai besoin du VPN pour passer des paquets de multidiffusion, ce qui ne semble pas être possible avec tun réseaux) avec une poignée de clients sur Internet. J'ai rencontré fréquent TCP Connection gèle sur le VPN. C'est-à-dire que je vais établir un TCP (par exemple, une connexion SSH, mais d'autres protocoles ont Questions similaires), et à un moment donné au cours de la session, il semble que le trafic cesserait d'être transmis sur ce TCP Session.
Cela semble être lié aux points auxquels les grands transferts de données se produisent, tels que si j'exécute une commande ls dans une session SSH ou si je cat un fichier journal long. Certaines recherches de Google présentent un certain nombre de réponses comme celle-ci précédente sur le défaut de serveur , indiquant que le coupable probable est un problème de MTU: que pendant les périodes de trafic élevé, le VPN essaie d'envoyer des paquets qui obtiennent tombé quelque part dans les tuyaux entre les points d'extrémité VPN. La réponse ci-dessus suggère d'utiliser les paramètres de configuration openvpn suivants pour atténuer le problème:
fragment 1400
mssfix
Cela devrait limiter le MTU utilisé sur le VPN à 1400 octets et fixer le TCP taille du segment maximum pour empêcher la génération de tous paquets plus grande que cela. Cela semble atténuer un peu le problème, mais je toujours voir souvent les geles. J'ai essayé un certain nombre de tailles comme des arguments de la directive fragment: 1200, 1000, 576, tous avec des résultats similaires. Je ne peux pas penser à une étrange topologie de réseau entre les deux Les extrémités qui pourraient déclencher un tel problème: le serveur VPN est en cours d'exécution sur une machine pfsense machine connectée directement à Internet et mon client est également connecté directement à Internet à un autre endroit.
Un autre morceau étrange du puzzle: Si j'exécute l'utilitaire tracepath, alors cela semble faire l'aide du problème. Un exemple de course ressemble à:
[~]$ tracepath -n 192.168.100.91
1: 192.168.100.90 0.039ms pmtu 1500
1: 192.168.100.91 40.823ms reached
1: 192.168.100.91 19.846ms reached
Resume: pmtu 1500 Hops 1 back 64
La course ci-dessus se situe entre deux clients sur le VPN: j'ai initié la trace de 192.168.100.90 à la destination de 192.168.100.91. Les deux clients ont été configurés avec fragment 1200; mssfix; Dans une tentative de limitation du MTU utilisé sur le lien. Les résultats ci-dessus sembleraient suggérer que tracepath a été capable de détecter une trajectoire de la MTU de 1500 octets entre les deux clients. Je supposerais que ce serait un peu plus petit en raison des paramètres de fragmentation spécifiés dans la configuration OpenVPN. J'ai trouvé cela résulter un peu étrange.
Même plus étranger, cependant: Si j'ai un TCP Connection dans l'état bloqué (par exemple, une session SSH avec une liste de répertoires qui se fige au milieu), alors exécutant le tracepath Commande indiquée ci-dessus provoque la démarrage de la connexion! Je ne peux pas comprendre une explication raisonnable pour la raison pour laquelle ce serait le cas, mais je me sens que cela pourrait être dirigé vers une solution pour éradiquer finalement le problème. .
Quelqu'un a-t-il des recommandations pour d'autres choses à essayer?
EDIT: Je suis revenu et j'ai regardé cela un peu plus loin et n'a pas trouvé d'informations plus confondues:
Je définit la connexion OpenVPN au fragment à 1400 octets, comme indiqué ci-dessus. Ensuite, je me suis connecté au VPN de sur Internet et utilisé sur WireShark pour examiner les paquets UDP envoyés au serveur VPN tandis que le stalle s'est produit. Aucun n'a été supérieur au nombre de 1400 octets spécifiés, la fragmentation semble fonctionner correctement.
Pour vérifier que même un MTU de 1400 octets serait suffisant, je suis pingé le serveur VPN à l'aide de la commande suivante (Linux):
ping <Host> -s 1450 -M doCela (je crois) envoie un paquet de 1450 octets avec une fragmentation désactivée (j'ai au moins vérifié qu'il n'a pas fonctionné si je l'ai défini à une valeur évidemment trop grande comme 1600 octets). Ceux-ci semblent fonctionner très bien; Je reçois des réponses de l'hôte sans problème.
Donc, peut-être que ce n'est pas du tout une question de MTU. Je suis juste confus quant à ce que cela pourrait être autre!
EDIT 2: Le trou de lapin continue de rester plus profond: j'ai maintenant isolé le problème un peu plus. Il semble être lié au système d'exploitation exact que le client VPN utilise. J'ai dupliqué avec succès le problème sur au moins trois machines Ubuntu (versions 12.04 à 13.04). Je peux dupliquer de manière fiable un gel de connexion SSH en une minute ou donc par juste cat- ing d'un fichier journal important.
Toutefois, si je fais le même test à l'aide d'une machine Centos 6 en tant que client, je ne vois pas le problème! J'ai testé à l'aide de la même version client openvpn que j'utilisais sur les machines Ubuntu. Je peux cat fichiers journaux pendant des heures sans voir le gel de la connexion. Cela semble fournir une idée de la cause ultime, mais je ne suis tout simplement pas sûr de ce que cette idée est.
J'ai examiné le trafic sur le VPN en utilisant Wireshark. Je ne suis pas un TCP expert, donc je ne sais pas quoi faire des détails de Gory, mais le gist est qu'à un moment donné, un paquet UDP est tombé en raison de la bande passante limitée de la liaison Internet, causant TCP retransmissions à l'intérieur du tunnel VPN. Sur le client CENTOS, ces retransmissions se produisent correctement et les choses se déplacent heureusement. À un moment donné avec les clients Ubuntu, cependant, la fin distante Démarre la retransmission du même TCP segment sur et sur (avec le retard de transmission augmentant entre chaque retransmission). Le client envoie ce qui ressemble à un fichier valide TCP ACK à chacun retransmission, mais l'extrémité distante continue de transmettre le même TCP segment périodiquement. Cela prolonge adfinitum et les stands de connexion. Ma question serait la suivante:
- Est-ce que quelqu'un a des recommandations sur la manière de résoudre et/ou de déterminer la cause première du TCP problème? C'est comme si la partie distante n'accepte pas les messages ACK envoyés par le client VPN.
Une différence commune entre le nœud Centos et les différentes sorties Ubuntu est que Ubuntu possède une version beaucoup plus récente du noyau Linux (de 3,2 à Ubuntu 12.04 à 3,8 en 13,04). Un pointeur sur un nouveau bug de noyau peut-être? Je suppose que si c'était le cas, alors je ne serais pas le seul à expérimenter le problème; Je ne pense pas que cela semble être une configuration particulièrement exotique.
Cette commande le résout pour moi:
$ Sudo ip link set dev tun0 mtu 1350 && echo ":)"
Vous pouvez vérifier les paramètres de tun0 avec
$ ip a s
À votre santé!
Désactiver la mise à l'échelle de la fenêtre dans TCP, avec:
sysctl -w net.ipv4.tcp_window_scaling=0
Après cela, SSH aux systèmes Debian/Ubuntu sur VPN fonctionnent bien pour moi.
Sous Windows à l'aide du mastic, vous devez modifier le MTU en allant à la connexion locale pour la connexion VPN -> Détails de l'interface réseau (adaptateur Windows ou quelque chose comme ça) -> Avancé -> Propriétés -> MTU (changez-la à quelque chose inférieur à 1500). Vous devrez peut-être vous reconnecter. Cela a fonctionné pour moi sur Windows et PuTTY