Jeden port OpenVPN, tri služby: prečo záleží na vnútorných portoch

Jedna relácia SSH, jedna webová aplikácia a jedno vyhľadanie názvu môžu zdieľať jedno VPN pripojenie bez boja o porty. Klient vytvorí jeden šifrovaný tok ku bráne a každý rozhovor aplikácie cestuje v jeho vnútri. Zvonku je viditeľná iba vlastná doprava tunela a jeho port. Vnútri si každá služba zachováva vlastný port a stále potrebuje vlastné povolenie.

Čo vonkajší tok nesie a čo skrýva

Klient zabalí každý paket do dopravy tunela predtým, než opustí stroj. Tento vonkajší tok má jeden cieľový port, pevne určený pri konfigurácii VPN. Vnútri obalu si každý pôvodný paket zachováva adresu a port služby, na ktorú mieri. Brána odstráni obal a smeruje podľa vnútorného hlavičky, takže cieľ vidí bežného klienta prichádzajúceho zo siete.

Záznam na rozhraní WAN preto ukazuje jeden rozhovor, nie tri. Vnútorné porty sa objavia až po dekapsulácii. Preto jedno otvorenie firewallu môže niesť SSH, HTTPS aj DNS súčasne.

# 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

Dokumentácia TUN/TAP opisuje odovzdanie, pri ktorom smerované zariadenie TUN odovzdáva IP pakety medzi jadrom a procesom v používateľskom priestore. Práve toto odovzdanie robí vnútornú hlavičku viditeľnou pre smerovanie a firewallový kód brány. Vysvetľuje tiež, prečo vonkajší port nič nehovorí o tom, ktoré služby sú povolené.

NAT presmerovanie patrí poslucháčovi, nie aplikáciám

Samo-hostovaná brána za NAT IPv4 potrebuje jeden vstupný preklad: verejná adresa a port sa mapujú na VPN poslucháča. Žiadne pravidlo nie je potrebné pre SSH, HTTPS ani DNS len preto, že používatelia tunela sa k nim dostanú. Zverejnenie týchto portov by odhalilo služby, ktoré tunel už chráni. Pravidlo presmerovania opisuje dostupnosť poslucháča, nie povolenie pre čokoľvek vnútri.

Platí to aj opačne. Otvorenie portu tunela neodhalí nič iné, takže služba dostupná iba cez tunel si drží svoju verejnú plochu zatvorenú. To oddelenie je zvyčajne dôvod, prečo službu držať v súkromí.

Vnútorná politika je miesto, kde sa prístup skutočne rozhoduje

Šifrovanie chráni cestu; neoprávňuje cieľ. Trasy klienta vyberajú, ktoré prefixy vstúpia do tunela, politika presmerovania brány rozhoduje, či pakety môžu odísť, a firewall a prihlásenie cieľa rozhodujú, či služba odpovie. DNS je najjasnejší prípad: prenášanie dopytov nespôsobí, že resolver ich prijme z vášho klientskeho fondu. Každá vrstva môže povedať nie nezávisle.

Testujte každú službu samostatne cez tunel. Úspešné vyhľadanie nič nehovorí o webovom porte a úspešná webová požiadavka nič nehovorí o SSH.

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

Keď je tunel aktívny a všetko zlyháva, najprv si prečítajte smerovaciu tabuľku klienta. Keď jedna služba zlyhá, zatiaľ čo ostatné fungujú, porucha je na tom cieli. Tieto dve pozorovania ukazujú na rôznych vlastníkov a ich miešanie stráca čas.

WireGuard ťahá rovnakú líniu

WireGuard nazýva svoj vonkajší poslucháč ListenPort, a vnútorná aplikácia stále používa port služby, ktorý potrebuje. AllowedIPs je množina smerovaných prefixov, nie zoznam povolených portov služieb. Čítanie ako zoznamu povolených portov vytvára pravidlá, ktoré nezodpovedajú tomu, čo tunel robí. Pomenovanie je iné; vrstvenie nie.

Povoľte službu v pravidlách lokálneho vstupu, keď beží priamo na koncovom bode, alebo v pravidlách presmerovania, keď je za týmto koncovým bodom. Tento rozdiel rozhoduje, ktorá sada pravidiel paket uvidí.

Všeobecný tvar je jedna vonkajšia doprava s mnohými vnútornými rozhovormi. Produkty, ktoré potrebujú viacero vonkajších výmen alebo iný protokol IP, pripomínajú, že vzor jedného verejného portu opisuje tento dizajn, nie každú VPN.