Reconnexion automatique du tunnel TCP


9

J'ai une connexion réseau non fiable entre deux machines: parfois les connexions TCP actives sont interrompues pour des raisons indépendantes de ma volonté. Je veux établir une connexion TCP fiable entre les deux machines.

Si le réseau était fiable, je courrais simplement ssh -L 1234:localhost:1234 remotehost, avec le serveur écoutant sur le port 1234 remotehost, et pointerais le client localhost:1234. Mais si la connexion ssh meurt, la connexion transférée le sera également. Comment organiser la restauration automatique de la connexion entre le client et le serveur?

Non-solutions:

  • Ce n'est pas pour les applications interactives, donc l' écran ne s'applique pas.
  • Il ne s'agit pas seulement de reconnecter automatiquement un tunnel SSH, la autossh . Je veux continuer à utiliser la même connexion TCP tunnelée, pas en démarrer une nouvelle.
  • En principe, un VPN ferait l'affaire. Mais il semble exagéré quand je veux juste une connexion TCP, et j'aimerais une solution qui fonctionne même si je n'ai pas d'autorisations root de chaque côté.

J'ai une faible mémoire d'un programme appelé rocksqui a fait exactement cela, mais il semble être tombé du visage du Web. Je suis principalement intéressé par Linux des deux côtés (même si je m'attendrais à ce qu'un programme à ce niveau soit portable pour d'autres unités), mais si vous connaissez un programme qui fonctionne entre QNX et VMS, tant mieux.


Gilles, utilisez-vous tcp keepalives avec vos connexions ssh? Sinon, essayez d'abord ... certaines implémentations NAT expirent rapidement les connexions
Mike Pennington

@Mike: Merci pour l'astuce. Je n'ai pas un besoin immédiat, mais j'ai été confronté à des situations où une route intermédiaire allait et venait (donc les keepalives TCP ont fait plus de mal que de bien) et des situations où un NAT m'a surchargé et m'a laissé tomber (donc les keepalives TCP pourraient aider). De toute façon, les keepalives TCP n'auraient pas d'importance pour un flux continu (par exemple scp)? En tout cas, je voudrais garder ce général: la prochaine fois que je suis confronté à un réseau floconneux de quelque saveur, que puis-je faire?
Gilles 'SO- arrête d'être méchant'

Gilles, les solutions sont différentes pour des flux constants comme scp. Je répondais w / ssh keepalives basé sur votre exemple de transfert de port. Re: saut en aval instable, il n'y a pas grand-chose que vous puissiez faire, à part créer une session ssh avec des keepalives plus tolérantes (c'est-à-dire permettre plus de keepalives abandonnées avec ServerAliveInterval > 0et ServerAliveCountMax > 3). NAT nécessite des intervalles de conservation inférieurs. La question clé est d'identifier quel est le problème et de l'adapter en conséquence. Mettez les options .ssh/configpour qu'elles soient toujours là pour vous
Mike Pennington

@Mike: Un de mes cas d'utilisation inclut le client obtenant son IP à partir d'un NAT surchargé qui abandonne au hasard même les connexions actives (pensez plus de P2P qu'il ne devrait y en avoir). Après quelques secondes, le client parvient à se reconnecter mais peut obtenir une adresse IP différente. Il n'y a aucun moyen que la connexion TCP survive dans ce cas. Rocks fait face, mais je préférerais quelque chose qui se compile prêt à l'emploi sur les systèmes d'aujourd'hui.
Gilles 'SO- arrête d'être méchant'

dans le cas où le NAT vous donne de nouvelles adresses IP, il n'y a pas grand-chose que vous puissiez faire que réparer le NAT ou espérer une autre rocksimplémentation ... bien que ce soit évidemment un vrai coup de foudre
Mike Pennington

Réponses:



1

Le seul protocole standard que je connaisse avec cette capacité est MPTCP . Il est transparent pour la couche application, donc SSH au-dessus de MPTCP devrait simplement fonctionner. Il peut exécuter les connexions TCP sous-jacentes sur différents chemins avec différentes IP, donc en principe, il pourrait être utilisé pour migrer votre connexion SSH vers et depuis la connexion VPN selon que la connexion VPN est établie.

Je ne sais pas grand-chose sur la maturité des implémentations MPTCP, mais la conception du protocole semble assez robuste.

Il devrait protéger vos connexions SSH de se perdre en raison de la connectivité réseau fragile. Il ne vous protégera pas contre un mitm qui veut rompre votre connexion SSH. Un mitm peut toujours injecter des données corrompues, que SSH détectera et rompra la connexion.

Une méthode de reconnexion de type MPTCP intégrée au protocole SSH serait la méthode que j'imagine garder une connexion vivante le plus longtemps possible. Mais je ne pense pas qu'une telle fonctionnalité ait été conçue pour le protocole SSH.


0

Vous pouvez utiliser daemontoolspour garder le port ssh en avant; il ne gardera pas nécessairement les programmes en fonction de la connexion en vie (comme probablement lorsque ssh se déconnecte, le port local commencera à refuser leurs connexions), mais c'est un début.

Je soupçonne qu'il y a quelques iptablesastuces, comme faire en sorte que ce port supprime les paquets dès que le ssh forward disparaît, de sorte que les programmes de connexion savent juste que les paquets disparaissent, sans être refusés. Je suis juste en train de daemontoolsm'apprendre (encore une fois), donc je ne sais pas si vous pouvez exécuter un script personnalisé lorsqu'un service meurt, mais je pense que vous le pouvez.


-2

TCP le fait automatiquement. Vous avez seulement besoin de désactiver ou d'affaiblir les hacks de nettoyage pratiques typiques utilisés pour tuer les connexions TCP moribondes. Désactivez TCP keepalive pour votre connexion et augmentez considérablement la limite des retransmissions excessives. Sous Linux, par exemple, écrivez un grand nombre dans /proc/sys/net/ipv4/tcp_retries2.

Cependant, dans un réseau moderne, un pare-feu d'inspection des paquets avec état est susceptible d'oublier une connexion TCP qui ne parvient pas à échanger des paquets régulièrement, il peut donc pleuvoir sur votre défilé.


1
Il est vrai que TCP peut gérer la situation, tant que chaque point de terminaison a une adresse IP statique et qu'il n'y a pas de boîtier de médiation avec état. La question mentionne reasons beyond my control, que je lis comme IP dynamique ou boîtiers intermédiaires avec état. Dans de tels scénarios, TCP keepalive peut aider un peu. Mais peu importe la façon dont vous configurez TCP keepalive, il ne suffira pas de maintenir la connexion en vie lorsqu'un état de perte du boîtier de médiation en raison du redémarrage.
kasperd

@kasperd Je suis d'accord. Cependant, il est vain d'essayer de garder une connexion TCP ouverte dans ces cas. Par conséquent, j'ai supposé que l'interrogateur n'était pas confronté à ces défis particuliers.
aecolley

Ce n'est pas inutile si vous contrôlez les deux points de terminaison et pouvez les mettre à niveau vers une pile avec prise en charge MPTCP. De plus, une solution de couche application pourrait être implémentée au-dessus de TCP sans nécessiter MPTCP.
kasperd
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.