En sam javni gostitelj za VPN in splet: kako razdeliti vloge

En stroj lahko zadovolji vse tri potrebe hkrati: zaključuje tunele, odgovarja na HTTPS in posreduje med dvema zasebnima omrežjema LAN. Ali je to smiselno, se zoži na tri stvari, ki jih je mogoče urediti na papirju: komu pripada javni naslov, komu pripada vsak par vrat in protokola ter kateremu procesu je dovoljeno posredovati pakete. Če to zadeneš, skupni gostitelj ni nič posebnega. Če zgrešiš, boš preživel vikend s storitvijo, ki se čisto zažene in nikoli ne odgovori.

Kar sledi, je postopek odločanja, ne gradbeni list. Vsak korak se konča s preverjanjem, ki dokaže, da je vloga, ki si jo pravkar dodal, res izolirana.

Izberi lastnika naslova pred vrati

Končna točka tunela in spletni strežnik si lahko delita jedro; hkratna delitev enega naslova, vrat in protokola je tisto, kar spodleti. WireGuard običajno vzame UDP 51820, OpenVPN vzame UDP 1194 ali TCP 443, spletni strežnik pa TCP 443. Boleč par je OpenVPN prek TCP 443 ob HTTPS, ker oba hočeta isto vtičnico in jedro jo da tistemu, ki se je prvi vezal. Samo demultiplekser spredaj, kot je sslh ali proxy, ki pozna TLS, jima dovoli deliti ta vrata, in doda komponento, katere okvara izgleda natanko kot težava z požarnim zidom.

Poglej lastnike, preden karkoli spremeniš: ss -lntup izpiše lokalni naslov, vrata in proces vsake poslušajoče vtičnice. Dve vrstici z 0.0.0.0:443 pomenita, da se druga storitev ni nikoli vezala, ne glede na to, kako vesela je bila njena init skripta. Premostitev premakne tudi lastnika. Ko se eth0 pridruži br0, se IP premakne na br0 in vsako pravilo požarnega zidu, ki imenuje eth0, se preneha ujemati, zato veži storitve na mostu in potrdi z ip -br addr.

Isto pravilo lastništva pojasni presenečenje, ki se pojavi z virtualnimi stroji. Strežnik tunela, ki teče znotraj gosta v istem omrežju LAN, obdrži gostov naslov, zato povezave, usmerjene na naslov samega gostitelja, ostanejo na gostitelju in tunel gosta jih nikoli ne vidi, kar koli že trdi profil odjemalca.

Usmerjaj med dvema omrežjema LAN ali naredi NAT na eni strani

Dve omrežji LAN, ki se ne vidita, lahko vsako pokliče javnega gostitelja, ki nato posreduje med tuneli. Ta usmerjena zasnova potrebuje tri stvari: vklopljeno posredovanje, pot do vsakega oddaljenega predpone in politiko posredovanja, ki spusti tranzit skozi. sysctl -w net.ipv4.ip_forward=1 pokriva prvo, ip route add 10.20.0.0/24 dev wg1 drugo, in vrstica nftables, kot je nft add rule inet filter forward iifname "wg0" oifname "wg1" accept tretjo.

Izvorni NAT je lažje dodati in težje razhroščevati. Maskiranje prepiše naslov odjemalca, zato oddaljena stran vidi koncentrator namesto pravega gostitelja, njegova pravila dostopa in dnevniki pa niso več uporabni za pripis. Ko sta obe omrežji tvoji, usmerjaj. Ko ena stran pripada tretji osebi, ki ne bo dodala povratne poti, je NAT možnost, ki gre ta teden ven. V vsakem primeru zapiši načrt naslovov, ker dveh prekrivajočih se /24 ne more usmerjati nobena konfiguracija.

Nič v tem, da škatla služi kot internetni izhod za prenosnik, ne preprečuje isti škatli zaključevanja dohodnih tunelov. Preprečujejo to le prekrivajoči se naslovi, zato je načrt naslovov dokument, ki šteje.

Preizkusi delitev, ko sta dve vlogi ustavljeni

Koristen preizkus je odštevanje: ustavi dve vlogi in potrdi, da tretja še vedno odgovarja. Spletna zahteva se mora dokončati z izklopljeno storitvijo tunela, rokovanje tunela pa se mora dokončati z ustavljenim spletnim strežnikom. Če oboje deluje le, ko vse teče, imaš naključno odvisnost, na primer skupno tabelo požarnega zidu, zablodelo pot ali ime, ki kaže na napačen naslov.

Trije ukazi naredijo ta preizkus konkreten. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ dokaže, da lokalni poslušalec odgovarja brez zunanjega DNS, wg show na odjemalcu dokaže, da je rokovanje končano, in tcpdump -ni any port 51820 na koncentratorju loči težavo usmerjanja od težave s ključem. Rokovanje, ki se v zajemu nikoli ne pojavi, je umrlo pred gostiteljem: požarni zid ponudnika, napačen javni naslov ali pravilo NAT na poti.

Ponovi odštevanje za posredovana omrežja LAN. Z enim odklopljenim partnerjem mora ping čez koncentrator spodleteti; ob ponovni povezavi se mora ping obnoviti brez dotika pravila. Ping, ki se obnovi šele po ponovnem zagonu tunela, kaže na politiko in ne na dosegljivost, to pa je druga poprava.

Ohrani nabor pravil berljiv, medtem ko odštevaš vloge. nft list ruleset naj bi kazal eno pravilo dovoljenja na vsako smer, ki jo res potrebuješ, in veriga posredovanja, ki dovoli vse, ni ločevanje, je delujoča predstavitev.

Dostopne linije samo IPv6 in storitve IPv4

Nekatere dostopne linije dajo samo dosegljivost IPv6, storitve pa je treba še vedno objaviti prek IPv4. Sam tunel potuje po družini, ki še spušča promet skozi, medtem ko objavljena storitev sedi na naslovu znotraj tunela. To obrne običajno predpostavko in tiho pokvari nadzor: pravilo požarnega zidu ali preverjanje razpoložljivosti, napisano za pot IPv4, zdaj opazuje vmesnik, ki ne nosi ničesar.

Preizkusi vsako družino posebej z curl -4 in curl -6, ker ena uspešna zahteva ne pove ničesar o poti, ki je nisi preizkusil. Lastništvo vrat se med družinami ne spremeni, poslušalec pa: ss -lntup navaja vtičnice IPv4 in IPv6 v ločenih vrsticah, in 0.0.0.0:443 ne pokriva [::]:443, razen če je proces zahteval vtičnico dual-stack.

Storitev, ki odgovarja na eni družini in zavrača na drugi, je običajno težava poslušalca, ne usmerjanja. Preden zasnovo razglasiš za končano, potrdi, da ima vsaka vloga svoj naslov ali vrata, da je posredovanje vklopljeno in dovoljeno, in da vsaka vloga še vedno odgovarja, ko sta drugi dve ustavljeni.