Eén publieke host voor VPN en web: hoe je de rollen verdeelt

Eén machine kan alle drie de behoeften tegelijk vervullen: tunnels beëindigen, HTTPS beantwoorden en tussen twee privé-LAN's doorsturen. Of dat verstandig is, komt neer op drie dingen die je op papier kunt regelen: wie het publieke adres bezit, wie elk paar van poort en protocol bezit, en welk proces pakketten mag doorsturen. Krijg je die goed, dan is de gedeelde host niets bijzonders. Krijg je ze fout, dan verspil je een weekend aan een dienst die netjes start en nooit antwoordt.

Wat volgt is een beslissingsprocedure, geen bouwtekening. Elke stap eindigt met de controle die bewijst dat de rol die je zojuist toevoegde echt geïsoleerd is.

Kies de eigenaar van het adres vóór de poorten

Een tunnel-eindpunt en een webserver kunnen een kernel delen; één adres, poort en protocol tegelijk delen is wat mislukt. WireGuard neemt meestal UDP 51820, OpenVPN neemt UDP 1194 of TCP 443, en een webserver neemt TCP 443. Het pijnlijke paar is OpenVPN over TCP 443 naast HTTPS, omdat beide dezelfde socket willen en de kernel hem geeft aan wie zich het eerst bond. Alleen een demultiplexer ervoor, zoals sslh of een TLS-bewuste proxy, laat ze die poort delen, en hij voegt een component toe waarvan de storing er precies als een firewallprobleem uitziet.

Kijk naar de eigenaars voordat je iets verandert: ss -lntup drukt het lokale adres, de poort en het proces van elke luisterende socket af. Twee regels met 0.0.0.0:443 betekenen dat de tweede dienst zich nooit bond, hoe vrolijk het init-script ook was. Bridging verplaatst ook de eigenaar. Wanneer eth0 zich bij br0 voegt, verhuist het IP naar br0 en elke firewallregel die eth0 noemt, komt niet meer overeen, dus bind diensten op de bridge en bevestig met ip -br addr.

Dezelfde eigendomsregel verklaart een verrassing die bij virtuele machines opduikt. Een tunnelserver die in een gast op hetzelfde LAN draait, houdt het adres van de gast, dus verbindingen naar het adres van de host zelf blijven op de host en de tunnel van de gast ziet ze nooit, wat het clientprofiel ook beweert.

Routeer tussen de twee LAN's of NAT één kant

Twee LAN's die elkaar niet zien, kunnen elk de publieke host bellen, die dan tussen de tunnels doorstuurt. Dat gerouteerde ontwerp vereist drie dingen: doorsturen aan, een route naar elk extern prefix en een doorstuurbeleid dat het transitverkeer doorlaat. sysctl -w net.ipv4.ip_forward=1 dekt het eerste, ip route add 10.20.0.0/24 dev wg1 het tweede, en een nftables-regel zoals nft add rule inet filter forward iifname "wg0" oifname "wg1" accept het derde.

Bron-NAT is makkelijker toe te voegen en moeilijker te debuggen. Masquerading herschrijft het adres van de client, dus de verre kant ziet de hub in plaats van de echte host, en de toegangsregels en logs zijn niet meer bruikbaar voor attributie. Als beide netwerken van jou zijn, routeer. Als één kant van een derde partij is die geen retourroute toevoegt, is NAT de optie die deze week uitgaat. Schrijf hoe dan ook het adresplan op, want twee overlappende /24's zijn met geen enkele configuratie te routeren.

Niets aan het dienen als internetuitgang voor een laptop verhindert dat dezelfde doos inkomende tunnels beëindigt. Alleen overlappende adressen doen dat, en daarom is het adresplan het document dat ertoe doet.

Test de splitsing terwijl twee rollen gestopt zijn

De nuttige test is aftrekken: stop twee rollen en bevestig dat de derde nog antwoordt. Een webverzoek moet slagen terwijl de tunneldienst uit staat, en een tunnelhandshake moet slagen terwijl de webserver gestopt is. Als beide alleen werken wanneer alles draait, heb je een toevallige afhankelijkheid, zoals een gedeelde firewaltabel, een verdwaalde route of een naam die naar het verkeerde adres wijst.

Drie commando's maken die test concreet. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ bewijst dat de lokale luisteraar antwoordt zonder externe DNS, wg show op de client bewijst dat de handshake is voltooid, en tcpdump -ni any port 51820 op de hub scheidt een routeringsprobleem van een sleutelprobleem. Een handshake die nooit in de capture verschijnt, stierf vóór de host: firewall van de provider, verkeerd publiek adres of een NAT-regel onderweg.

Herhaal het aftrekken voor de doorgestuurde LAN's. Met één peer losgekoppeld hoort een ping over de hub te mislukken; weer verbonden hoort de ping te herstellen zonder een regel aan te raken. Een ping die pas terugkomt na een herstart van de tunnel wijst op beleid en niet op bereikbaarheid, en dat is een andere oplossing.

Houd de regelset leesbaar terwijl je rollen aftrekt. nft list ruleset hoort één acceptatieregel per richting te tonen die je echt nodig hebt, en een doorstuurketen die alles accepteert is geen scheiding, het is een werkende demo.

Alleen IPv6-toegangslijnen en IPv4-diensten

Sommige toegangslijnen geven alleen IPv6-bereikbaarheid, en diensten moeten nog steeds via IPv4 worden gepubliceerd. De tunnel zelf reist over de familie die nog verkeer doorlaat, terwijl de gepubliceerde dienst op een adres binnen de tunnel zit. Dat keert de gebruikelijke aanname om en breekt de monitoring stil: een firewallregel of uptime-controle die voor het IPv4-pad is geschreven, bewaakt nu een interface die niets draagt.

Test elke familie apart met curl -4 en curl -6, want één geslaagd verzoek zegt niets over het pad dat je niet hebt geprobeerd. Poorteigendom verandert niet tussen families, maar de luisteraar wel: ss -lntup vermeldt IPv4- en IPv6-sockets op aparte regels, en 0.0.0.0:443 dekt [::]:443 niet, tenzij het proces een dual-stack-socket vroeg.

Een dienst die op de ene familie antwoordt en op de andere weigert, is meestal een luisteraarprobleem, geen routeringsprobleem. Voordat je het ontwerp klaar noemt, bevestig je dat elke rol zijn eigen adres of poort bezit, dat doorsturen aan staat en is toegestaan, en dat elke rol nog antwoordt terwijl de andere twee gestopt zijn.