Dy faqe, një nënrrjetë, një hub WireGuard: bëjeni të funksionojë

Të dyja faqet përdorin të njëjtin interval LAN, dhe mbivendosja nuk është ajo që e prish vërtet projektin. Hub-i duhet ta zgjedhë faqen vetëm sipas adresës së destinacionit, dhe dy destinacione identike nuk i japin asgjë për të zgjedhur. Rinumerimi i një zyre që funksionon për të kënaqur një tunel është zakonisht një shkëmbim më i keq sesa t'i japësh çdo shërbimi të publikuar një adresë të veçantë që tuneli mund ta mbajë. Projekti më poshtë publikon një shërbim HTTPS për faqe dhe asgjë tjetër.

Pse mbivendosja nuk është problemi i vërtetë

WireGuard përcjell sipas destinacionit: AllowedIPs e një peer-i përcaktojnë se cili peer merr një paketë. Dy peer nuk mund të shpallin të dy 10.10.7.0/24 pa fituar njëri prej tyre çdo kërkim. Kjo është veti e tabelës së peer-ëve dhe jo e tunelit, prandaj zgjidhja këtu është një plan adresash dhe jo një mashtrim rrugëtimi.

Plani është të ndalojmë plotësisht shpalljen e LAN-it. Në vend të kësaj shpallni një alias për çdo shërbim, një adresë për faqe, dhe lëreni portën e çdo faqe ta përkthejë atë alias në aplikacionin e vet të vërtetë.

Përdoruesi rrugëton dy adresa unike, nuk e sheh kurrë prefiksin e paqartë, dhe asgjë nuk ndryshon në asnjërën nga dy zyrat. Kjo e thotë edhe kufirin me ndershmëri: ju po publikoni një shërbim HTTPS nga çdo faqe, nuk po bashkoni dy rrjete. Rregullat që vijojnë mbeten të vogla sepse deklarata është e ngushtë. Një deklaratë më e gjerë do të kërkonte rregulla më të gjera, dhe pikërisht kështu këto projekte bëhen të ndërlikuara.

Jepini çdo faqeje një alias që përdoruesi mund ta rrugëtojë

Zgjidhni adresa nga një interval që nuk përplaset me asgjë në makinën e përdoruesit, hub-in ose në ndonjë nga dy LAN-et. Këtu hub-i është 10.66.0.1, përdoruesi është 10.66.0.10, portat janë 10.66.0.21 dhe 10.66.0.22, dhe dy alias-et janë 10.77.1.20 dhe 10.77.2.20. Hub-i publikon çdo alias përmes peer-it që e zotëron, kështu që një paketë dalëse drejtuar një alias mund të dalë vetëm përmes faqes përkatëse:

[Interface]
Address = 10.66.0.1/32
ListenPort = 51820
PrivateKey = HUB_KEY

[Peer]
PublicKey = USER_PUBLIC_KEY
AllowedIPs = 10.66.0.10/32

[Peer]
PublicKey = SITE_A_PUBLIC_KEY
AllowedIPs = 10.66.0.21/32, 10.77.1.20/32

[Peer]
PublicKey = SITE_B_PUBLIC_KEY
AllowedIPs = 10.66.0.22/32, 10.77.2.20/32

Ana e përdoruesit ka nevojë vetëm për dy alias-et, gjë që e mban konfigurimin e klientit të lirë nga të dy prefikset LAN. Asgjë në atë konfigurim nuk përmend ndonjë nga LAN-et e vërteta:

[Interface]
Address = 10.66.0.10/32
PrivateKey = USER_KEY

[Peer]
PublicKey = HUB_PUBLIC_KEY
Endpoint = hub.example.net:51820
AllowedIPs = 10.77.1.20/32, 10.77.2.20/32
PersistentKeepalive = 25

Çdo portë shpall hub-in dhe burimin e përdoruesit, asgjë tjetër, kështu që një faqe nuk e mëson kurrë LAN-in e faqes tjetër. Keepalive mban një mapim NAT në uplink-un e faqes; nuk autorizon trafikun, dhe firewali ende vendos çfarë pranohet. Kopjimi i konfigurimit nga një portë në tjetrën është në rregull për sa kohë çelësi privat, adresa e ndërfaqes dhe alias-i ndryshojnë të gjithë.

Çfarë duhet të lejojë hub-i midis dy peer-ëve të vet

Hub-i përcjell paketa midis dy peer-ëve të vet, gjë që është një vendim në zinxhirin forward dhe jo një vendim hyrjeje. Aktivizoni përcjelljen IPv4 përmes mekanizmit të zakonshëm të platformës, pastaj lejoni saktësisht çiftet që i nevojiten projektit.

