Jeden port OpenVPN, tři služby: proč záleží na vnitřních portech

Jedno SSH sezení, jedna webová aplikace a jedno vyhledání názvu mohou sdílet jedno VPN připojení, aniž by se přely o porty. Klient vytváří jeden šifrovaný tok k bráně a každá komunikace aplikace v něm putuje. Zvenčí jsou viditelné jen vlastní transport a port tunelu. Uvnitř si každá služba zachovává svůj port a stále potřebuje vlastní oprávnění.

Co nese vnější tok a co skrývá

Klient zabalí každý paket do transportu tunelu, než opustí stroj. Tento vnější tok má jeden cílový port, pevně daný při konfiguraci VPN. Uvnitř obalu si každý původní paket zachovává adresu a port služby, na kterou míří. Brána obal odstraní a směruje podle vnitřní hlavičky, takže cíl vidí běžného klienta přicházejícího ze sítě.

Odposlech na rozhraní WAN tedy ukazuje jeden rozhovor, nikoli tři. Vnitřní porty se objeví až po dekapsulaci. Proto může jediné otevření firewallu přenášet SSH, HTTPS i DNS současně.

# 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

Dokumentace TUN/TAP popisuje předání, při kterém směrované zařízení TUN předává IP pakety mezi jádrem a procesem v uživatelském prostoru. Právě toto předání zpřístupňuje vnitřní hlavičku směrovacímu a firewallovému kódu brány. Vysvětluje také, proč vnější port nic neříká o tom, které služby jsou povoleny.

Přesměrování NAT patří naslouchajícímu procesu, ne aplikacím

Samoobsluhovaná brána za NATem IPv4 potřebuje jeden příchozí překlad: veřejnou adresu a port namapované na naslouchající proces VPN. Pro SSH, HTTPS nebo DNS není nutné žádné pravidlo jen proto, že se k nim uživatelé tunelu dostanou. Zveřejnění těchto portů by odhalilo služby, které tunel už chrání. Pravidlo přesměrování popisuje dosažitelnost naslouchajícího procesu, nikoli oprávnění pro cokoli uvnitř.

Platí to i obráceně. Otevření portu tunelu nic dalšího nevystaví, takže služba dostupná jen tunelem zůstává na veřejné straně zavřená. Právě toto oddělení je obvykle důvod, proč se služba vůbec drží v soukromí.

O přístupu se ve skutečnosti rozhoduje ve vnitřní politice

Šifrování chrání cestu; neautorizuje cíl. Routy klienta určují, které prefixy vstoupí do tunelu, politika přesměrování brány rozhoduje, zda pakety mohou tunel opustit, a firewall cíle spolu s přihlášením rozhodují, zda služba odpoví. DNS je nejjasnější případ: přenášení dotazů neznamená, že resolver je přijme z vašeho poolu klientů. Každá vrstva může nezávisle říci ne.

Otestujte každou službu zvlášť tunelem. Úspěšné vyhledání neříká nic o webovém portu a úspěšný webový požadavek neříká nic o SSH.

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

Když je tunel nahozený a všechno selhává, přečtěte si nejprve routovací tabulku klienta. Když selže jedna služba, zatímco ostatní fungují, závada je na onom cíli. Tato dvě pozorování ukazují na různé vlastníky a jejich míchání ztrácí čas.

WireGuard kreslí stejnou hranici

WireGuard pojmenovává svůj vnější naslouchající proces pomocí ListenPort a vnitřní aplikace stále používá jakýkoli port služby, který potřebuje. AllowedIPs je množina směrovaných prefixů, nikoli seznam povolených portů služeb. Čtení tohoto jako seznamu povolených portů vede k pravidlům, která neodpovídají tomu, co tunel dělá. Pojmenování je jiné; vrstvení ne.

Povolte službu v politice místního vstupu, když běží na samotném koncovém bodu, nebo v politice přesměrování, když se nachází za tímto koncovým bodem. Toto rozlišení rozhoduje, která sada pravidel paket uvidí.

Obecný tvar je jeden vnější transport s mnoha vnitřními rozhovory. Produkty, které potřebují několik vnějších výměn nebo jiný IP protokol, připomínají, že vzor jednoho veřejného portu popisuje tento návrh, a ne každou VPN.