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 и држите сесију отворену много дуже од интервала који је раније падао. Затим учините руту трајном у одобреној мрежној конфигурацији, јер једнократна команда није план рестартовања и проблем ће се вратити при следећем рестартовању са новом мистеријом.

Када је асиметрија у реду

Асиметрично рутирање је нормално у многим мрежама и није покварено по дефиницији. Постаје проблем када праћење стања, превођење или политика зависе од виђења путање коју не виде, и свако од тога има другачији лек. Проверите шта средњи уређај заиста захтева пре него што га редизајнирате.

Трајан одговор именује две путање, уређај који мора да види обе и руту која то омогућава. Ако не можете да именујете уређај, још увек нисте нашли узрок.