SSH kas minutę nutrūksta VPN? Kaltas ne keepalive

SSH prisijungia, veikia apie minutę, o paskui kiekvieną kartą sustingsta maždaug tuo pačiu intervalu. Įprastas paaiškinimas yra neveiklumo laiko limitas, todėl žmonės sumažina MTU ir nustato kliento keepalive. WireGuard ryšys, su kuriuo dirbau, jau buvo visa tai išbandęs: mažesnis tunelio MTU, client-alive nustatymai, sukonfigūruotas tunelio keepalive. Nutrūkimai tęsėsi nepakitę. Priežastis buvo asimetrinis LAN maršrutas, ir šį modelį verta atpažinti, nes jis nugali bet kurį laikmačiais pagrįstą sprendimą.

Keepalive įrodo, kad jūsų pagrindinis kompiuteris dar pasirengęs siųsti. Jis negali priversti būseną saugančio įrenginio pamatyti atsakymo, kuris niekada per jį nepereina.

Mitas: keepalive ištaiso tylų nutrūkimą

SSH keepalive egzistuoja vienai užduočiai: neleisti kažkam, kas skaičiuoja tylą, pašalinti neveiklios sesijos. Tai jie daro gerai. Jie neišsprendžia būseną saugančio įrenginio, kuris pamatė pirmą paketą viena kryptimi ir paskui niekada nepamatė atsakymo, nes niekas, ką siunčia klientas, nekeičia, kurią sąsają naudoja atsakymas.

MTU pakeitimas yra kitas populiarus sprendimas, ir jis turi tą patį gedimo būdą. MTU sumažinimas padeda fragmentacijai ir kelio MTU problemoms, o maršrutui nieko nedaro. Jei jūsų laikmačiai ir MTU jau yra pagrįsti, o nutrūkimas vis dar pasikartojančiu intervalu, intervalas jums kalba apie kažkur esantį laiko limitą, o ne apie paketo dydį. Užsirašykite intervalą ir palyginkite jį su būsenos laiko limitais kiekviename kelyje esančiame įrenginyje.

Požymis yra reguliarumas kartu su sesija, kuri išlieka naudojama tame intervale. Neveiklumo laiko limitai smogia, kai nieko nevyksta; šis smogia, kai rašote.

Ką iš tikrųjų daro papildomas šliuzas

Padėkite nešiojamąjį kompiuterį ir VPN šliuzą į tą patį LAN, atskirą LAN ugniasienę kaip numatytąjį šliuzą. Nešiojamasis kompiuteris siunčia VPN skirtą srautą ugniasienei, ugniasienė perduoda jį šliuzui, ir šliuzo atsakymai grįžta tiesiai per LAN į nešiojamąjį kompiuterį. Ta antroji atkarpa niekada nepereina ugniasienės, todėl jos būsenos lentelė laiko pusę ryšio.

Toliau pateikti adresai atspindi tą išdėstymą:

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

Peradresavimai ir būsenos tvarkymas tada paverčia veikiantį rankos paspaudimą ryšiu, kuris miršta vėliau, o ne iš karto. Vėlavimas yra senstanti būsenos įrašas arba griežtesnio patikrinimo gedimas, todėl intervalas atrodo toks mechaniškas.

Niekas iš to neatsiranda kliento konfigūracijoje, todėl jo paieška paprastai prasideda ne tame faile.

Pasirinkite vieną apgalvotą kelią

Aukščiau pateiktam išdėstymui tolimo potinklio maršrutizavimas tiesiai į VPN šliuzą pašalina pusę ryšio:

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

Tai pavyzdiniai adresai. Kitas šuolis turi būti pasiekiamas jūsų LAN, priešdėlis turi būti numatytas tolimas tinklas, o antroji komanda parodo rezultatą prieš juo pasikliaujant. Jei šliuzas yra ne jūsų potinkyje, šis maršrutas nėra tas sprendimas, kurio norite.

Jei ugniasienė skirta stebėti srautą tarp tų sistemų, maršrutizavimas aplink ją yra neteisingas dizainas. Vietoj to leiskite abiem kryptims kirsti ribą ir sukonfigūruokite maršrutus kiekvienoje pusėje, kad grįžimo kelias sutaptų. Tikslas yra vienas apgalvotas kelias, o ne mažiau būsenos tikrinimo.

Netgate pastabos apie asimetrinį maršrutizavimą aprašo tą pačią sąsajos lygio asimetriją ir būsenos problemas, kurias ji sukuria, todėl perskaitykite jas prieš pasauliškai atlaisvindami būsenos tvarkymą. Į šį atvejį panašūs laiko nutrūkimai patys savaime nėra įrodymas. Traktuokite straipsnį kaip vieno gedimo būdo aprašymą, tada įrodykite, kad jūsų tinklas jį atitinka, prieš keisdami pasaulinę būsenos politiką.

Išbandykite iš abiejų galų

Perskaitykite nešiojamojo kompiuterio maršrutą link paskirties vietos ir paskirties vietos maršrutą atgal link nešiojamojo kompiuterio; tai du atskiri sprendimai ir greičiausiai tik vienas jų yra neteisingas. Ping, kuris pavyksta iš paties šliuzo, gali visiškai paslėpti problemą, nes jis kyla iš mašinos, kurios kelias jau teisingas. Jums reikia abiejų krypčių taip, kaip jas mato du tikrosios sesijos galai.

Po pataisymo vėl atidarykite SSH ir laikykite sesiją atvirą gerokai ilgiau nei intervalas, kuris anksčiau nepavykdavo. Tada padarykite maršrutą nuolatiniu patvirtintoje tinklo konfigūracijoje, nes vienkartinė komanda nėra perkrovimo planas ir problema grįš kitą kartą perkraunant su nauja mįsle.

Kada asimetrija yra gerai

Asimetrinis maršrutizavimas daugelyje tinklų yra normalus ir pagal apibrėžimą nesugadintas. Jis tampa problema, kai būsenos sekimas, vertimas ar politika priklauso nuo kelio, kurio jie nemato, matymo, ir kiekvienas iš jų turi skirtingą sprendimą. Patikrinkite, ko iš tikrųjų reikalauja vidurinis įrenginys, prieš perdarydami aplink jį.

Ilgalaikis atsakymas įvardija du kelius, įrenginį, kuris turi matyti abu, ir maršrutą, kuris tai padaro įmanoma. Jei negalite įvardyti įrenginio, dar neradote priežasties.