OpenVPN na porte 53: tri rozhovory, ktoré si ľudia mýlia
Rozlíšenie názvu koncového bodu, šifrovaný prenos a DNS po tuneli sú tri rozhovory. Zistite, ktorá fáza zlyhala, skôr než zmeníte port alebo resolver.
Správy, ktoré tvrdia, že VPN je na porte 53 zablokovaná, miešajú tri pozorovania, ktoré zlyhávajú z rôznych dôvodov. Rozlíšenie názvu koncového bodu sa deje skôr, než existuje tunel, šifrovaný prenos je samostatný rozhovor a DNS dopyty vykonané neskôr sú tretie. Každé má svoj vlastný podpis zlyhania a iba jedno z nich sa vôbec týka DNS.
Pred akoukoľvek zmenou zoraďte pakety podľa účelu, pretože oprava nasleduje fázu.
Tri rozhovory, jedno číslo portu
Prvý rozhovor je vyhľadanie názvu koncového bodu: váš počítač sa pýta nakonfigurovaného resolvera, kde sa nachádza vpn.example.com, a táto odpoveď prichádza cez bežný DNS skôr, než klient odošle čo i len jeden tunelový paket. Druhý je samotný prenos OpenVPN, ktorý sa pripája k adrese, ktorú vyhľadanie poskytlo, na protokole a porte uvedených v profile. Tretí sa deje po tom, čo je tunel postavený, keď aplikácie žiadajú názvy a odoslané nastavenia resolvera rozhodujú, kto odpovie.
Tieto tri môžu uspieť alebo zlyhať nezávisle. Klient môže dokonale rozlíšiť svoj koncový bod a napriek tomu sa nedostať k poslucháčovi a môže vytvoriť tunel, kým každé interné vyhľadanie názvu zlyháva, pretože nastavenia DNS nikdy nedorazili.
| 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 |
Čítajte tabuľku ako kontrolný zoznam, nie ako opis. Ak sa názov koncového bodu nerozlíši, nič neskôr nemôže fungovať a tunel sa nikdy nezačne.
Číslo portu nepomenúva aplikáciu
Port 53 nesie DNS podľa konvencie a operátor OpenVPN tam môže tiež zverejniť poslucháča, a práve preto je toto číslo slabý identifikátor. Relácia OpenVPN na UDP 53 je stále relácia OpenVPN a DNS dopyt na server na porte 53 nehovorí nič o tom, či je tunel povolený. Riadky proto a remote profilu určujú vonkajší koncový bod; číslo portu samo o sebe nič neurčuje.
Pri diagnostike to reže na obe strany: všeobecná UDP sonda na port 53 dokazuje, že port odpovedá, nie že odpovedá služba VPN. Testujte so skutočným klientom a skutočným profilom, pretože iba to precvičuje podanie ruky, ktoré služba očakáva.
Dokážte poslucháča, skôr než obviníte sieť
Na serveri overte, čo je viazané pomocou ss -lunp | grep 53, a porovnajte s protokolom a portom profilu. Zo siete klienta spustite klienta s väčšou podrobnosťou, aby záznam ukázal, ktorú adresu a prenos skúsil. Ak server počúva a pakety klienta neprichádzajú, odmieta ich cesta alebo politika, a to je rozhovor s vlastníkom siete, nie dôvod meniť port.
Iný port pomáha len vtedy, keď na ňom služba skutočne počúva a nasadenie to dovoľuje. Presun poslucháča, aby sa obišlo filtrovanie spravovanej siete, je rozhodnutie o politike, nie krok pri riešení problémov. Pred zmenou služby sa opýtajte vlastníka siete, čo je dovolené, pretože obchádzka porušujúca politiku sa neskôr aj tak uzavrie. Zapíšte tú odpoveď vedľa profilu, aby nasledujúci človek neopakoval žiadosť.
Skontrolujte DNS po tuneli, oddelene
Keď je tunel postavený, preskúmajte stav resolvera na rozhraní VPN a opýtajte sa na jeden interný a jeden verejný názov. Ak interné názvy zlyhávajú, kým tunel prenáša prevádzku, odoslané nastavenia DNS sa neuplatnili, čo je otázka integrácie klienta, nie prenosu. Ak verejné názvy zlyhávajú a interné fungujú, politika rozdeleného tunela robí to, na čo bola nakonfigurovaná.
Zmeny DNS nechajte vlastníkovi resolvera. Prepísanie spravovanej konfigurácie resolvera, aby jeden test prešiel, môže pokaziť súkromné názvy pre všetko ostatné na počítači. Ak tunel posiela resolver a klient ho ignoruje, opravte integráciu klienta namiesto pridania statického záznamu inde. Statické záznamy skrývajú zlyhanie, kým niekto nezmení sieť. Zapíšte, ktorý resolver má odpovedať na ktorý menný priestor.