Jedan javni host za VPN i web: kako razdvojiti uloge

Jedan stroj može odgovoriti na sve tri potrebe odjednom: zaključivati tunele, odgovarati na HTTPS i prosljeđivati između dvije privatne LAN mreže. Da li je to razumno zavisi od tri stvari koje možete riješiti na papiru: ko posjeduje javnu adresu, ko posjeduje svaki par port-protokol i kojem procesu je dopušteno prosljeđivati pakete. Ako to uradite kako treba, zajednički host nije ništa neobično. Ako pogriješite, potrošit ćete vikend na uslugu koja se čisto pokreće i nikada ne odgovara.

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

Odaberite vlasnika adrese prije portova

Krajnja točka tunela i web server mogu dijeliti jedno jezgro; dijeljenje iste adrese, porta i protokola u isto vrijeme je ono što pada. WireGuard obično zauzima UDP 51820, OpenVPN zauzima UDP 1194 ili TCP 443, a web server zauzima TCP 443. Bolan par je OpenVPN preko TCP 443 pored HTTPS-a, jer oba žele isti socket i jezgro ga daje onome koji se prvi vezao. Samo demultiplekser sprijeda, poput sslh ili TLS-osviještenog proxyja, dopušta im da dijele taj port, a on dodaje komponentu čiji kvar izgleda tačno kao problem s firewallom.

Pogledajte vlasnike prije nego što bilo šta promijenite: ss -lntup ispisuje lokalnu adresu, port i proces za svaki socket koji sluša. Dva reda sa 0.0.0.0:443 znače da se druga usluga nikada nije vezala, koliko god njen init skript bio veseo. Bridge također pomjera vlasnika. Kada se eth0 pridruži br0, IP se pomjera na br0 i svako firewall pravilo koje spominje eth0 prestaje da se podudara, zato vežite usluge na bridge i potvrdite sa ip -br addr.

Isto pravilo vlasništva objašnjava iznenađenje koje se pojavljuje s virtualnim mašinama. Server tunela koji radi unutar gosta na istoj LAN mreži zadržava adresu gosta, pa veze prema vlastitoj adresi hosta ostaju na hostu i tunel gosta ih nikada ne vidi, šta god klijentski profil sugerisao.

Rutiranje između dvije LAN mreže ili NAT jedne strane

Dvije LAN mreže koje ne vide jedna drugu mogu svaka birati javni host, koji zatim prosljeđuje između tunela. Taj rutirani dizajn zahtijeva 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 prvo, ip route add 10.20.0.0/24 dev wg1 drugo, a nftables linija poput nft add rule inet filter forward iifname "wg0" oifname "wg1" accept treće.

Source NAT je lakše dodati i teže otkloniti greške. Maskiranje prepisuje adresu klijenta, pa dalja strana vidi hub umjesto stvarnog hosta, a njena pravila pristupa i logovi prestaju biti korisni za pripisivanje. Kada su obje mreže vaše, rutirajte. Kada jedna strana pripada trećoj strani koja neće dodati povratnu rutu, NAT je opcija koja se isporučuje ove sedmice. U svakom slučaju zapišite plan adresa, jer dvije preklapajuće /24 ne mogu se rutirati nikakvom količinom konfiguracije.

Ništa u tome što djelujete kao internet izlaz za laptop ne sprječava istu kutiju da zaključuje dolazne tunele. To čine samo adrese koje se preklapaju, zato je plan adresa dokument koji je važan.

Testirajte razdvajanje dok su dvije uloge zaustavljene

Koristan test je oduzimanje: zaustavite dvije uloge i potvrdite da treća još odgovara. Web zahtjev treba da se završi sa isključenom uslugom tunela, a handshake tunela treba da se završi sa zaustavljenim web serverom. Ako oboje radi samo kada sve radi, imate slučajnu zavisnost: zajedničku firewall tabelu, zalutalu rutu ili ime koje pokazuje na pogrešnu adresu.

Tri komande čine taj test konkretnim. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ dokazuje da lokalni slušalac odgovara bez vanjskog DNS-a, wg show na klijentu dokazuje da je handshake završen, a tcpdump -ni any port 51820 na hubu razdvaja problem rutiranja od problema s ključem. Handshake koji se nikada ne pojavi u snimku umro je prije hosta: firewall provajdera, pogrešna javna adresa ili NAT pravilo na putu.

Ponovite oduzimanje za proslijeđene LAN mreže. Sa jednim isključenim peerom ping preko huba treba da padne; kada se ponovo poveže, ping treba da se vrati bez diranja pravila. Ping koji se vraća samo nakon ponovnog pokretanja tunela ukazuje na politiku, a ne na dostupnost, i to je drugačija popravka.

Držite skup pravila čitljivim dok oduzimate uloge. nft list ruleset treba da pokaže jedno accept pravilo po smjeru koji vam stvarno treba, a forward lanac koji prihvata sve nije razdvajanje, to je radna demonstracija.

Pristupne linije samo s IPv6 i IPv4 usluge

Neke pristupne linije daju dostupnost samo preko IPv6, a usluge se ipak moraju objavljivati preko IPv4. Sam tunel putuje preko one porodice koja još propušta saobraćaj, dok objavljena usluga stoji na adresi unutar tunela. To obrće uobičajenu pretpostavku i tiho kvari monitoring: firewall pravilo ili uptime provjera napisana za IPv4 put sada posmatra interfejs koji ništa ne nosi.

Testirajte svaku porodicu zasebno sa curl -4 i curl -6, jer jedan uspješan zahtjev ne govori ništa o putu koji niste probali. Vlasništvo nad portom se ne mijenja između porodica, ali slušalac se mijenja: ss -lntup prikazuje IPv4 i IPv6 sockete kao odvojene redove, a 0.0.0.0:443 ne pokriva [::]:443 osim ako proces nije zatražio dual-stack socket.

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