OpenVPN na portu 53: tri razgovora koja ljudi miješaju
Pretraga krajnje točke, šifrirani transport i DNS nakon tunela tri su odvojena razgovora. Utvrdite koja je faza zakazala prije nego promijenite port ili resolver.
Izvještaji koji kažu da je VPN blokiran na portu 53 miješaju tri zapažanja koja zataje iz različitih razloga. Razrješavanje imena krajnje točke događa se prije nego postoji bilo kakav tunel, šifrirani transport je odvojen razgovor, a DNS upiti nakon toga treći. Svako ima svoj potpis kvara, a samo je jedno od njih uopće o DNS-u.
Razvrstajte pakete po namjeni prije nego bilo što promijenite, jer popravak slijedi fazu.
Tri razgovora, jedan broj porta
Prvi razgovor je pretraga imena za krajnju točku: vaše računalo pita svoj konfigurirani resolver gdje se nalazi vpn.example.com, a taj odgovor dolazi preko običnog DNS-a prije nego klijent pošalje ijedan paket tunela. Drugi je sam transport OpenVPN-a, koji se povezuje na adresu koju je pretraga dala, preko protokola i porta koje profil navodi. Treći se događa nakon što je tunel podignut, kada aplikacije traže imena, a pushane postavke resolvera odlučuju tko odgovara.
Ta tri mogu uspjeti ili zatajiti neovisno. Klijent može savršeno razriješiti svoju krajnju točku i ipak ne doći do slušača, a može i uspostaviti tunel dok svaka unutarnja pretraga imena zataji jer DNS postavke nikada nisu stigle.
| 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 |
Čitajte tablicu kao kontrolni popis, a ne kao opis. Ako se ime krajnje točke ne razriješi, ništa kasnije ne može raditi i tunel nikada ne počinje.
Broj porta ne imenuje aplikaciju
Port 53 po konvenciji nosi DNS, a OpenVPN operater može i tamo objaviti slušač, što je upravo razlog zašto je broj loš identifikator. OpenVPN sesija na UDP 53 i dalje je OpenVPN sesija, a DNS upit poslužitelju na portu 53 ne govori ništa o tome je li tunel dopušten. Linije proto i remote u profilu određuju vanjsku krajnju točku; broj porta sam po sebi ne određuje ništa.
To reže na obje strane pri dijagnostici: generička UDP sonda na port 53 dokazuje da port odgovara, a ne da VPN usluga odgovara. Testirajte pravim klijentom i pravim profilom, jer samo to vježba rukovanje koje usluga očekuje.
Dokažite slušač prije nego okrivite mrežu
Na poslužitelju potvrdite što je vezano pomoću ss -lunp | grep 53 i usporedite s protokolom i portom profila. Iz klijentove mreže pokrenite klijent s većom razinom detalja kako bi zapis pokazao koju je adresu i transport pokušao. Ako poslužitelj sluša, a klijentovi paketi ne dolaze, put ili politika ih odbijaju, i to je razgovor za vlasnika mreže, a ne razlog za promjenu portova.
Drugi port pomaže samo kad usluga doista sluša tamo i kada to implementacija dopušta. Premještanje slušača da bi se izbjeglo filtriranje upravljane mreže odluka je o politici, a ne korak za rješavanje problema. Pitajte vlasnika mreže što je dopušteno prije nego promijenite uslugu, jer zaobilazno rješenje koje krši politiku kasnije se ipak zatvara. Zapišite taj odgovor uz profil kako sljedeća osoba ne bi ponovila zahtjev.
Provjerite DNS nakon tunela, odvojeno
Kad je tunel podignut, pregledajte stanje resolvera na VPN sučelju i upitajte jedno unutarnje i jedno javno ime. Ako unutarnja imena zataje dok tunel prenosi promet, pushane DNS postavke nisu primijenjene, što je pitanje integracije klijenta, a ne transporta. Ako javna imena zataje, a unutarnja rade, politika razdvojenog tunela radi ono za što je konfigurirana.
Zadržite DNS promjene kod vlasnika resolvera. Prepisivanje upravljane konfiguracije resolvera da bi jedan test prošao može slomiti privatna imena za sve ostalo na računalu. Ako tunel pusha resolver, a klijent ga ignorira, popravite integraciju klijenta umjesto da dodajete statički unos negdje drugdje. Statički unosi skrivaju kvar dok netko ne promijeni mrežu. Zapišite koji resolver treba odgovarati za svaki imenski prostor.