Jeden verejný host pre VPN a web: ako rozdeliť roly

Jeden stroj môže uspokojiť všetky tri potreby naraz: ukončovať tunely, odpovedať na HTTPS a preposielať medzi dvoma privátnymi sieťami LAN. Či je to rozumné, sa zužuje na tri veci, ktoré sa dajú vyriešiť na papieri: komu patrí verejná adresa, komu patrí každá dvojica portu a protokolu a ktorému procesu je dovolené preposielať pakety. Ak to trafíte, zdieľaný host nie je nič zvláštne. Ak nie, strávite víkend so službou, ktorá sa čisto spustí a nikdy neodpovie.

To, čo nasleduje, je rozhodovacia procedúra, nie stavebný list. Každý krok sa končí kontrolou, ktorá dokazuje, že rola, ktorú ste práve pridali, je skutočne izolovaná.

Vyberte vlastníka adresy pred portami

Koncový bod tunela a webový server môžu zdieľať jedno jadro; zdieľanie jednej adresy, portu a protokolu súčasne je to, čo zlyháva. WireGuard zvyčajne zaberá UDP 51820, OpenVPN zaberá UDP 1194 alebo TCP 443 a webový server zaberá TCP 443. Bolestivá dvojica je OpenVPN cez TCP 443 vedľa HTTPS, pretože obe chcú ten istý socket a jadro ho dá tomu, kto sa pripútal prvý. Iba demultiplexor vpredu, ako sslh alebo proxy, ktorý rozumie TLS, im dovolí zdieľať ten port, a pridáva komponent, ktorého porucha vyzerá presne ako problém brány firewall.

Pozrite sa na vlastníkov, kým čokoľvek zmeníte: ss -lntup vypíše lokálnu adresu, port a proces každého počúvajúceho socketu. Dva riadky s 0.0.0.0:443 znamenajú, že druhá služba sa nikdy nepripútala, akokoľvek veselý bol jej init skript. Premostenie tiež presúva vlastníka. Keď sa eth0 pripojí k br0, IP prechádza na br0 a každé pravidlo brány firewall, ktoré menuje eth0, prestane sedieť, preto pripnite služby na moste a potvrďte pomocou ip -br addr.

To isté pravidlo vlastníctva vysvetľuje prekvapenie, ktoré sa objavuje s virtuálnymi strojmi. Server tunela, ktorý beží v hosťovi v tej istej sieti LAN, si zachováva adresu hosťa, takže pripojenia smerované na adresu samotného hostiteľa zostávajú na hostiteľovi a tunel hosťa ich nikdy nevidí, nech už profil klienta tvrdí čokoľvek.

Smerujte medzi dvoma sieťami LAN alebo spravte NAT na jednej strane

Dve siete LAN, ktoré sa navzájom nevidia, môžu každá zavolať verejného hostiteľa, ktorý potom preposiela medzi tunelmi. Takýto smerovaný návrh potrebuje tri veci: zapnuté preposielanie, trasu ku každému vzdialenému prefixu a politiku preposielania, ktorá prepustí tranzit. sysctl -w net.ipv4.ip_forward=1 pokrýva prvú, ip route add 10.20.0.0/24 dev wg1 druhú, a riadok nftables ako nft add rule inet filter forward iifname "wg0" oifname "wg1" accept tretiu.

Zdrojový NAT sa pridáva ľahšie a ladí ťažšie. Maskovanie prepisuje adresu klienta, takže vzdialená strana vidí koncentrátor namiesto skutočného hostiteľa, a jej pravidlá prístupu a záznamy prestanú byť užitočné pre atribúciu. Keď sú obe siete vaše, smerujte. Keď jedna strana patrí tretej strane, ktorá nepridá návratovú trasu, NAT je možnosť, ktorá vyjde tento týždeň. V každom prípade zapíšte plán adries, pretože dve prekrývajúce sa /24 nemožno smerovať žiadnou konfiguráciou.

Nič na tom, že skrinka slúži ako internetový východ pre notebook, nebráni tej istej skrinke ukončovať prichádzajúce tunely. Bránia tomu iba prekrývajúce sa adresy, a preto je plán adries dokumentom, na ktorom záleží.

Otestujte rozdelenie, kým sú dve roly zastavené

Užitočný test je odčítanie: zastavte dve roly a potvrďte, že tretia stále odpovedá. Webová požiadavka sa musí dokončiť s vypnutou službou tunela a prebiehajúca výmena tunela sa musí dokončiť so zastaveným webovým serverom. Ak obe fungujú len vtedy, keď všetko beží, máte náhodnú závislosť, napríklad zdieľanú tabuľku brány firewall, zatúlanú trasu alebo meno ukazujúce na zlú adresu.

Tri príkazy robia ten test konkrétnym. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ dokazuje, že lokálny poslucháč odpovedá bez externého DNS, wg show na klientovi dokazuje, že výmena sa dokončila, a tcpdump -ni any port 51820 na koncentrátore oddeľuje problém smerovania od problému kľúča. Výmena, ktorá sa v zázname nikdy neobjaví, zomrela pred hostiteľom: brána firewall poskytovateľa, nesprávna verejná adresa alebo pravidlo NAT na ceste.

Zopakujte odčítanie pre preposielané siete LAN. S jedným partnerom odpojeným má ping cez koncentrátor zlyhať; po opätovnom pripojení sa má ping obnoviť bez dotyku pravidla. Ping, ktorý sa obnoví až po reštarte tunela, ukazuje na politiku, nie na dostupnosť, a to je iná oprava.

Udržujte sadu pravidiel čitateľnú, kým odčítate roly. nft list ruleset má zobrazovať jedno povoľovacie pravidlo pre každý smer, ktorý skutočne potrebujete, a reťaz preposielania, ktorá povoľuje všetko, nie je oddelenie, je to fungujúca ukážka.

Prístupové linky len IPv6 a služby IPv4

Niektoré prístupové linky dávajú len dosiahnuteľnosť IPv6 a služby sa stále musia publikovať cez IPv4. Samotný tunel ide cez rodinu, ktorá ešte prepúšťa prevádzku, kým publikovaná služba sedí na adrese vnútri tunela. To obracia obvyklý predpoklad a potichu kazí monitorovanie: pravidlo brány firewall alebo kontrola dostupnosti napísaná pre cestu IPv4 teraz sleduje rozhranie, ktoré nič nenesie.

Testujte každú rodinu zvlášť pomocou curl -4 a curl -6, pretože jedna úspešná požiadavka nič nehovorí o ceste, ktorú ste neskúsili. Vlastníctvo portov sa medzi rodinami nemení, ale poslucháč áno: ss -lntup uvádza sockety IPv4 a IPv6 v samostatných riadkoch a 0.0.0.0:443 nepokrýva [::]:443, ak proces nepožiadal o dual-stack socket.

Služba, ktorá odpovedá na jednej rodine a odmieta na druhej, je zvyčajne problém poslucháča, nie smerovania. Predtým, než návrh vyhlásite za hotový, potvrďte, že každá rola má vlastnú adresu alebo port, že preposielanie je zapnuté a povolené a že každá rola stále odpovedá, keď sú ostatné dve zastavené.