Én OpenVPN-port, tre tjenester: hvorfor indre porte betyder noget

Én SSH-session, én webapp og ét navneopslag kan dele én enkelt VPN-forbindelse uden at slås om porte. Klienten bygger én krypteret strøm til gatewayen, og hver applikationssamtale rejser indeni den. Udenfor er kun tunnelens egen transport og port synlig. Indeni beholder hver tjeneste sin egen port og har stadig brug for sin egen tilladelse.

Hvad den ydre strøm bærer, og hvad den skjuler

Klienten pakker hver pakke ind i tunnelens transport, før den forlader maskinen. Denne ydre strøm har én destinationsport, fastsat da VPN'en blev konfigureret. Inde i indpakningen beholder hver oprindelig pakke adressen og porten for den tjeneste, den sigter mod. Gatewayen fjerner indpakningen og router på den indre header, så destinationen ser en almindelig klient ankomme fra netværket.

En optagelse på WAN-interfacet viser derfor én samtale, ikke tre. De indre porte vises først efter afkapsling. Derfor kan én enkelt firewall-åbning bære SSH, HTTPS og DNS på samme tid.

# 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 dækker overdragelsen, hvor en rutet TUN-enhed sender IP-pakker mellem kernen og en brugerrumsproces. Denne overdragelse er det, der gør den indre header synlig for gatewayens routing- og firewallkode. Den forklarer også, hvorfor den ydre port intet siger om, hvilke tjenester der er tilladte.

NAT-videresendelsen tilhører lytteren, ikke applikationerne

En selvhostet gateway bag IPv4-NAT har brug for én indgående oversættelse: den offentlige adresse og port mappet til VPN-lytteren. Der kræves ingen regel for SSH, HTTPS eller DNS, bare fordi tunnelbrugere når dem. At offentliggøre disse porte ville blotlægge tjenester, som tunnelen allerede beskytter. Videresendelsesreglen beskriver lytterens tilgængelighed, ikke en tilladelse til noget indeni.

Det omvendte gælder også. At åbne tunnelporten blotlægger intet andet, så en tjeneste, der kun kan nås gennem tunnelen, holder sin offentlige overflade lukket. Denne adskillelse er normalt netop grunden til at holde tjenesten privat.

Den indre politik er, hvor adgangen faktisk afgøres

Kryptering beskytter vejen; den autoriserer ikke en destination. Klientruter vælger, hvilke præfikser der kommer ind i tunnelen, gatewayens videresendelsespolitik afgør, om pakker må forlade den, og destinationens firewall plus login afgør, om tjenesten svarer. DNS er det tydeligste tilfælde: at bære forespørgsler får ikke en resolver til at acceptere dem fra din klientpulje. Hvert lag kan sige nej uafhængigt.

Test hver tjeneste for sig gennem tunnelen. Et vellykket opslag siger intet om webporten, og en vellykket webforespørgsel siger intet 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 fejler, skal du først læse klientens rutetabel. Når én tjeneste fejler, mens de andre virker, sidder fejlen på den destination. De to observationer peger på forskellige ejere, og at blande dem spilder tid.

WireGuard trækker samme linje

WireGuard navngiver sin ydre lytter med ListenPort, og en indre applikation bruger stadig den tjenesteport, den har brug for. AllowedIPs er et sæt rutede præfikser, ikke en liste over tilladte tjenesteporte. At læse det som en port-allowlist giver regler, der ikke passer til det, tunnelen gør. Navngivningen er anderledes; lagdelingen er ikke.

Tillad tjenesten i lokal-input-politikken, når den kører på selve endpointet, eller i videresendelsespolitikken, når den ligger bag det endpoint. Forskellen afgør, hvilket regelsæt der ser pakken.

Den generelle form er én ydre transport med mange indre samtaler. Produkter, der kræver flere ydre udvekslinger eller en anden IP-protokol, er en påmindelse om, at mønstret med én offentlig port beskriver dette design og ikke enhver VPN.