Klientët në rrjedhën e poshtme pas një VPN në rrjedhën e sipërme: rrugë apo NAT?

Një portë ekzekuton WireGuard për pajisjet e tua dhe një klient OpenVPN drejt rrjetit të dikujt tjetër. Përcjellja mes dy ndërfaqeve të brendshme funksionon, dhe është e lehtë të konkludosh se nënrrjeta e poshtme është tani pjesë e shërbimit të sipërm. Nuk është. Rruga që klienti tërheq i thotë portës sate ku të dërgojë kërkesat; nuk thotë asgjë për mënyrën se si rrjeta e largët ua kthen trafikun pajisjeve për të cilat nuk ka dëgjuar kurrë. Zgjidh një model kthimi që shërbimi i sipërm e mbështet vërtet përpara se të shtosh një rregull të vetëm.

Vendos modelin e kthimit përpara se të prekësh rrugëtimin

Në këtë udhëzues, klientët e poshtëm përdorin 10.90.0.0/24, adresa e tunelit të sipërm që i është caktuar portës është 10.80.0.6, dhe burimi i largët i miratuar është 172.20.0.30. Dy modele përshtaten me këtë formë: ruaj burimin e poshtëm dhe bëj që ana e largët ta rrugëtojë, ose përkthe burimin në adresën e tunelit të vetë portës. Gjithçka pas këtij vendimi është mekanike, dhe vetë vendimi kërkon pronarin e shërbimit. Njëri rresht më sipër është marrëveshje rrugëtimi me anën e largët; tjetri është një ndryshim lokal politike që mund ta bësh vetë. Ngatërrimi i të dyjave është ai që e kthen një ndryshim dhjetë minutash në një negociatë.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

Zgjidh një rresht dhe qëndro në të. Rreshtat janë alternativa, jo hapa, dhe përzierja e tyre prodhon një dizajn që askush nuk mund ta shpjegojë në rishikim.

Ruajtja e burimit me rrugëtim

Ana e largët merr një kërkesë nga një adresë e poshtme, prandaj i duhet një rrugë e mbështetur dhe pronësi peer për atë nënrrjetë, si dhe autorizim për ta pranuar. Këto janë cilësime të largëta, dhe asnjë rrugë lokale Linux nuk i krijon. Kërkoji shprehimisht dhe me shkrim, me prefiksin dhe peer-in e tunelit që do ta mbajë, dhe prit që përgjigjja të varet nga fakti nëse shërbimi mbështet fare marrëveshje nga sajti në sajt.

Nëse përgjigjja është po, konfigurimi lokal është i vogël: përcjellja e aktivizuar, allowed-ips e peer-it WireGuard që mbulojnë intervalin e poshtëm, dhe një politikë firewall që lejon kalimin në të dy drejtimet.

Përkthim burimi i qëllimshëm

Nëse shërbimi e kthen trafikun vetëm te adresa e klientit të lidhur, përkthe burimin në atë adresë në dalje dhe mbaj gjendjen conntrack që e kthen mbrapsht për përgjigjet. Kufizo rregullin te burimet e poshtme të synuara, destinacionet e largëta të synuara dhe ndërfaqja e sipërme. Një rregull që përkthen gjithçka që del nga çdo ndërfaqe është një politikë shumë më e madhe sesa kjo kërkesë, dhe do të të befasojë më vonë.

IPv6 kërkon dizajnin e vet; kopjimi i një rreshti masquerade për IPv4 nuk është arkitekturë. Testo rrugën e përkthyer me një lidhje të re, jo me një të ruajtur në cache.

Rruga lokale e të dhënave duhet të funksionojë gjithsesi

Përkthimi nuk e heq punën lokale: porta ende ka nevojë për një rrugë drejt destinacioneve të poshtme, pronësinë e saktë të burimit të peer-it WireGuard, përcjelljen e aktivizuar dhe një politikë të ngushtë firewall mes ndërfaqeve. Një kërkesë e krijuar në vetë portën nuk ushtron asnjë prej atyre lejeve, dhe për këtë arsye testet lokale në portë kalojnë ndërsa pajisjet e poshtme vazhdojnë të dështojnë.

Testo nga një pajisje e vërtetë e poshtme, jo nga porta. Adresa e burimit është i gjithë qëllimi i këtij ushtrimi.

Një burim do të thotë një identitet sesioni

Shërbimi i largët sheh sesionin e autentikuar të portës dhe adresën e tij të përkthyer, jo një autentikim të pavarur për çdo pajisje të poshtme. Mbaj të qarta lejet për pajisje dhe identitetet e aplikacioneve, dhe konfirmo me pronarin e shërbimit se një portë që vepron për disa pajisje lejohet fare. Përkthimi nuk është mënyrë për të anashkaluar kërkesën e regjistrimit për çdo pajisje; nëse shërbimi kërkon që çdo pajisje të regjistrohet, përdor atë model ose negocio një marrëveshje nga sajti në sajt.

Shkruaje atë konfirmim në runbook pranë rregullit, sepse rishikuesi i ardhshëm do të pyesë nëse dizajni u miratua apo ishte thjesht i përshtatshëm.

Përcakto gjendjen e shkëputjes, pastaj testo tri kërkesa

Vendos çfarë ndodh kur tuneli i sipërm bie. Trafiku i largët i autorizuar nuk duhet të ndjekë në heshtje një rrugë rezervë të zakonshme WAN atje ku kjo ndalohet, prandaj politika e firewall-it që lejon kalimin duhet gjithashtu të dështojë e mbyllur. Pastaj testo tri raste nga një pajisje e vërtetë e poshtme: një kërkesë e lejuar që funksionon, një kërkesë e ndaluar që dështon, dhe një dështim i sipërm që ndalon atë të lejuarën.

Regjistro kthimin mbrapsht në një rresht për çdo rregull, që ndryshimi të mund të anulohet pa rindërtuar qëllimin.