Автоматично відновлюваний тунель TCP

9

У мене ненадійний мережевий зв’язок між двома машинами: іноді активні TCP-з'єднання випадають з причин, що не знаходяться під моїм контролем. Я хочу встановити надійний TCP-зв’язок між двома машинами.

Якби мережа була надійною, я б просто запустив ssh -L 1234:localhost:1234 remotehost, із прослуховуванням сервера на порту 1234 remotehostі вкажу клієнта на localhost:1234. Але якщо ssh-з'єднання вмирає, то і переадресоване з'єднання. Як я можу організувати автоматичне відновлення зв'язку між клієнтом і сервером?

Не рішення:

Це не для інтерактивних додатків, тому екран не застосовується.
Йдеться не лише про автоматичне підключення тунелю SSH, la autossh . Я хочу продовжувати використовувати те саме тунельоване TCP-з'єднання, а не запускати нове.
В принципі, VPN зробив би свою справу. Але це здається непосильним, коли я просто хочу одне TCP-з'єднання, і я хотів би рішення, яке працює, навіть якщо у мене немає дозволів root на будь-якій стороні.

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

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

Gilles, ти використовуєш tcp keepalives зі своїми ssh-з'єднаннями? Якщо ні, спершу спробуйте це ... Час з'єднань з реалізацією NAT швидко закінчується

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

@Mike: Дякую за пораду. У мене немає негайної потреби, але я зіткнувся з обома ситуаціями, коли якийсь проміжний маршрут прийшов і пішов (таким чином, TCP-ключі зробили більше шкоди, ніж користі), і ситуації, коли NAT перевантажив мене і кинув мене (тому TCP keepalives може допомогти). TCP keepalives не матиме значення для безперервного потоку (наприклад, scp), чи не так? У будь-якому випадку я хотів би дотриматись цього загального: наступного разу, коли я зіткнуся з лускатою мережею будь-якого смаку, що я можу зробити?

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

Жили, рішення різні для постійних потоків, як scp. Я відповідав на w / ssh keepalives на основі прикладу вашого переадресації портів. Re: лускатий хоп вниз за течією, ви не можете багато чого зробити, крім створення сеансу ssh з келепалами, які є більш толерантними (тобто дозволяють отримати більше кинутих кепалів з ServerAliveInterval > 0і ServerAliveCountMax > 3). NAT вимагає менших інтервалів зберігання. Ключове питання - визначити, у чому полягає проблема, та адаптувати її відповідно. Введіть варіанти, .ssh/configщоб вони завжди були для вас

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

@Mike: Один з моїх випадків використання включає клієнт, який отримує свій IP від перевантаженого NAT, ніж випадково скидає навіть активні з'єднання (подумайте, більше P2P, ніж повинно бути). Через кілька секунд клієнту вдається знову підключитися, але може отримати іншу IP-адресу. У цьому випадку з'єднання TCP не виживе. Скелі справляються, але я вважаю за краще щось, що збирається з коробки в сучасних системах.

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

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

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

5

Чи шукаєте старі непорушені надійні розетки ( скелі )?

— Hangin у тихому відчаї
джерело

1

Дякую, Рокс - це справді те, що я запам'ятав. Звичайно, я вважаю за краще щось, що підтримується.

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

@ Gilles'SO-stopbeingevil 'Мало того, що він не знайдений, але, схоже, повністю скинувся з обличчя Інтернету!

— Майкл

1

Єдиний стандартний протокол, про який я знаю з цією можливістю, - це MPTCP . Він прозорий для додаткового шару, тому SSH поверх MPTCP повинен просто працювати. Він може запускати базові TCP-з'єднання по різних трасах з різними IP-адресами, тому в принципі він міг би використовуватися для міграції вашого SSH-з'єднання в і з VPN-з'єднання, залежно від того, підключено VPN-з'єднання.

Я не знаю багато про зрілість реалізації MPTCP, але дизайн протоколу виглядає досить надійним.

Це повинно захищати ваші SSH-з'єднання від втрати через невміле підключення до мережі. Це не захистить вас від mitm, який хоче перервати ваш SSH-з'єднання. Mitm все ще може вводити пошкоджені дані, які SSH виявить і порушить з'єднання.

Вбудований у протокол SSH метод, подібний до MPTCP, як повторне з'єднання, був би методом, який я міг би уявити, щоб зберегти з'єднання живим якнайдовше. Але я не думаю, що така функція була розроблена для протоколу SSH.

— касперд
джерело

0

Ви можете використовувати daemontoolsдля збереження ssh-порта вперед; не обов'язково тримати програми в залежності від з'єднання живими, поки воно не працює (як імовірно, коли ssh від'єднає локальний порт, почне відмовлятися від з'єднань), але це початок.

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

— Гордон Морхаус
джерело

-2

TCP робить це автоматично. Вам потрібно лише відключити або послабити типові практичні хаки очищення, які використовуються для вбивства moribund TCP-з'єднань. Вимкніть збереження TCP для вашого з'єднання та значно збільшите обмеження для надмірної повторної передачі. Наприклад, в Linux записуйте велику кількість /proc/sys/net/ipv4/tcp_retries2.

Однак у сучасній мережі надзвичайний брандмауер для перевірки пакетів, ймовірно, забуде про TCP-з'єднання, яке не вдається регулярно обмінюватися пакетами, тому на вашому параді може піти дощ.

— аеколі
джерело

1

Це правда, що TCP може впоратись із ситуацією, якщо кожна кінцева точка має статичну IP-адресу та немає загальнодоступних середніх скриньок. У цьому питанні згадується reasons beyond my control, що я читаю як динамічний IP або стаціонарний проміжок. У таких сценаріях TCP keepalive може трохи допомогти. Але як би ви не налаштували TCP keepalive, його буде недостатньо, щоб зберегти з'єднання живим, коли середня скринька втрачає стан через перезапуск.

— kasperd

@kasperd Я згоден. Однак намагатись утримувати TCP-з'єднання відкритим у цих випадках марно. Тому я припустив, що запитуючий не стикається з тими викликами.

— aecolley

Це не даремно, якщо ви керуєте обома кінцевими точками і можете оновити їх до стеку з підтримкою MPTCP. Крім того, рішення рівня шару додатку може бути реалізовано поверх TCP без необхідності MPTCP.

— kasperd