Éin OpenVPN-port, tre tenester: derfor er indre portar viktige

Éi SSH-økt, éin webapp og eitt namneoppslag kan dele éi VPN-tilkopling utan å slåst om portar. Klienten byggjer éin kryptert straum til gatewayen, og kvar applikasjonssamtale reiser inne i han. Utanfor er berre tunnelens eigen transport og port synleg. Inne held kvar teneste sin eigen port og treng framleis sitt eige løyve.

Kva den ytre straumen ber, og kva han skjuler

Klienten pakkar kvar pakke inn i transporten til tunnelen før ho forlèt maskinen. Den ytre straumen har éin destinasjonsport, fastsett då VPN-en vart konfigurert. Inne i innpakkinga held kvar opphavlege pakke adressa og porten til tenesta han er retta mot. Gatewayen fjernar innpakkinga og rutar på den indre headeren, slik at destinasjonen ser ein vanleg klient som kjem frå nettet.

Eit opptak på WAN-grensesnittet viser derfor éin samtale, ikkje tre. Dei indre portane viser seg først etter dekapsulering. Derfor kan éi brannmur-opning bera SSH, HTTPS og DNS samstundes.

# 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 dekkjer overleveringa der ein ruta TUN-eining sender IP-pakkar mellom kjernen og ein brukarromsprosess. Den overleveringa er det som gjer den indre headeren synleg for ruting- og brannmurkoden til gatewayen. Ho forklarer òg kvifor den ytre porten ikkje seier noko om kva tenester som er tillatne.

NAT-vidaresendinga høyrer til lyttaren, ikkje applikasjonane

Ein sjølvhosta gateway bak IPv4 NAT treng éi innkomande omsetjing: den offentlege adressa og porten blir knytte til VPN-lyttaren. Ingen regel er naudsynt for SSH, HTTPS eller DNS berre fordi tunnelbrukarar når dei. Å publisere desse portane ville eksponere tenester tunnelen allereie vernar. Vidaresendingsregelen skildrar tilgjengelegheita til lyttaren, ikkje eit løyve for noko inni.

Det motsette gjeld òg. Å opne tunnelporten eksponerer ingenting anna, så ei teneste som berre er nåbar gjennom tunnelen held den offentlege flata si lukka. Den skilnaden er vanlegvis grunnen til å halde tenesta privat i utgangspunktet.

Indre politikk er der tilgangen faktisk blir avgjord

Kryptering vernar vegen; ho autoriserer ikkje ein destinasjon. Klientruter vel kva prefiks som går inn i tunnelen, vidaresendingspolitikken til gatewayen avgjer om pakkar kan forlata han, og brannmuren og innlogginga til destinasjonen avgjer om tenesta svarar. DNS er det klåraste tilfellet: å bera spørjingar gjer ikkje ein resolver villig til å godta dei frå klientpoolen din. Kvart lag kan seie nei sjølvstendig.

Test kvar teneste for seg gjennom tunnelen. Eit vellukka oppslag seier ingenting om webporten, og ei vellukka webførespurnad seier 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 feilar, les rutetabellen til klienten først. Når éi teneste feilar medan dei andre verkar, sit feilen på den destinasjonen. Dei to observasjonane peikar på ulike eigarar, og å blande dei kastar bort tid.

WireGuard dreg same linja

WireGuard kallar den ytre lyttaren sin ListenPort, og ein indre applikasjon brukar framleis den tenesteporten han treng. AllowedIPs er eit sett med ruta prefiks, ikkje ei liste over tillatne tenesteportar. Å lese det som ei port-tillatingsliste gir reglar som ikkje samsvarer med det tunnelen gjer. Namngjevinga er annleis; lagdelinga er ikkje.

Tillat tenesta i lokal input-politikk når ho køyrer på endepunktet sjølv, eller i vidaresendingspolitikk når ho sit bak det endepunktet. Skilnaden avgjer kva regelsett som ser pakken.

Den generelle forma er éin ytre transport med mange indre samtalar. Produkt som treng fleire ytre utvekslingar, eller ein annan IP-protokoll, minner om at mønsteret med éin offentleg port skildrar dette designet og ikkje kvar VPN.