SSH пада на VPN всяка минута? Причината не е keepalive

SSH се свързва, работи около минута и след това замръзва на приблизително същия интервал всеки път. Обичайното обяснение е таймаут за бездействие, затова хората намаляват MTU и задават keepalive на клиента. WireGuard връзка, по която работих, вече беше преминала през всичко това: по-малък MTU на тунела, настройки за client-alive, конфигуриран keepalive на тунела. Прекъсванията продължаваха непроменени. Причината се оказа асиметричен LAN маршрут и моделът си заслужава да бъде разпознат, защото побеждава всяко поправяне, основано на таймери.

Keepalive доказва, че хостът ви все още е готов да изпраща. Той не може да накара устройство, което пази състояние, да види отговор, който никога не минава през него.

Митът: keepalive поправят тихо прекъсване

SSH keepalive съществуват за една задача: да не позволят на нещо, което брои тишината, да убие бездействаща сесия. Правят го добре. Не решават проблема на устройство със състояние, което е видяло първия пакет в една посока и след това никога не е видяло отговора, защото нищо, което клиентът изпраща, не променя интерфейса, по който минава отговорът.

Промяната на 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 и дръжте сесията отворена доста след интервала, който преди се проваляше. След това направете маршрута постоянен в одобрената мрежова конфигурация, защото еднократната команда не е план за рестарт и проблемът ще се върне при следващия рестарт с нова загадка.

Кога асиметрията е приемлива

Асиметричното маршрутизиране е нормално в много мрежи и не е счупено по определение. То става проблем, когато проследяването на състоянието, транслацията или политиката зависят от виждането на път, който не виждат, и всяко от тях има различно решение. Проверете какво всъщност изисква средното устройство, преди да препроектирате около него.

Издръжливият отговор назовава двата пътя, устройството, което трябва да вижда и двата, и маршрута, който прави това възможно. Ако не можете да назовете устройството, още не сте намерили причината.