Jedan javni host za VPN i web: kako podijeliti uloge

Jedan stroj može odgovoriti na sve tri potrebe odjednom: završavati tunele, odgovarati na HTTPS i prosljeđivati između dva privatna LAN-a. Je li to razumno svodi se na tri stvari koje možete riješiti na papiru: kome pripada javna adresa, kome pripada svaki par porta i protokola i kojem je procesu dopušteno prosljeđivati pakete. Ako to pogodite, zajednički host nije ništa posebno. Ako pogriješite, provest ćete vikend na usluzi koja se čisto pokreće i nikada ne odgovara.

Ono što slijedi je postupak odlučivanja, a ne list za gradnju. Svaki korak završava provjerom koja dokazuje da je uloga koju ste upravo dodali doista izolirana.

Odaberite vlasnika adrese prije portova

Krajnja točka tunela i web poslužitelj mogu dijeliti jezgru; dijeljenje jedne adrese, porta i protokola istodobno je ono što pada. WireGuard obično uzima UDP 51820, OpenVPN uzima UDP 1194 ili TCP 443, a web poslužitelj uzima TCP 443. Par koji boli je OpenVPN preko TCP 443 pokraj HTTPS-a, jer oba žele istu utičnicu i jezgra je daje onome koji se prvi vezao. Samo demultiplekser ispred, poput sslh ili proxyja koji poznaje TLS, dopušta im da dijele taj port, i on dodaje komponentu čiji kvar izgleda točno kao problem vatrozida.

Pogledajte vlasnike prije nego što bilo što promijenite: ss -lntup ispisuje lokalnu adresu, port i proces svake utičnice koja sluša. Dva retka koja pokazuju 0.0.0.0:443 znače da se druga usluga nikada nije vezala, koliko god njezina init skripta bila vesela. Premošćivanje također pomiče vlasnika. Kada se eth0 pridruži br0, IP prelazi na br0 i svako pravilo vatrozida koje imenuje eth0 prestaje se podudarati, pa vežite usluge na mostu i potvrdite s ip -br addr.

Isto pravilo vlasništva objašnjava iznenađenje koje se pojavljuje s virtualnim strojevima. Poslužitelj tunela koji radi unutar gosta na istom LAN-u zadržava adresu gosta, pa veze usmjerene na adresu samog hosta ostaju na hostu i tunel gosta ih nikada ne vidi, što god klijentski profil tvrdio.

Usmjeravajte između dva LAN-a ili NAT-ajte jednu stranu

Dva LAN-a koji se ne vide mogu svaki birati javni host, koji zatim prosljeđuje između tunela. Taj usmjereni dizajn treba tri stvari: uključeno prosljeđivanje, rutu prema svakom udaljenom prefiksu i politiku prosljeđivanja koja propušta tranzit. sysctl -w net.ipv4.ip_forward=1 pokriva prvu, ip route add 10.20.0.0/24 dev wg1 drugu, a nftables redak poput nft add rule inet filter forward iifname "wg0" oifname "wg1" accept treću.

Izvorni NAT lakše je dodati i teže otkloniti. Maskiranje prepisuje adresu klijenta, pa udaljena strana vidi čvorište umjesto pravog hosta, a njegova pravila pristupa i zapisi prestaju biti korisni za atribuciju. Kada su obje mreže vaše, usmjeravajte. Kada jedna strana pripada trećoj strani koja neće dodati povratnu rutu, NAT je opcija koja isporučuje ovaj tjedan. U svakom slučaju, zapišite plan adresa, jer se dvije preklapajuće /24 ne mogu usmjeriti nikakvom količinom konfiguracije.

Ništa u tome što kutija služi kao internetski izlaz za prijenosno računalo ne sprječava istu kutiju da završava dolazne tunele. Sprječavaju samo preklapajuće adrese, i zato je plan adresa dokument koji je važan.

Testirajte podjelu dok su dvije uloge zaustavljene

Koristan test je oduzimanje: zaustavite dvije uloge i potvrdite da treća još odgovara. Web zahtjev treba se dovršiti dok je usluga tunela isključena, a rukovanje tunela treba se dovršiti dok je web poslužitelj zaustavljen. Ako oboje rade samo kad sve radi, imate slučajnu ovisnost, poput zajedničke tablice vatrozida, zalutale rute ili imena koje pokazuje na pogrešnu adresu.

Tri naredbe čine taj test konkretnim. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ dokazuje da lokalni slušatelj odgovara bez vanjskog DNS-a, wg show na klijentu dokazuje da je rukovanje dovršeno, a tcpdump -ni any port 51820 na čvorištu razdvaja problem usmjeravanja od problema ključa. Rukovanje koje se nikad ne pojavi u snimci umrlo je prije hosta: vatrozid pružatelja, pogrešna javna adresa ili NAT pravilo na putu.

Ponovite oduzimanje za proslijeđene LAN-ove. S jednim partnerom isključenim, ping preko čvorišta treba pasti; kad se ponovno spoji, ping se treba vratiti bez diranja pravila. Ping koji se vraća tek nakon ponovnog pokretanja tunela pokazuje na politiku, a ne na dosežnost, što je drugačiji popravak.

Držite skup pravila čitljivim dok oduzimate uloge. nft list ruleset treba pokazati jedno pravilo prihvaćanja po smjeru koji doista trebate, a lanac prosljeđivanja koji prihvaća sve nije razdvajanje, to je radni demo.

Pristupni vodovi samo s IPv6 i usluge na IPv4

Neki pristupni vodovi daju samo IPv6 dosežnost, a usluge se ipak moraju objaviti preko IPv4. Sam tunel putuje obitelji koja još propušta promet, dok objavljena usluga sjedi na adresi unutar tunela. To preokreće uobičajenu pretpostavku i tiho kvari nadzor: pravilo vatrozida ili provjera radnog vremena napisana za IPv4 put sada nadzire sučelje koje ništa ne nosi.

Testirajte svaku obitelj zasebno s curl -4 i curl -6, jer jedan uspješan zahtjev ne govori ništa o putu koji niste isprobali. Vlasništvo nad portom ne mijenja se među obiteljima, ali slušatelj se mijenja: ss -lntup navodi IPv4 i IPv6 utičnice u odvojenim recima, a 0.0.0.0:443 ne pokriva [::]:443 osim ako proces nije zatražio dual-stack utičnicu.

Usluga koja odgovara na jednoj obitelji i odbija na drugoj obično je problem slušatelja, a ne usmjeravanja. Prije nego što dizajn proglasite gotovim, potvrdite da svaka uloga posjeduje vlastitu adresu ili port, da je prosljeđivanje uključeno i dopušteno, i da svaka uloga još odgovara dok su druge dvije zaustavljene.