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

Кога асиметријата е во ред

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

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