En enda publik värd för VPN och webb: hur rollerna delas

En enda maskin kan täcka alla tre behoven samtidigt: avsluta tunnlar, svara på HTTPS och vidarebefordra mellan två privata LAN. Om det är förnuftigt beror på tre saker du kan avgöra på papper: vem som äger den publika adressen, vem som äger varje port- och protokollpar och vilken process som får vidarebefordra paket. Får du dessa rätt är den delade värden inget märkvärdigt. Får du dem fel spenderar du en helg på en tjänst som startar rent och aldrig svarar.

Det som följer är en beslutsprocedur, inte ett byggblad. Varje steg avslutas med kontrollen som bevisar att rollen du just lade till verkligen är isolerad.

Välj ägaren av adressen före portarna

En tunneländpunkt och en webbserver kan dela en kärna; att dela en adress, port och protokoll samtidigt är det som fallerar. WireGuard tar vanligtvis UDP 51820, OpenVPN tar UDP 1194 eller TCP 443, och en webbserver tar TCP 443. Paret som svider är OpenVPN över TCP 443 bredvid HTTPS, eftersom båda vill ha samma socket och kärnan ger den till den som band sig först. Bara en demultiplexer framför, som sslh eller en TLS-medveten proxy, låter dem dela den porten, och den lägger till en komponent vars fel ser exakt ut som ett brandväggsproblem.

Titta på ägarna innan du ändrar något: ss -lntup skriver ut lokal adress, port och process för varje lyssnande socket. Två rader som visar 0.0.0.0:443 betyder att den andra tjänsten aldrig band sig, hur glad dess init-skript än var. Bryggning flyttar också ägaren. När eth0 ansluter till br0, flyttas IP-adressen till br0 och varje brandväggsregel som nämner eth0 slutar matcha, så bind tjänsterna på bryggan och bekräfta med ip -br addr.

Samma ägarregel förklarar en överraskning som dyker upp med virtuella maskiner. En tunnelserver som körs inuti en gäst på samma LAN behåller gästens adress, så anslutningar riktade mot värdens egen adress stannar på värden och gästens tunnel ser dem aldrig, vad klientprofilen än påstår.

Rutta mellan de två näten eller NAT:a ena sidan

Två LAN som inte ser varandra kan var och en ringa den publika värden, som sedan vidarebefordrar mellan tunnlarna. Den routade designen behöver tre saker på plats: vidarebefordran påslagen, en väg mot varje fjärrprefix och en vidarebefordringspolicy som släpper igenom transiten. sysctl -w net.ipv4.ip_forward=1 täcker det första, ip route add 10.20.0.0/24 dev wg1 det andra, och en nftables-rad som nft add rule inet filter forward iifname "wg0" oifname "wg1" accept det tredje.

Käll-NAT är lättare att lägga till och svårare att felsöka. Maskering skriver om klientens adress, så den bortre sidan ser hubben i stället för den verkliga värden, och dess åtkomstregler och loggar slutar vara användbara för attribuering. När båda näten är dina, rutta. När ena sidan tillhör en tredje part som inte lägger till en returväg är NAT alternativet som går ut den här veckan. Skriv i alla fall ned adressplanen, för två överlappande /24 kan inte routas av någon mängd konfiguration.

Inget i att lådan fungerar som internetutgång för en laptop hindrar samma låda från att avsluta inkommande tunnlar. Bara överlappande adresser gör det, och därför är adressplanen dokumentet som spelar roll.

Testa delningen medan två roller är stoppade

Det användbara testet är subtraktion: stoppa två roller och bekräfta att den tredje fortfarande svarar. En webbförfrågan ska slutföras med tunneltjänsten nere, och ett tunnelhandskakning ska slutföras med webbservern stoppad. Om båda bara fungerar när allt körs har du ett oavsiktligt beroende, som en delad brandväggstabell, en vilsegången rutt eller ett namn som pekar på fel adress.

Tre kommandon gör testet konkret. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ bevisar att den lokala lyssnaren svarar utan extern DNS, wg show på klienten bevisar att handskakningen slutfördes, och tcpdump -ni any port 51820 på hubben skiljer ett routingproblem från ett nyckelproblem. En handskakning som aldrig dyker upp i inspelningen dog före värden: leverantörens brandvägg, fel publik adress eller en NAT-regel på vägen.

Upprepa subtraktionen för de vidarebefordrade näten. Med en peer frånkopplad ska en ping över hubben misslyckas; när den är återansluten ska pinget återhämta sig utan att röra en regel. Ett ping som bara återhämtar sig efter omstart av tunneln pekar på policy och inte på nåbarhet, och det är en annan åtgärd.

Håll regeluppsättningen läsbar medan du subtraherar roller. nft list ruleset bör visa en tillåtningsregel per riktning du faktiskt behöver, och en vidarebefordringskedja som tillåter allt är inte separering, det är en fungerande demo.

Endast IPv6-anslutningslinjer och IPv4-tjänster

Vissa anslutningslinjer ger bara IPv6-nåbarhet, och tjänster måste ändå publiceras över IPv4. Själva tunneln färdas över den familj som fortfarande släpper igenom trafik, medan den publicerade tjänsten sitter på en adress inuti tunneln. Det vänder den vanliga assumptionen och bryter tyst övervakningen: en brandväggsregel eller uptime-kontroll skriven för IPv4-vägen bevakar nu ett gränssnitt som inte bär något.

Testa varje familj för sig med curl -4 och curl -6, för en lyckad förfrågan säger inget om vägen du inte provade. Portägande ändras inte mellan familjer, men lyssnaren gör det: ss -lntup listar IPv4- och IPv6-sockets på separata rader, och 0.0.0.0:443 täcker inte [::]:443 om inte processen bad om en dual-stack-socket.

En tjänst som svarar på en familj och nekar på den andra är oftast ett lyssnarproblem, inte ett routingproblem. Innan du kallar designen klar, bekräfta att varje roll äger sin egen adress eller port, att vidarebefordran är påslagen och tillåten, och att varje roll fortfarande svarar med de två andra stoppade.