SSH katkeb VPN-is iga minut? Süüdi pole keepalive

SSH ühendub, töötab umbes minuti ja külmub siis iga kord ligikaudu sama intervalliga. Tavaline seletus on jõudetõrje, seega inimesed langetavad MTU-d ja seavad kliendi keepalive'id. WireGuardi link, mille kallal töötasin, oli selle kõik juba läbi teinud: väiksem tunnel-MTU, client-alive seaded, konfigureeritud tunnel-keepalive. Katkestused jätkusid muutumatult. Põhjuseks osutus asümmeetriline LAN-marsruut ja muster tasub ära tunda, sest see võidab iga taimeripõhise paranduse.

Keepalive tõestab, et sinu host on endiselt valmis saatma. See ei suuda panna olekut pidavat seadet nägema vastust, mis ei läbi seda kunagi.

Müüt: keepalive'id parandavad vaikse katkestuse

SSH keepalive'id on ühe töö jaoks: takistada midagi, mis loeb vaikust, jõudeolevat sessiooni kõrvaldamast. Seda nad teevad hästi. Nad ei lahenda olekut pidava seadme probleemi, mis nägi esimest paketti ühes suunas ja ei näinud seejärel kunagi vastust, sest miski, mida klient saadab, ei muuda, millist liidest vastus kasutab.

MTU muutmine on teine populaarne parandus ja sellel on sama rikkerežiim. MTU langetamine aitab killustumise ja tee-MTU probleemide puhul ega tee marsruudile midagi. Kui sinu taimerid ja MTU on juba mõistlikud ning katkestus on endiselt korduva intervalliga, räägib intervall sulle kuskil olevast taimerist, mitte paketi suurusest. Kirjuta intervall üles ja võrdle seda oleku taimeritega igal seadmel teel.

Märk on korrapärasus koos sessioga, mis jääb selle intervalli sees kasutatavaks. Jõudetõrjed tabavad siis, kui midagi ei juhtu; see tabab siis, kui sa trükid.

Mida lisavärav tegelikult teeb

Aseta sülearvuti ja VPN-värav samasse LAN-i, eraldi LAN-tulemüür vaikeväravana. Sülearvuti saadab VPN-i suunduva liikluse tulemüürile, tulemüür edastab selle väravale ja värava vastused lähevad otse üle LAN-i tagasi sülearvutisse. See teine jalg ei läbi kunagi tulemüüri, seega hoiab selle olekutabel poolt ühendust.

Allolevad aadressid peegeldavad seda paigutust:

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

Ümbersuunamised ja olekukäsitlus muudavad siis toimiva käepigistuse ühenduseks, mis sureb hiljem, mitte kohe. Viivitus on olekukirje vananemine või rangema kontrolli nurjumine, mistõttu intervall näeb nii mehaaniline välja.

Midagi sellest ei ilmu kliendi konfiguratsioonis, mistõttu algab selle otsimine tavaliselt vales failis.

Vali üks teadlik tee

Ülaltoodud paigutuse puhul eemaldab kaugema alavõrgu suunamine otse VPN-väravale poole ühenduse:

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

Need on näidisaadressid. Järgmine hüpe peab olema sinu LAN-is kättesaadav, eesliide peab olema kavandatud kaugvõrk ja teine käsk näitab tulemust enne, kui sellele lootma jääd. Kui värav pole sinu alavõrgus, ei ole see marsruut see parandus, mida sa tahad.

Kui tulemüür peaks nende süsteemide vahelist liiklust valvama, on sellest mööda marsruutimine vale disain. Lase selle asemel mõlemal suunal piiri ületada ja sea marsruudid kummalgi poolel nii, et tagasitee klapiks. Eesmärk on üks teadlik tee, mitte vähem olekukontrolli.

Netgate'i märkmed asümmeetrilise marsruutimise kohta kirjeldavad sama asümmeetriat liidese tasandil ja olekuprobleeme, mida see tekitab, seega loe neid enne, kui olekukäsitlust globaalselt lõdvendad. Selle juhtumiga sarnanevad ajastatud katkestused ei ole iseenesest tõestus. Käsitle artiklit ühe rikkerežiimi kirjeldusena ja tõesta seejärel, et sinu enda võrk sellele vastab, enne kui muudad globaalset olekupoliitikat.

Testi mõlemast otsast

Loe sülearvuti marsruuti sihtkoha poole ja sihtkoha marsruuti tagasi sülearvuti poole; need on kaks eraldi otsust ja tõenäoliselt on ainult üks neist vale. Ping, mis õnnestub värava enda pealt, võib probleemi täielikult peita, sest see algab masinast, mille tee on juba õige. Sul on vaja mõlemat suunda nii, nagu neid näevad tegeliku sessiooni kaks otsa.

Pärast parandust ava SSH uuesti ja hoia sessiooni lahti kaugele üle selle intervalli, mis varem nurjus. Seejärel tee marsruut püsivaks kinnitatud võrgukonfiguratsioonis, sest ühekordne käsk ei ole taaskäivituse plaan ja probleem naaseb järgmisel taaskäivitamisel uue mõistatusega.

Millal asümmeetria on korras

Asümmeetriline marsruutimine on paljudes võrkudes normaalne ja pole definitsiooni järgi katki. Sellest saab probleem siis, kui olekujälgimine, tõlkimine või poliitika sõltuvad tee nägemisest, mida nad ei näe, ja igal neist on erinev ravim. Kontrolli, mida keskmine seade tegelikult nõuab, enne kui selle ümber ümber kujundad.

Püsiv vastus nimetab kaks teed, seadme, mis peab nägema mõlemat, ja marsruudi, mis selle võimalikuks teeb. Kui sa ei suuda seadet nimetada, pole sa veel põhjust leidnud.