OpenVPN na portu 53: tři rozhovory, které si lidé pletou
Vyhledání koncového bodu, šifrovaný transport a DNS po tunelu jsou tři samostatné rozhovory. Určete, která fáze selhala, než změníte port nebo resolver.
Zprávy, které tvrdí, že VPN je zablokovaná na portu 53, míchají tři pozorování, která selhávají z různých důvodů. Překlad názvu koncového bodu probíhá dříve, než existuje jakýkoli tunel, šifrovaný transport je samostatný rozhovor a DNS dotazy provedené poté jsou třetí. Každé má svůj vlastní podpis selhání a jen jedno z nich se vůbec týká DNS.
Než cokoli změníte, roztřiďte pakety podle účelu, protože oprava se řídí fází.
Tři rozhovory, jedno číslo portu
První rozhovor je vyhledání názvu pro koncový bod: váš stroj se ptá nakonfigurovaného resolveru, kde se nachází vpn.example.com, a tato odpověď dorazí přes běžný DNS ještě předtím, než klient odešle jediný paket tunelu. Druhý je samotný transport OpenVPN, který se připojuje na adresu, kterou vyhledání vrátilo, přes protokol a port, které určuje profil. Třetí nastává po zprovoznění tunelu, kdy aplikace žádají názvy a potlačená nastavení resolveru rozhodují, kdo odpoví.
Tyto tři mohou uspět nebo selhat nezávisle. Klient může svůj koncový bod dokonale přeložit a přesto nedosáhnout naslouchající proces, a může navázat tunel, zatímco každé interní vyhledání názvu selhává, protože nastavení DNS nikdy nedorazila.
| Conversation | When it happens | What has to be true |
|---|---|---|
| Endpoint lookup | Before the client contacts a hostname | An underlying resolver path can answer for the endpoint name |
| OpenVPN transport | During tunnel establishment | The gateway listens on its configured transport, address and port, and nothing filters it |
| Application DNS | During or after the protected session | A resolver the client can reach, plus routing that carries its queries |
Čtěte tabulku jako kontrolní seznam, ne jako popis. Pokud se název koncového bodu nepřeloží, nic dalšího nemůže fungovat a tunel se nikdy nespustí.
Číslo portu aplikaci nepojmenovává
Port 53 nese DNS podle konvence a operátor OpenVPN na něm může také zveřejnit naslouchající proces, což je přesně důvod, proč je číslo špatným identifikátorem. Relace OpenVPN na UDP 53 je stále relací OpenVPN a DNS dotaz na server na portu 53 nic neříká o tom, zda je tunel povolen. Řádky proto a remote v profilu definují vnější koncový bod; číslo portu samo o sobě ne definuje nic.
Při diagnostice to platí oběma směry: obecná UDP sonda na port 53 dokazuje, že port odpovídá, ne že odpovídá služba VPN. Testujte skutečným klientem a skutečným profilem, protože jen to procvičí handshake, který služba očekává.
Dokažte naslouchající proces, než obviníte síť
Na serveru ověřte, co je vázáno pomocí ss -lunp | grep 53, a porovnejte to s protokolem a portem profilu. Ze sítě klienta spusťte klienta s vyšší podrobností, aby protokol ukázal, kterou adresu a transport zkusil. Pokud server naslouchá a pakety klienta nedorazí, cesta nebo politika je odmítá, a to je rozhovor pro vlastníka sítě, ne důvod měnit porty.
Jiný port pomůže jen tehdy, když na něm služba skutečně naslouchá a nasazení to dovoluje. Přesunout naslouchající proces, aby se vyhnul filtrování spravované sítě, je rozhodnutí o politice, ne krok řešení potíží. Než službu změníte, zeptejte se vlastníka sítě, co je povoleno, protože obchvat, který porušuje politiku, bude později stejně uzavřen. Zapište tuto odpověď vedle profilu, aby další člověk žádost neopakoval.
Zkontrolujte DNS po tunelu, odděleně
Jakmile je tunel zprovozněný, prohlédněte stav resolveru na rozhraní VPN a dotážete se na jeden interní a jeden veřejný název. Pokud interní názvy selhávají, zatímco tunel přenáší provoz, potlačená nastavení DNS nebyla použita, což je otázka integrace klienta, ne transportu. Pokud veřejné názvy selhávají a interní fungují, politika rozděleného tunelu dělá to, pro co byla nakonfigurována.
Změny DNS nechte na vlastníkovi resolveru. Přepsání spravované konfigurace resolveru, aby prošel jeden test, může rozbít privátní názvy pro všechno ostatní na stroji. Pokud tunel potlačuje resolver a klient jej ignoruje, opravte integraci klienta místo přidávání statické položky někam jinam. Statické položky skrývají selhání, dokud někdo nezmění síť. Zapište, který resolver má odpovídat za každý jmenný prostor.