Én OpenVPN-port, tre tjenester: derfor betyr indre porter noe

Én SSH-økt, én webapp og ett navneoppslag kan dele én VPN-tilkobling uten å slåss om porter. Klienten bygger én kryptert strøm til gatewayen, og hver applikasjonssamtale reiser inne i den. Utenfor er bare tunnelens egen transport og port synlig. Inne beholder hver tjeneste sin egen port og trenger fortsatt sin egen tillatelse.

Hva den ytre strømmen bærer, og hva den skjuler

Klienten pakker hver pakke inn i tunnelens transport før den forlater maskinen. Den ytre strømmen har én destinasjonsport, fastsatt da VPN-en ble konfigurert. Inni innpakningen beholder hver opprinnelige pakke adressen og porten til tjenesten den er rettet mot. Gatewayen fjerner innpakningen og ruter på den indre headeren, slik at destinasjonen ser en vanlig klient som kommer fra nettet.

Et opptak på WAN-grensesnittet viser derfor én samtale, ikke tre. De indre portene vises først etter dekapsulering. Derfor kan én brannmuråpning bære SSH, HTTPS og DNS samtidig.

# 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-dokumentasjonen dekker overleveringen der en rutet TUN-enhet sender IP-pakker mellom kjernen og en brukerromsprosess. Den overleveringen er det som gjør den indre headeren synlig for gatewayens ruting- og brannmurkode. Den forklarer også hvorfor den ytre porten ikke sier noe om hvilke tjenester som er tillatt.

NAT-videresendingen tilhører lytteren, ikke applikasjonene

En selvhostet gateway bak IPv4 NAT trenger én innkommende oversettelse: den offentlige adressen og porten knyttes til VPN-lytteren. Ingen regel kreves for SSH, HTTPS eller DNS bare fordi tunnelbrukere når dem. Å publisere disse portene ville eksponere tjenester tunnelen allerede beskytter. Videresendingsregelen beskriver lytterens tilgjengelighet, ikke en tillatelse for noe inni.

Det motsatte gjelder også. Å åpne tunnelporten eksponerer ingenting annet, så en tjeneste som bare nås gjennom tunnelen holder den offentlige flaten lukket. Den separasjonen er vanligvis grunnen til å holde tjenesten privat i utgangspunktet.

Indre policy er der tilgangen faktisk avgjøres

Kryptering beskytter veien; den autoriserer ikke en destinasjon. Klientruter velger hvilke prefikser som går inn i tunnelen, gatewayens videresendingspolicy avgjør om pakker kan forlate den, og destinasjonens brannmur pluss innlogging avgjør om tjenesten svarer. DNS er det klareste tilfellet: å bære spørringer gjør ikke en resolver villig til å godta dem fra klientpoolen din. Hvert lag kan si nei uavhengig.

Test hver tjeneste for seg gjennom tunnelen. Et vellykket oppslag sier ingenting om webporten, og en vellykket webforespørsel sier ingenting om SSH.

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

Når tunnelen er oppe og alt feiler, les klientens rutetabell først. Når én tjeneste feiler mens de andre virker, sitter feilen på den destinasjonen. De to observasjonene peker på forskjellige eiere, og å blande dem kaster bort tid.

WireGuard trekker samme linje

WireGuard navngir sin ytre lytter med ListenPort, og en indre applikasjon bruker fortsatt den tjenesteporten den trenger. AllowedIPs er et sett med rutede prefikser, ikke en liste over tillatte tjenesteportet. Å lese det som en portallowlist gir regler som ikke samsvarer med det tunnelen gjør. Navngivningen er annerledes; lagdelingen er ikke.

Tillat tjenesten i lokal input-policy når den kjører på endepunktet selv, eller i videresendingspolicy når den sitter bak det endepunktet. Forskjellen avgjør hvilket regelsett som ser pakken.

Den generelle formen er én ytre transport med mange indre samtaler. Produkter som trenger flere ytre utvekslinger, eller en annen IP-protokoll, minner om at mønsteret med én offentlig port beskriver denne designen og ikke enhver VPN.