SSH bie në VPN çdo minutë? Nuk është keepalive

SSH lidhet, punon rreth një minute dhe më pas ngrin në të njëjtin interval pothuajse çdo herë. Shpjegimi i zakonshëm është një timeout papunësie, kështu që njerëzit ulin MTU-në dhe vendosin keepalive në klient. Lidhja WireGuard ku punova e kishte kaluar tashmë të gjithë këtë: një MTU tuneli më të vogël, cilësime client-alive, një keepalive tuneli të konfiguruar. Ndërprerjet vazhduan të pandryshuara. Shkaku doli të ishte një rrugë LAN asimetrike, dhe modeli ia vlen të njihet sepse mposht çdo rregullim të bazuar në kohëmatës.

Një keepalive provon që hosti yt është ende i gatshëm të dërgojë. Nuk mund ta bëjë një pajisje që mban gjendje të shohë një përgjigje që nuk kalon kurrë përmes saj.

Miti: keepalive rregullojnë një ndërprerje të heshtur

Keepalive-t e SSH ekzistojnë për një detyrë: të pengojnë diçka që numëron heshtjen të heqë një sesion joaktiv. Këtë e bëjnë mirë. Nuk e zgjidhin pajisjen që mban gjendje e cila pa paketën e parë në një drejtim dhe më pas nuk e pa kurrë përgjigjen, sepse asgjë nga ajo që dërgon klienti nuk ndryshon se cilën ndërfaqe përdor përgjigja.

Ndryshimi i MTU-së është rregullimi tjetër popullor dhe ka të njëjtin mënyrë dështimi. Ulja e MTU-së ndihmon fragmentimin dhe problemet e MTU-së së rrugës, dhe nuk bën asgjë për një rrugë. Nëse kohëmatësit dhe MTU-ja janë tashmë të arsyeshme dhe ndërprerja vazhdon në një interval të përsëritur, intervali po të tregon për një timeout diku, jo për madhësinë e paketës. Shkruaje intervalin dhe krahasoje me timeout-et e gjendjes në çdo pajisje të rrugës.

Shenja është rregullsia e kombinuar me një sesion që mbetet i përdorshëm brenda atij intervali. Timeout-et e papunësisë godasin kur nuk ndodh asgjë; ky godet ndërsa ti shkruan.

Çfarë bën në të vërtetë gateway-i shtesë

Vendos laptopin dhe gateway-in VPN në të njëjtën LAN, me një firewall LAN të veçantë si gateway parazgjedhje. Laptopi dërgon trafikun drejt VPN-së te firewall-i, firewall-i e përcjell te gateway-i, dhe përgjigjet e gateway-it kthehen drejt përmes LAN-it te laptopi. Ai këmbë i dytë nuk kalon kurrë përmes firewall-it, kështu që tabela e tij e gjendjes mban gjysmë lidhjeje.

Adresat më poshtë pasqyrojnë atë rregullim:

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

Ridrejtimet dhe trajtimi i gjendjes më pas e kthejnë një handshake funksional në një lidhje që vdes më vonë, jo menjëherë. Vonesa është plakja e zërit të gjendjes ose dështimi i një kontrolli më të rreptë, prandaj intervali duket kaq mekanik.

Asgjë nga kjo nuk shfaqet në konfigurimin e klientit, prandaj kërkimi për të zakonisht nis në skedarin e gabuar.

Zgjidh një rrugë të qëllimshme

Për rregullimin e mësipërm, rrugëtimi i nënrrjetit të largët drejtpërdrejt te gateway-i VPN eliminon gjysmë lidhjen:

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

Këto janë adresa shembull. Hapi tjetër duhet të jetë i arritshëm në LAN-in tënd, prefiksi duhet të jetë rrjeti i largët i synuar, dhe komanda e dytë të tregon rezultatin përpara se të mbështetesh tek ai. Nëse gateway-i nuk është në nënrrjetin tënd, kjo rrugë nuk është rregullimi që do.

Nëse firewall-i është menduar të mbikëqyrë trafikun midis atyre sistemeve, rrugëtimi përreth tij është projektim i gabuar. Në vend të kësaj, lërini të dy drejtimet të kalojnë kufirin dhe konfiguro rrugët në secilën anë në mënyrë që rruga e kthimit të përputhet. Qëllimi është një rrugë e vetme e qëllimshme, jo më pak kontroll gjendjeje.

shënime mbi rrugëtimin asimetrik e Netgate përshkruajnë të njëjtën asimetri në nivel ndërfaqeje dhe problemet e gjendjes që krijon, prandaj lexoji përpara se të lirosh trajtimin e gjendjes globalisht. Shkëputjet e kohëzuara të ngjashme me këtë rast nuk janë provë më vete. Trajto artikullin si përshkrim i një mënyre dështimi dhe më pas provo që rrjeti yt përputhet me të përpara se të ndryshosh politikën globale të gjendjes.

Testoje nga të dy skajet

Lexo rrugën e laptopit drejt destinacionit dhe rrugën e destinacionit kthim drejt laptopit; janë dy vendime të veçanta dhe ndoshta vetëm njëri prej tyre është i gabuar. Një ping që ka sukses nga vetë gateway-i mund ta fshehë plotësisht problemin, sepse niset nga makina e së cilës rruga është tashmë e saktë. Të duhen të dy drejtimet ashtu siç i shohin dy skajet e sesionit real.

Pas rregullimit, rihap SSH dhe mbaje sesionin hapur shumë përtej intervalit që dështonte më parë. Më pas bëje rrugën të përhershme në konfigurimin e rrjetit të miratuar, sepse një komandë e njëhershme nuk është plan rinisjeje dhe problemi do të kthehet në rinisjen tjetër me një mister të ri.

Kur asimetria është në rregull

Rrugëtimi asimetrik është normal në shumë rrjete dhe nuk është i prishur sipas përkufizimit. Bëhet problem kur gjurmimi i gjendjes, përkthimi ose politika varen nga shikimi i një rruge që nuk e shohin, dhe secili prej tyre ka një ilaç të ndryshëm. Kontrollo çfarë kërkon vërtet pajisja e mesme përpara se të ridizajnosh rreth saj.

Përgjigja e qëndrueshme emërton dy rrugët, pajisjen që duhet t'i shohë të dyja dhe rrugën që e bën të mundur. Nëse nuk mund ta emërtosh pajisjen, nuk e ke gjetur ende shkakun.