Një host i vetëm publik për VPN dhe web: si t'i ndash rolet

Një makinë e vetme mund të plotësojë të tre nevojat njëherësh: të përfundojë tunelet, të përgjigjet për HTTPS dhe të përcjellë midis dy rrjeteve LAN private. Nëse kjo është e arsyeshme, varet nga tre gjëra që mund t'i zgjidhësh në letër: kush e zotëron adresën publike, kush e zotëron çdo çift porti dhe protokolli dhe cilit proces i lejohet të përcjellë paketa. Nëse këto janë të sakta, hosti i përbashkët nuk ka asgjë të veçantë. Nëse janë të gabuara, do të kalosh një fundjavë me një shërbim që niset pastër dhe nuk përgjigjet kurrë.

Ajo që vijon është një procedurë vendimi, jo një fletë ndërtimi. Çdo hap përfundon me kontrollin që vërteton se roli që sapo shtove është vërtet i izoluar.

Zgjidh pronarin e adresës para porteve

Një pikë fundore tuneli dhe një server web mund të ndajnë një kernel; ndarja e një adrese, porte dhe protokolli në të njëjtën kohë është ajo që dështon. WireGuard zakonisht merr UDP 51820, OpenVPN merr UDP 1194 ose TCP 443, dhe një server web merr TCP 443. Çifti që të dhemb është OpenVPN mbi TCP 443 pranë HTTPS, sepse të dy duan të njëjtin socket dhe kernel-i ia jep atij që u lidh i pari. Vetëm një demultiplekser përpara, si sslh ose një proxy që njeh TLS, i lejon ta ndajnë atë port, dhe shton një komponent, dështimi i të cilit duket saktësisht si problem i firewall-it.

Shiko pronarët para se të ndryshosh çdo gjë: ss -lntup printon adresën lokale, portin dhe procesin e çdo socket-i që dëgjon. Dy rreshta që tregojnë 0.0.0.0:443 nënkuptojnë se shërbimi i dytë nuk u lidh kurrë, sado i gëzuar të ishte skripti init. Ura zhvendos edhe pronarin. Kur eth0 bashkohet me br0, IP kalon te br0 dhe çdo rregull firewall që emërton eth0 pushon së përputhuri, ndaj lidh shërbimet në urë dhe konfirmo me ip -br addr.

I njëjti rregull pronësie shpjegon një surprizë që shfaqet me makinat virtuale. Një server tuneli që xhiron brenda një mysafiri në të njëjtin LAN mban adresën e mysafirit, ndaj lidhjet e drejtuara nga adresa e vetë hostit mbeten në host dhe tuneli i mysafirit nuk i sheh kurrë, çfarëdo që thotë profili i klientit.

Ruto midis dy rrjeteve LAN ose bëj NAT njërën anë

Dy rrjete LAN që nuk shihen dot mund të telefonojnë secili hostin publik, i cili pastaj përcjell midis tuneleve. Ky dizajn i rutuar kërkon tre gjëra: përcjellje e ndezur, një rrugë drejt çdo prefiksi të largët dhe një politikë përcjelljeje që lejon tranzitin të kalojë. sysctl -w net.ipv4.ip_forward=1 mbulon të parën, ip route add 10.20.0.0/24 dev wg1 të dytën, dhe një rresht nftables si nft add rule inet filter forward iifname "wg0" oifname "wg1" accept të tretën.

NAT-i i burimit është më i lehtë për t'u shtuar dhe më i vështirë për t'u korrigjuar. Maskimi rishkruan adresën e klientit, ndaj pala e largët sheh hub-in në vend të hostit të vërtetë, dhe rregullat e aksesit e regjistrat e tij nuk janë më të dobishëm për atribuim. Kur të dy rrjetet janë të tuat, ruto. Kur njëra anë i përket një pale të tretë që nuk do të shtojë një rrugë kthimi, NAT-i është opsioni që niset këtë javë. Sido që të jetë, shkruaj planin e adresave, sepse dy /24 të mbivendosura nuk mund t'i rutoje asnjë konfigurim.

Asgjë në faktin që kutia shërben si dalje interneti për një laptop nuk e pengon të njëjtën kuti të përfundojë tunele hyrëse. Vetëm adresat e mbivendosura e pengojnë, dhe prandaj plani i adresave është dokumenti që ka rëndësi.

Testo ndarjen ndërsa dy role janë ndalur

Testi i dobishëm është zbritja: ndal dy role dhe konfirmo që i treti përsëri përgjigjet. Një kërkesë web duhet të përfundojë me shërbimin e tunelit të fikur, dhe një shtrëngim duarsh i tunelit duhet të përfundojë me serverin web të ndalur. Nëse të dyja funksionojnë vetëm kur gjithçka xhiron, ke një varësi aksidentale, si një tabelë firewall e përbashkët, një rrugë e humbur ose një emër që tregon adresën e gabuar.

Tre komanda e bëjnë atë test konkret. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ vërteton se dëgjuesi lokal përgjigjet pa DNS të jashtëm, wg show në klient vërteton se shtrëngimi i duarve përfundoi, dhe tcpdump -ni any port 51820 në hub ndan problemin e rutimit nga problemi i çelësit. Një shtrëngim duarsh që nuk shfaqet kurrë në kapje ka vdekur para hostit: firewall-i i ofruesit, adresë publike e gabuar ose një rregull NAT në rrugë.

Përsërit zbritjen për rrjetet LAN që përcillen. Me një palë të shkëputur, një ping përmes hub-it duhet të dështojë; kur rilidhet, ping-u duhet të rikuperohet pa prekur një rregull. Një ping që rikuperohet vetëm pas rinisjes së tunelit tregon politikën dhe jo arritshmërinë, dhe ky është një rregullim tjetër.

Mbaje grupin e rregullave të lexueshëm ndërsa zbret role. nft list ruleset duhet të tregojë një rregull lejimi për çdo drejtim që të duhet vërtet, dhe një zinxhir përcjelljeje që pranon gjithçka nuk është ndarje, është një demonstrim që funksionon.

Linja aksesi vetëm IPv6 dhe shërbime IPv4

Disa linja aksesi japin vetëm arritshmëri IPv6, dhe shërbimet duhet të publikohen ende përmes IPv4. Vetë tuneli udhëton përmes familjes që ende lejon trafikun, ndërsa shërbimi i publikuar qëndron në një adresë brenda tunelit. Kjo përmbys supozimin e zakonshëm dhe prish monitorimin në heshtje: një rregull firewall ose një kontroll uptime i shkruar për rrugën IPv4 tani vëzhgon një ndërfaqe që nuk mbart asgjë.

Testo çdo familje veçmas me curl -4 dhe curl -6, sepse një kërkesë e suksesshme nuk thotë asgjë për rrugën që nuk e provove. Pronësia e porteve nuk ndryshon midis familjeve, por dëgjuesi ndryshon: ss -lntup liston socket-et IPv4 dhe IPv6 në rreshta të veçantë, dhe 0.0.0.0:443 nuk mbulon [::]:443 nëse procesi nuk ka kërkuar një socket dual-stack.

Një shërbim që përgjigjet në një familje dhe refuzon në tjetrën është zakonisht problem i dëgjuesit, jo i rutimit. Para se ta shpallësh dizajnin të përfunduar, konfirmo që çdo rol zotëron adresën ose portin e vet, se përcjellja është e ndezur dhe e lejuar, dhe se çdo rol përsëri përgjigjet me dy të tjerët të ndalur.