Bëni që përcjellja IPv4 të zgjasë pas një rinisjeje të portës VPN

Ping-u drejt portës funksionon dhe arritja e çdo gjëje pas saj jo, dhe kjo është forma e një problemi përcjelljeje dhe jo e një problemi tuneli. Dorëzimi lokal drejt portës provon që tuneli u ngrit dhe që caktimi i adresës funksionoi; nuk thotë asgjë për atë nëse bërthama do të kalojë një paketë nga një ndërfaqe në tjetrën. Përpara se të prekni çdo sysctl, konfirmoni që makina është menduar të rrugëtojë këtë trafik dhe gjeni kontekstin e rrjetit që mban ndërfaqen përballë klientit. Pastaj lexoni vlerën atje, dhe jo atje ku udhëzuesi i fundit që lexuat shikoi rastësisht.

Arritja e portës nuk është e njëjtë me përcjelljen

Brenda bërthamës ndodhin dy vendime të veçanta. Dorëzimi në një adresë lokale përfundon udhëtimin e paketës; përcjellja e nxjerr përsëri jashtë përmes një ndërfaqeje tjetër, dhe ky vendim i dytë rregullohet sipas hapësirës së emrave të rrjetit. Një portë mund të jetë plotësisht e arritshme ndërsa përcjellja është e fikur, dhe nga një prompt ping të dyja dështimet duken njësoj.

Shkruani se në cilën ndërfaqe vjen paketa e klientit dhe përmes cilës ndërfaqe del rruga e mëtejshme. Të dyja i përkasin një hapësire të vetme emrash, dhe pikërisht ajo hapësirë mban cilësimin që ka rëndësi.

Lexoni vlerën atje ku paketat janë në të vërtetë

Në një portë që rrugëton në hapësirën e emrave të hostit, një komandë e vetme i përgjigjet pyetjes: sysctl net.ipv4.ip_forward. Kur rruga hyrëse dhe ajo e mëtejshme jetojnë në një hapësirë emrash me emër, pyesni atë hapësirë: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. Vlera e hostit nuk zëvendëson vlerën e hapësirës së emrave, dhe një njësh në host nuk është provë për asgjë.

Jo çdo kontekst rrugëtimi ka një etiketë që mund t'ia jepni ip netns. Mjediset e ekzekutimit të kontejnerëve dhe shërbimet krijojnë hapësira emrash që nuk regjistrohen kurrë nën një emër miqësor, dhe për ato përdorni mjetet e inspektimit të mjedisit. Zëvendësoni vpn-gw me emrin e vërtetë, ose me mekanizmin e mjedisit që arrin të njëjtin kontekst, dhe ndaloni hamendjen në nivel hosti.

Jepini cilësimit një pronar të vetëm

Në një portë hosti konvencionale me systemd, forma e qëndrueshme është një skedar drop-in me një emër të zgjedhur nga administratori, si /etc/sysctl.d/60-vpn-forwarding.conf, që përmban net.ipv4.ip_forward = 1. Shkruani skedarin, pastaj ngarkoni pikërisht atë skedar që të ndryshojë edhe gjendja e gjallë: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, e ndjekur nga një rilexim. Emri i skedarit është shembull dhe jo një shteg VPN i rezervuar, dhe numri fillestar ka rëndësi sepse skedarët e renditur më vonë fitojnë.

Përparësia është vendi ku qëndrueshmëria thyhet në heshtje. Kontrolloni si ngarkuesin e shpërndarjes ashtu edhe drop-in-in tuaj, sepse procps sysctl --system në fund lexon edhe /etc/sysctl.conf, ndërsa rendi sysctl.d i systemd është një sekuencë krejt tjetër. Një caktim më i vonë mund ta kthejë menjëherë të njëjtin çelës, duke e lënë skedarin tuaj të saktë dhe vlerën efektive të gabuar. Mos e mbishkruani një skedar ekzistues administratori për të fituar atë debat; gjeni pronarin dhe ndryshojeni atje.

Një hapësirë emrash e krijuar pas nisjes nuk rregullohet fare nga një drop-in i hostit. Cilësimi i saj i përket asaj që e krijon, qoftë mjedisi i ekzekutimit të kontejnerëve qoftë njësia e furnizimit të hapësirës së emrave. T'i japësh një kontejneri privilegje të gjera hosti për të shmangur pyetjen është një marrëveshje më e keqe sesa të shpenzosh dhjetë minuta duke identifikuar pronarin e saktë.

Dijeni sa kushton çelësi përpara se ta ktheni

ip_forward nuk është një boolean i padëmshëm. Dokumentacioni i bërthamës vëren se ndryshimi i tij rivendos disa parametra të tjerë IPv4 në vlerat e paracaktuara të hostit ose të rrugëtuesit, prandaj një kthim diagnostik mund të hedhë poshtë rregullime të bëra diku tjetër dhe të mos e përmendë kurrë. Trajtojeni si një ndryshim konfigurimi me efekte anësore dhe jo si një provë që mund të ekzekutohet me lehtësi.

Kjo gjithashtu përjashton fikjen dhe ndezjen e tij sa herë që një klient nuk arrin një host. Nëse vlera është tashmë një, defekti është diku tjetër në rrugë, dhe rishkrimi i të njëjtit çelës për herë të tretë nuk do ta lëvizë.

Provoni qëndrueshmërinë, pastaj testoni pjesën tjetër të rrugës

Rilexoni vlerën në katër momente: menjëherë pas ndryshimit, pasi shfaqet ndërfaqja VPN, pas një rilidhjeje dhe pas një rinisjeje të planifikuar. Një vlerë që kthehet pas në cilindo nga ato pika ka një pronar të dytë, dhe një shkrim tjetër i vetëm thjesht e fsheh atë deri në rinisjen tjetër.

Përcjellja e aktivizuar ende lë tre gjëra për t'u verifikuar. Klienti ka nevojë për një rrugë drejt destinacionit, porta ka nevojë për një rrugë të mëtejshme plus leje për ta përdorur, dhe destinacioni ka nevojë për një rrugë kthimi drejt adresës së tunelit të klientit. Një LAN privat i rrugëtuar nuk ka nevojë automatikisht për NAT, prandaj mos shtoni masquerading përpara se të dini cila nga të tre mungon, dhe testoni nga klienti i synuar dhe jo nga vetë porta, sepse një kërkesë e nisur në portë nuk e prek kurrë rrugën e përcjelljes që sapo aktivizuat. IPv6 ka politikën e vet të përcjelljes dhe të rrugëtimit, prandaj një test IPv4 që funksionon nuk thotë asgjë për të.

Mbani së bashku në runbook shtegun e drop-in, pronarin e hapësirës së emrave dhe komandën e rileximit. Kushdo që e merr këtë më pas duhet të mund të lexojë vlerën, të shohë kush e zotëron dhe të vendosë brenda një minute nëse problemi është qëndrueshmëria apo pjesa tjetër e rrugës.