Jeden veřejný host pro VPN i web: jak oddělit role

Jeden stroj může splnit všechny tři potřeby najednou: ukončovat tunely, odpovídat na HTTPS a předávat mezi dvěma privátními sítěmi LAN. Zda je to rozumné, závisí na třech věcech, které lze rozhodnout na papíře: kdo vlastní veřejnou adresu, kdo vlastní každou dvojici port a protokol a kterému procesu je dovoleno předávat pakety. Udělejte to správně a sdílený host není ničím zvláštní. Udělejte to špatně a strávíte víkend u služby, která se čistě spustí a nikdy neodpoví.

Následuje rozhodovací postup, ne stavební návod. Každý krok končí kontrolou, která dokazuje, že role, kterou jste právě přidali, je skutečně izolovaná.

Vyberte vlastníka adresy dříve než porty

Koncový bod tunelu a webový server mohou sdílet jedno jádro; sdílení jedné adresy, portu a protokolu současně je to, co selhává. WireGuard obvykle zabírá UDP 51820, OpenVPN zabírá UDP 1194 nebo TCP 443 a webový server zabírá TCP 443. Bolestivá dvojice je OpenVPN přes TCP 443 vedle HTTPS, protože obě chtějí stejný socket a jádro ho předá tomu, kdo se připojil první. Sdílet tento port jim dovolí jen demultiplexor vpředu, jako je sslh nebo proxy s podporou TLS, a ten přidává komponentu, jejíž porucha vypadá přesně jako problém firewallu.

Podívejte se na vlastníky, než cokoli změníte: ss -lntup vypisuje místní adresu, port a proces pro každý naslouchající socket. Dva řádky s 0.0.0.0:443 znamenají, že druhá služba se nikdy nepřipojila, ať byl její init skript jakkoli veselý. Bridge také přesouvá vlastníka. Když se eth0 připojí k br0, IP se přesune na br0 a každé pravidlo firewallu, které zmiňuje eth0 přestane odpovídat, takže služby navázejte na bridge a potvrďte to pomocí ip -br addr.

Stejné pravidlo vlastnictví vysvětluje překvapení, které se objevuje u virtuálních strojů. Server tunelu, který běží uvnitř hosta ve stejné LAN, si zachovává adresu hosta, takže spojení mířící na vlastní adresu hostitele zůstávají na hostiteli a tunel hosta je nikdy nevidí, ať klientský profil naznačuje cokoli.

Směrujte mezi dvěma sítěmi LAN, nebo jednu stranu přeložte přes NAT

Dvě sítě LAN, které na sebe nevidí, mohou každá vytáčet veřejný host, který pak předává mezi tunely. Tento směrovaný návrh potřebuje tři věci: zapnuté předávání, trasu ke každému vzdálenému prefixu a politiku předávání, která propustí tranzit. sysctl -w net.ipv4.ip_forward=1 pokrývá první, ip route add 10.20.0.0/24 dev wg1 druhé, a řádek nftables jako nft add rule inet filter forward iifname "wg0" oifname "wg1" accept třetí.

Zdrojový NAT se snadno přidává a těžko ladí. Maskarádování přepisuje adresu klienta, takže vzdálená strana vidí hub místo skutečného hostitele a její přístupová pravidla a logy přestávají být užitečné pro přiřazení. Když jsou obě sítě vaše, směrujte. Když jedna strana patří třetí straně, která nepřidá zpětnou trasu, je NAT možnost, kterou lze doručit tento týden. V každém případě si zapište plán adres, protože dvě překrývající se /24 nelze směrovat žádným množstvím konfigurace.

Nic na tom, že pro notebook fungujete jako internetový výstup, nebrání stejné krabici ukončovat příchozí tunely. Brání tomu jen překrývající se adresy, a proto je plán adres dokument, na kterém záleží.

Otestujte oddělení, zatímco jsou dvě role zastavené

Užitečný test je odečítání: zastavte dvě role a potvrďte, že třetí stále odpovídá. Webový požadavek by měl proběhnout se zastavenou službou tunelu a handshake tunelu by měl proběhnout se zastaveným webovým serverem. Pokud obojí funguje jen tehdy, když běží všechno, máte náhodnou závislost: sdílenou tabulku firewallu, zbloudilou trasu nebo jméno ukazující na špatnou adresu.

Tři příkazy ten test zkonkrétní. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ dokazuje, že místní posluchač odpovídá bez externího DNS, wg show na klientovi dokazuje, že handshake proběhl, a tcpdump -ni any port 51820 na hubu odděluje problém směrování od problému s klíčem. Handshake, který se v záznamu nikdy neobjeví, zemřel před hostitelem: firewall poskytovatele, špatná veřejná adresa nebo pravidlo NAT na cestě.

Zopakujte odečítání pro předávané sítě LAN. S jedním odpojeným protějškem by ping přes hub měl selhat; po opětovném připojení by se ping měl obnovit, aniž byste se dotkli pravidla. Ping, který se obnoví jen po restartu tunelu, ukazuje na politiku, ne na dosažitelnost, a to je jiná oprava.

Udržujte sadu pravidel čitelnou, zatímco odečítáte role. nft list ruleset by měl ukázat jedno pravidlo přijetí na směr, který skutečně potřebujete, a forward řetězec, který přijímá vše, není oddělení, ale fungující demo.

Přístupové linky pouze s IPv6 a služby IPv4

Některé přístupové linky dávají dosažitelnost jen přes IPv6 a služby se stále musí publikovat přes IPv4. Tunel sám cestuje po rodině, která ještě propouští provoz, zatímco publikovaná služba sedí na adrese uvnitř tunelu. To obrací obvyklý předpoklad a tiše rozbíjí monitoring: pravidlo firewallu nebo kontrola dostupnosti napsaná pro cestu IPv4 nyní sleduje rozhraní, které nic nenese.

Otestujte každou rodinu zvlášť pomocí curl -4 a curl -6, protože jeden úspěšný požadavek nic neříká o cestě, kterou jste nezkusili. Vlastnictví portu se mezi rodinami nemění, ale posluchač ano: ss -lntup vypisuje sockety IPv4 a IPv6 jako samostatné řádky a 0.0.0.0:443 nepokrývá [::]:443, pokud proces nepožádal o dual-stack socket.

Služba, která odpovídá na jedné rodině a odmítá na druhé, je obvykle problém posluchače, ne směrování. Než návrh prohlásíte za hotový, potvrďte, že každá role vlastní svou adresu nebo port, že předávání je zapnuté a povolené a že každá role stále odpovídá, když jsou druhé dvě zastavené.