SSH обривається на VPN щохвилини? Причина не keepalive

Сеанс, що помирає через повторюваний інтервал, зазвичай втрачає стан міжмережевого екрана, а не keepalive. Простежте обидва напрямки, перш ніж чіпати MTU чи таймери.

SSH підключається, працює близько хвилини, а потім щоразу застигає приблизно через той самий інтервал. Звичайне пояснення — тайм-аут простою, тому люди знижують MTU і налаштовують keepalive на клієнті. З'єднання WireGuard, над яким я працював, уже пройшло через усе це: менший MTU тунелю, налаштування client-alive, налаштований keepalive тунелю. Обриви тривали без змін. Причиною виявився асиметричний маршрут у LAN, і цей шаблон варто впізнавати, бо він перемагає будь-яке виправлення на основі таймерів.

Keepalive доводить, що ваш хост усе ще готовий надсилати. Він не може змусити пристрій, що веде стан, побачити відповідь, яка ніколи через нього не проходить.

Міф: keepalive виправляють тихий обрив

Keepalive в SSH існують для однієї задачі: не дати чомусь, що рахує тишу, прибрати неактивний сеанс. Із цим вони добре справляються. Вони не вирішують проблему пристрою зі станом, який побачив перший пакет в одному напрямку і потім так і не побачив відповідь, бо ніщо з того, що надсилає клієнт, не змінює, який інтерфейс використовує відповідь.

Зміна MTU — інше популярне виправлення, і в неї той самий режим відмови. Зниження MTU допомагає фрагментації та проблемам MTU шляху, і воно нічого не робить для маршруту. Якщо ваші таймери й MTU вже розумні, а обрив усе ще відбувається через повторюваний інтервал, інтервал говорить вам про тайм-аут десь, а не про розмір пакета. Запишіть інтервал і порівняйте його з тайм-аутами стану на кожному пристрої на шляху.

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

Що насправді робить додатковий шлюз

Поставте ноутбук і VPN-шлюз в одну LAN, а окремий LAN-міжмережевий екран — шлюзом за замовчуванням. Ноутбук надсилає трафік у напрямку VPN до міжмережевого екрана, той передає його шлюзу, і відповіді шлюзу повертаються прямо через LAN до ноутбука. Друга ділянка ніколи не проходить через міжмережевий екран, тому його таблиця станів тримає половину з'єднання.

Адреси нижче відображають цю схему:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

Перенаправлення й обробка стану потім перетворюють робоче рукостискання на з'єднання, яке помирає пізніше, а не одразу. Затримка — це старіння запису стану або провал суворішої перевірки, тому інтервал виглядає так механічно.

Нічого з цього не з'являється в конфігурації клієнта, тому пошук зазвичай починається не в тому файлі.

Виберіть один свідомий шлях

Для схеми вище маршрутизація віддаленої підмережі напряму на VPN-шлюз прибирає половину з'єднання:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

Це прикладні адреси. Наступний хоп має бути досяжним у вашій LAN, префікс має бути потрібною віддаленою мережею, а друга команда показує результат, перш ніж ви на нього покладетеся. Якщо шлюз не у вашій підмережі, цей маршрут — не те виправлення, яке вам потрібне.

Якщо міжмережевий екран має контролювати трафік між цими системами, маршрутизація в обхід нього — хибна архітектура. Натомість пропустіть обидва напрямки через межу й налаштуйте маршрути з кожного боку так, щоб зворотний шлях збігався. Мета — єдиний свідомий шлях, а не менше перевірки стану.

нотатки про асиметричну маршрутизацію від Netgate описують ту саму асиметрію на рівні інтерфейсу та проблеми стану, які вона створює, тому прочитайте їх, перш ніж глобально послаблювати обробку стану. Часові розриви, схожі на цей випадок, самі по собі не є доказом. Ставтеся до статті як до опису одного режиму відмови, а потім доведіть, що ваша мережа йому відповідає, перш ніж змінювати глобальну політику стану.

Перевірте з обох боків

Прочитайте маршрут ноутбука до призначення й маршрут призначення назад до ноутбука; це два окремі рішення, і, ймовірно, неправильне лише одне з них. Ping, успішний із самого шлюзу, може повністю приховати проблему, бо він походить із машини, чий шлях уже правильний. Вам потрібні обидва напрямки так, як їх бачать два кінці реального сеансу.

Після виправлення знову відкрийте SSH і тримайте сеанс відкритим значно довше за інтервал, який раніше зривався. Потім зробіть маршрут постійним у схваленій мережевій конфігурації, бо разова команда — не план перезавантаження, і проблема повернеться при наступному перезавантаженні з новою загадкою.

Коли асиметрія нормальна

Асиметрична маршрутизація нормальна в багатьох мережах і не є поломкою за визначенням. Вона стає проблемою, коли відстеження стану, трансляція або політика залежать від видимості шляху, якого вони не бачать, і кожне з цього має інші ліки. Перевірте, чого насправді потребує середній пристрій, перш ніж перебудовувати все навколо нього.

Стійка відповідь називає два шляхи, пристрій, якому потрібно бачити обидва, і маршрут, який це уможливлює. Якщо ви не можете назвати пристрій, ви ще не знайшли причину.

Схожі статті