Én offentlig vert for VPN og nett: hvordan dele rollene

Én maskin kan dekke alle tre behovene samtidig: avslutte tunneler, svare på HTTPS og videresende mellom to private nett. Om det er fornuftig avhenger av tre ting du kan avgjøre på papiret: hvem som eier den offentlige adressen, hvem som eier hvert port- og protokollpar, og hvilken prosess som har lov til å videresende pakker. Får du disse riktig, er den delte verten ikke noe spesielt. Får du dem galt, bruker du en helg på en tjeneste som starter rent og aldri svarer.

Det som følger er en beslutningsprosedyre, ikke et byggeark. Hvert steg avsluttes med kontrollen som beviser at rollen du nettopp la til faktisk er isolert.

Velg eieren av adressen før portene

Et tunnelendepunkt og en nettserver kan dele en kjerne; å dele én adresse, port og protokoll samtidig er det som feiler. WireGuard tar vanligvis UDP 51820, OpenVPN tar UDP 1194 eller TCP 443, og en nettserver tar TCP 443. Paret som svir er OpenVPN over TCP 443 ved siden av HTTPS, fordi begge vil ha samme socket og kjernen gir den til den som bandt seg først. Bare en demultiplekser foran, som sslh eller en TLS-bevisst proxy, lar dem dele den porten, og den legger til en komponent der feilen ser nøyaktig ut som et brannmurproblem.

Se på eierne før du endrer noe: ss -lntup skriver ut lokal adresse, port og prosess for hver lyttende socket. To rader som viser 0.0.0.0:443 betyr at den andre tjenesten aldri bandt seg, uansett hvor blid init-skriptet var. Broing flytter også eieren. Når eth0 blir med i br0, flyttes IP-en til br0 og hver brannmurregel som nevner eth0 slutter å stemme, så bind tjenestene på broen og bekreft med ip -br addr.

Den samme eierregelen forklarer en overraskelse som dukker opp med virtuelle maskiner. En tunnelserver som kjører inne i en gjest på samme nett beholder gjestens adresse, så tilkoblinger rettet mot vertens egen adresse blir værende på verten og gjestens tunnel ser dem aldri, uansett hva klientprofilen sier.

Rut mellom de to nettene eller NAT én side

To nett som ikke ser hverandre kan hver ringe den offentlige verten, som deretter videresender mellom tunnelene. Det rutede designet trenger tre ting på plass: videresending slått på, en rute mot hvert eksterne prefiks og en videresendingspolicy som slipper transitten gjennom. sysctl -w net.ipv4.ip_forward=1 dekker det første, ip route add 10.20.0.0/24 dev wg1 det andre, og en nftables-linje som nft add rule inet filter forward iifname "wg0" oifname "wg1" accept det tredje.

Kilde-NAT er lettere å legge til og vanskeligere å feilsøke. Maskering skriver om klientadressen, så den fjerne siden ser huben i stedet for den egentlige verten, og tilgangsreglene og loggene slutter å være nyttige for attribusjon. Når begge nettene er dine, rut. Når én side tilhører en tredjepart som ikke legger til en returrute, er NAT alternativet som sendes denne uken. Uansett, skriv ned adresseplanen, fordi to overlappende /24 ikke kan rutes av noen mengde konfigurasjon.

Ingenting ved å være internettutgang for en bærbar PC hindrer den samme boksen i å avslutte innkommende tunneler. Bare overlappende adresser gjør det, og derfor er adresseplanen dokumentet som betyr noe.

Test delingen mens to roller er stoppet

Den nyttige testen er subtraksjon: stopp to roller og bekreft at den tredje fortsatt svarer. En nettforespørsel bør fullføres med tunneltjenesten nede, og et tunnelhåndtrykk bør fullføres med nettserveren stoppet. Hvis begge bare virker når alt kjører, har du en tilfeldig avhengighet, som en delt brannmurtabell, en vill rute eller et navn som peker på feil adresse.

Tre kommandoer gjør den testen konkret. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ beviser at den lokale lytteren svarer uten ekstern DNS, wg show på klienten beviser at håndtrykket er fullført, og tcpdump -ni any port 51820 på huben skiller et rutingsproblem fra et nøkkelproblem. Et håndtrykk som aldri dukker opp i opptaket døde før verten: leverandørens brannmur, feil offentlig adresse eller en NAT-regel underveis.

Gjenta subtraksjonen for nettene som videresendes. Med én peer frakoblet skal en ping over huben feile; når den er tilkoblet igjen, skal pinget komme tilbake uten å røre en regel. Et ping som bare kommer tilbake etter omstart av tunnelen peker på policy og ikke på tilgjengelighet, og det er en annen retting.

Hold regelsettet lesbart mens du trekker fra roller. nft list ruleset bør vise én tillatelsesregel per retning du faktisk trenger, og en videresendingskjede som tillater alt er ikke separasjon, det er en fungerende demo.

Bare IPv6-tilgangslinjer og IPv4-tjenester

Noen tilgangslinjer gir bare IPv6-tilgjengelighet, og tjenester må fortsatt publiseres over IPv4. Selve tunnelen går over familien som fortsatt slipper trafikk gjennom, mens den publiserte tjenesten sitter på en adresse inne i tunnelen. Det snur den vanlige antakelsen og bryter overvåkingen stille: en brannmurregel eller oppetidskontroll skrevet for IPv4-veien overvåker nå et grensesnitt som ikke bærer noe.

Test hver familie for seg med curl -4 og curl -6, fordi én vellykket forespørsel ikke sier noe om veien du ikke prøvde. Porteierskap endres ikke mellom familier, men lytteren gjør det: ss -lntup lister IPv4- og IPv6-sokler på separate rader, og 0.0.0.0:443 dekker ikke [::]:443 med mindre prosessen ba om en dual-stack-socket.

En tjeneste som svarer på én familie og nekter på den andre er vanligvis et lytterproblem, ikke et rutingsproblem. Før du kaller designet ferdig, bekreft at hver rolle eier sin egen adresse eller port, at videresending er slått på og tillatt, og at hver rolle fortsatt svarer med de to andre stoppet.