Автоматически снова соединяющийся туннель TCP
Действительно ли старыми являются несохраняемые Надежные Сокеты (Скалы), что Вы ищете?
Вы можете использовать daemontools , чтобы поддерживать порт ssh вперед; он не обязательно будет поддерживать программы, зависящие от соединения, пока оно не работает (предположительно, когда ssh отключит локальный порт, он начнет отказывать своим соединениям), но это начало.
Я подозреваю, что есть некоторые iptables , например, заставляя этот порт сбрасывать пакеты, как только пересылка ssh уходит, чтобы подключающиеся программы просто знали, что пакеты исчезают, а не отклоняются. Я просто изучаю daemontools сам (снова), поэтому я не уверен, можно ли запустить собственный сценарий, когда служба умирает, но я подозреваю, что можете.
Единственный известный мне стандартный протокол с такой возможностью - MPTCP. Он прозрачен для прикладного уровня, поэтому SSH поверх MPTCP должен просто работать. Он может запускать лежащие в основе TCP соединения по разным путям с разными IP-адресами, поэтому в принципе его можно использовать для переноса вашего SSH-соединения внутрь и наружу VPN-соединения в зависимости от того, развито ли VPN-соединение.
Я мало что знаю о зрелости реализации MPTCP, но дизайн протокола выглядит довольно надежным.
Он должен защищать ваши SSH-соединения от потери из-за неаккуратного сетевого соединения. Он не защитит вас от митма, который хочет разорвать ваше SSH соединение. Митм все еще может впрыскивать поврежденные данные, которые SSH обнаружит и разорвет соединение.
MPTCP вроде метода переподключения, встроенного в протокол SSH, был бы тем методом, который я мог бы себе представить, поддерживая соединение живым как можно дольше. Но я не думаю, что такая возможность была разработана для протокола SSH.
TCP делает это автоматически. Нужно только отключить или ослабить типичные практические очистительные хаки, используемые для уничтожения морфинговых TCP-соединений. Отключите TCP keepalive для вашего соединения и значительно увеличьте предел для чрезмерных ретрансляций. В Linux, например, запишите большое число в /proc/sys/net/ipv4/tcp_retries2.
Однако, в современной сети брандмауэр с контролем состояния пакетов, скорее всего, забудет о TCP соединении, которое не может регулярно обмениваться пакетами, поэтому на Вашем параде может пойти дождь.
.