En OpenVPN-port, tre tjänster: därför spelar inre portar roll

En SSH-session, en webbapp och en namnsökning kan dela en enda VPN-anslutning utan att slåss om portar. Klienten bygger ett krypterat flöde till gatewayen, och varje applikationssamtal färdas inuti det. Utanför syns bara tunnelns egen transport och port. Inuti behåller varje tjänst sin egen port och behöver fortfarande sin egen behörighet.

Vad det yttre flödet bär, och vad det döljer

Klienten lindar in varje paket i tunnelns transport innan det lämnar maskinen. Det yttre flödet har en destinationsport, fastställd när VPN:en konfigurerades. Inuti omslaget behåller varje originalpaket adressen och porten för den tjänst det riktar sig till. Gatewayen tar bort omslaget och routar på den inre headern, så destinationen ser en vanlig klient som anländer från nätet.

En avlyssning på WAN-gränssnittet visar därför ett samtal, inte tre. De inre portarna syns först efter avkapsling. Därför kan en enda brandväggsöppning bära SSH, HTTPS och DNS samtidigt.

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

TUN/TAP-dokumentationen beskriver överlämningen där en routad TUN-enhet skickar IP-paket mellan kärnan och en process i användarutrymmet. Den överlämningen är det som gör den inre headern synlig för gatewayens routing- och brandväggskod. Den förklarar också varför den yttre porten inte säger något om vilka tjänster som är tillåtna.

NAT-vidarebefordran tillhör lyssnaren, inte applikationerna

En egenhostad gateway bakom IPv4-NAT behöver en inkommande översättning: den offentliga adressen och porten mappas till VPN-lyssnaren. Ingen regel krävs för SSH, HTTPS eller DNS bara för att tunnelanvändare når dem. Att publicera dessa portar skulle exponera tjänster som tunneln redan skyddar. Vidarebefordringsregeln beskriver lyssnarens nåbarhet, inte en behörighet för något inuti.

Det omvända gäller också. Att öppna tunnelporten exponerar inget annat, så en tjänst som bara nås via tunneln håller sin offentliga yta stängd. Den separationen är oftast skälet att hålla tjänsten privat.

Den inre policyn är där åtkomst faktiskt avgörs

Kryptering skyddar vägen; den auktoriserar inte en destination. Klientrutter väljer vilka prefix som går in i tunneln, gatewayens vidarebefordringspolicy avgör om paket får lämna den, och destinationens brandvägg plus inloggning avgör om tjänsten svarar. DNS är det tydligaste fallet: att bära frågor gör inte en resolver villig att acceptera dem från din klientpool. Varje lager kan säga nej oberoende.

Testa varje tjänst för sig genom tunneln. En lyckad sökning säger inget om webbporten, och en lyckad webbförfrågan säger inget om SSH.

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

När tunneln är uppe och allt misslyckas, läs klientens routingtabell först. När en tjänst misslyckas medan de andra fungerar sitter felet på den destinationen. De två observationerna pekar på olika ägare, och att blanda dem slösar tid.

WireGuard drar samma linje

WireGuard namnger sin yttre lyssnare ListenPort, och en inre applikation använder fortfarande den tjänsteport den behöver. AllowedIPs är en uppsättning routade prefix, inte en lista över tillåtna tjänsteportar. Att läsa det som en portallowlist ger regler som inte stämmer med vad tunneln gör. Namngivningen är annorlunda; lagreringen är det inte.

Tillåt tjänsten i lokal input-policy när den körs på själva ändpunkten, eller i vidarebefordringspolicy när den sitter bakom den ändpunkten. Skillnaden avgör vilken regeluppsättning som ser paketet.

Den allmänna formen är en yttre transport med många inre samtal. Produkter som behöver flera yttre utbyten, eller ett annat IP-protokoll, påminner om att mönstret med en offentlig port beskriver den här designen och inte varje VPN.