Rregulli më poshtë i lejon përdoruesit një alias dhe një portë, dhe lejon trafikun e kthimit përmes gjurmimit të lidhjeve. Ai hedh poshtë çdo gjë tjetër në rrugën forward, dhe ky është qëllimi:

nft add table inet hub_transit
nft add chain inet hub_transit forward '{ type filter hook forward priority 0 ; policy drop ; }'
nft add rule inet hub_transit forward ct state established,related accept
nft add rule inet hub_transit forward iifname wg0 oifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 accept

Dy detaje ia vlen të përmenden sepse shkaktojnë dështime të heshtura. Një accept në një zinxhir bazë nuk e anulon një drop në një tjetër, prandaj bashkojeni këtë me politikën ekzistuese në vend që ta ngarkoni pranë saj. Dhe adresa e burimit identifikon pajisjen, jo personin; mbani vërtetimin e aplikacionit të ndarë nga pranimi në rrjet.

Ku një alias bëhet adresë e vërtetë

Faqja A merr një kërkesë për 10.77.1.20, rishkruan destinacionin në aplikacionin e vërtetë dhe rishkruan burimin në adresën e vet LAN, që përgjigjja të mund të kthehet pa një rrugë drejt tunelit. Kryerja e të dy përkthimeve në një vend e mban pjesën tjetër të rrjetit të paditur për alias-in. Rregullat më poshtë janë i gjithë mekanizmi:

nft add table ip site_a_nat
nft add chain ip site_a_nat pre '{ type nat hook prerouting priority -100 ; policy accept ; }'
nft add chain ip site_a_nat post '{ type nat hook postrouting priority 100 ; policy accept ; }'
nft add rule ip site_a_nat pre iifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 dnat to 10.10.7.20:443
nft add rule ip site_a_nat post iifname wg0 oifname lan0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.10.7.20 snat to 10.10.7.2

Politika forward e faqes A duhet pastaj ta lejojë rrjedhën e përkthyer nga ndërfaqja e tunelit në ndërfaqen LAN, plus drejtimin e kthimit. Hook-u forward e sheh destinacionin pas përkthimit të destinacionit dhe përpara rishkrimit të burimit, prandaj rregulli emërton adresën e aplikacionit të vërtetë. Lexoni ato dy hook në atë rend sa herë që një rregull duket se nuk përputhet me asgjë. Një rregull forward i shkruar kundër alias-it nuk mund të përputhet kurrë, sepse alias-i nuk ekziston më në atë hook.

Faqja B e përsërit këtë me alias-in dhe çelësin e vet. Nuk duhet ta ripërdorë çelësin privat të faqes A, sepse dy peer që ndajnë një identitet janë një gabim konfigurimi i vështirë për t'u parë dhe i lehtë për t'u krijuar duke kopjuar një skedar. Mbani të dy dokumentet e portës identike përveç vlerave që duhet të ndryshojnë, që ndryshimi të dalë në pah gjatë rishikimit. Një skedar i kopjuar është origjina e zakonshme e atij defekti.

Rishkrimi i burimit ka një kosto. Aplikacioni e sheh portën si klientin e vet, prandaj regjistrat e saj nuk tregojnë më se cili përdorues u lidh. Ruani gjurmën e auditimit të portës dhe mos e dobësoni hyrjen në aplikacion për të kompensuar një identitet rrjeti që përkthimi e hoqi.

Si të provohet se të dy emrat e publikuar përgjigjen

Jepini çdo alias-i një emër DNS dhe konfiguroni aplikacionin dhe certifikatën për atë emër, sepse përkthimi nuk i rishkruan ridrejtimeve ose URL-të absolute të ngulitura. Përdorni një emër për faqe që një mospërputhje certifikate të mos ngatërrohet kurrë me një defekt rrugëtimi.

Testoni nga klienti i vërtetë, konfirmoni cila faqe u përgjigj dhe testoni gjithashtu një portë të paautorizuar. Përdorni lidhje të reja pas çdo ndryshimi NAT, pasi gjendja e vendosur mban mapimin e vjetër:

wg show wg0 allowed-ips
sudo nft list ruleset
curl -sS -o /dev/null -w "%{http_code}\n" https://site-a.example.net/

Një alias bosh ose i papritur në komandën e parë do të thotë që zgjedhja e peer-it është e gabuar përpara se ndonjë rregull firewali të ketë rëndësi. Nëse alias-i është i saktë dhe emri vazhdon të dështojë, problemi ka kaluar në DNS dhe certifikata. Sapo të dy emrat përgjigjen dhe porta e tretë mbetet e mbyllur, projekti bën atë që pretendon: dy shërbime të publikuara në mënyrë të ngushtë, jo dy LAN të bashkuara.