Автоматически переподключаемый TCP-туннель

9

У меня ненадежное сетевое соединение между двумя компьютерами: иногда активные соединения TCP теряются по независящим от меня причинам. Я хочу установить надежное TCP-соединение между двумя компьютерами.

Если бы сеть была надежной, я бы просто запустил ssh -L 1234:localhost:1234 remotehostсервер, прослушивающий порт 1234 remotehost, и указал бы на клиента localhost:1234. Но если соединение ssh умирает, то и переадресованное соединение. Как я могу организовать автоматическое восстановление соединения между клиентом и сервером?

Non-решения:

Это не для интерактивных приложений, поэтому экран не применяется.
Это не просто автоматическое переподключение SSH-туннеля, а-ля autossh . Я хочу продолжать использовать то же туннельное TCP-соединение, а не начинать новое.
В принципе, VPN может помочь. Но это кажется излишним, когда я просто хочу одно TCP-соединение, и я бы хотел, чтобы решение работало, даже если у меня нет прав root ни с одной стороны.

У меня тусклое воспоминание о программе, которая называется rocksименно это, но кажется, что она упала с лица сети. Я в основном интересуюсь Linux с обеих сторон (хотя я ожидаю, что программа на этом уровне будет переносимой на другие устройства), но если вам известна программа, которая работает между QNX и VMS, тем лучше.

— Жиль "ТАК - прекрати быть злым"
источник

Жиль, вы используете tcp keepalive с вашими ssh-соединениями? Если нет, попробуйте сначала ... некоторые реализации NAT быстро устанавливают время соединения

— Майк Пеннингтон,

@Mike: Спасибо за совет. У меня нет срочной необходимости, но я сталкивался как с ситуациями, когда какой-то промежуточный маршрут приходил и уходил (так что TCP keepalive принес больше вреда, чем пользы), так и с ситуациями, когда NAT перегружал и сбрасывал меня (так что TCP keepalive может помочь). Протоколы поддержки TCP в любом случае не будут иметь значения для непрерывного потока (например, scp), не так ли? В любом случае, я бы хотел оставить это в общих чертах: в следующий раз, когда я столкнусь с ненадежной сетью любого вкуса, что я могу сделать?

— Жиль "ТАК - перестань быть злым"

Жиль, решения разные для постоянных потоков, как scp. Я отвечал w / ssh keepalive на основе вашего примера переадресации портов. Re: flaky downstream hop, вы ничего не можете сделать, кроме как создать ssh-сессию с keepalive, которые являются более терпимыми (т. Е. Разрешить больше отброшенных keepalive с помощью ServerAliveInterval > 0and ServerAliveCountMax > 3). NAT требует меньших интервалов keepalive. Ключевой вопрос заключается в том, чтобы определить, в чем заключается проблема, и соответственно адаптировать ее. Поместите варианты, .ssh/configчтобы они всегда были для вас

— Майк Пеннингтон

@Mike: один из моих вариантов использования включает в себя получение клиентом своего IP-адреса от перегруженного NAT, который случайным образом сбрасывает даже активные соединения (подумайте, что P2P больше, чем должно быть). Через несколько секунд клиенту удается восстановить соединение, но он может получить другой IP-адрес. В этом случае TCP-соединение не выживет. Rocks отлично справляется, но я бы предпочел что-то, что компилируется из коробки на современных системах.

— Жиль "ТАК - перестань быть злым"

в случае, когда NAT дает вам новые IP-адреса, вы ничего не можете сделать, кроме как исправить NAT или надеяться на другую rocksреализацию ... хотя это, очевидно, реальное препятствие

— Майк Пеннингтон,

5

Является ли старое необслуживаемое надежное гнездо ( скалы ), что вы ищете?

— Hangin on в тихом отчаянии
источник

1

Спасибо, Рокс действительно то, что я вспомнил. Конечно, я бы предпочел что-то, что поддерживается.

— Жиль "ТАК - перестань быть злым"

@ Gilles 'SO-stopbeingevil' Мало того, что это не имеет смысла, но, кажется, полностью выпало из Интернета!

— Майкл

1

Единственный известный мне протокол с этой возможностью - это MPTCP . Он прозрачен для прикладного уровня, поэтому SSH поверх MPTCP должен просто работать. Он может запускать базовые TCP-соединения по разным путям с разными IP-адресами, поэтому в принципе его можно использовать для миграции вашего SSH-соединения в VPN-подключение и из него в зависимости от того, установлено ли VPN-подключение.

Я не знаю много о зрелости реализаций MPTCP, но дизайн протокола выглядит довольно надежным.

Он должен защищать ваши SSH-соединения от потери из-за нестабильного сетевого подключения. Это не защитит вас от того, кто хочет разорвать ваше соединение SSH. Mitm все еще может ввести поврежденные данные, которые SSH обнаружит и разорвет соединение.

MPTCP-подобный метод переподключения, встроенный в протокол SSH, был бы тем методом, который я мог бы себе представить, поддерживая соединение в течение максимально долгого времени. Но я не думаю, что такая функция была разработана для протокола SSH.

— kasperd
источник

0

Вы можете использовать, daemontoolsчтобы держать порт SSH вперед; он не обязательно будет поддерживать программы, зависящие от соединения, живыми, пока он не работает (как предположительно, когда ssh отключается, локальный порт начнет отказывать в их соединениях), но это только начало.

Я подозреваю, что есть некоторые iptablesхитрости, такие как вызов этого порта для пакетов DROP, как только ssh forward уходит, поэтому подключающиеся программы просто знают, что пакеты исчезают, а не получают отказ. Я только учусь daemontools(снова), поэтому я не уверен, что вы можете запустить собственный скрипт, когда служба умирает, но я подозреваю, что вы можете.

— Гордон Морхаус
источник

-2

TCP делает это автоматически. Вам нужно только отключить или ослабить типичные практические методы очистки, используемые для уничтожения умирающих TCP-соединений. Отключите поддержку активности TCP для своего соединения и значительно увеличьте лимит чрезмерных повторных передач. В Linux, например, напишите большое число в /proc/sys/net/ipv4/tcp_retries2.

Однако в современной сети брандмауэр с проверкой состояния пакетов может забыть о TCP-соединении, которое не может регулярно обмениваться пакетами, поэтому на вашем параде может пойти дождь.

— aecolley
источник

1

Это правда, что TCP может справиться с ситуацией, если у каждой конечной точки есть статический IP-адрес и нет промежуточных ящиков с состоянием. Упоминается вопрос reasons beyond my control, который я читаю как динамический IP-адрес или промежуточные блоки с состоянием. В таких случаях TCP keepalive может немного помочь. Но независимо от того, как вы настраиваете поддержку активности TCP, недостаточно поддерживать соединение, когда промежуточный ящик теряет состояние из-за перезапуска.

— Касперд

@kasperd Я согласен. Однако в таких случаях бесполезно пытаться держать TCP-соединение открытым. Поэтому я предположил, что спрашивающий не сталкивается с этими конкретными проблемами.

— Aecolley

Это не бесполезно, если вы контролируете обе конечные точки и можете обновить их до стека с поддержкой MPTCP. Кроме того, решение на уровне приложений может быть реализовано поверх TCP без использования MPTCP.

— Касперд