Izvještaji koji kažu da je VPN blokiran na portu 53 miješaju tri zapažanja koja zataje zbog različitih razloga. Razrješavanje imena završne točke događa se prije nego što tunel uopće postoji, šifrirani je prijenos zaseban razgovor, a DNS-upiti koji se izvode poslije treći su. Svaki ima svoj potpis kvara, i samo se jedan od njih uopće tiče DNS-a.

Razvrstajte pakete prema namjeni prije nego što bilo što promijenite, jer popravak slijedi fazu.

Tri razgovora, jedan broj porta

Prvi razgovor je traženje imena završne točke: vaše računalo pita svoj konfigurirani razrješivač gdje se nalazi vpn.example.com, a taj odgovor dolazi običnim DNS-om prije nego što klijent pošalje ijedan tunelski paket. Drugi je sam OpenVPN prijenos, koji se povezuje na adresu koju je traženje dalo, na onom protokolu i portu koje profil navede. Treći se događa nakon što je tunel podignut, kada aplikacije traže imena, a gurnute postavke razrješivača odlučuju tko odgovara.

Ta tri mogu uspjeti ili zatajiti neovisno. Klijent može savršeno razriješiti svoju završnu točku i ipak ne doći do slušača, a može i uspostaviti tunel dok svako interno traženje imena zataji jer DNS postavke nikada nisu stigle.

ConversationWhen it happensWhat has to be true
Endpoint lookupBefore the client contacts a hostnameAn underlying resolver path can answer for the endpoint name
OpenVPN transportDuring tunnel establishmentThe gateway listens on its configured transport, address and port, and nothing filters it
Application DNSDuring or after the protected sessionA resolver the client can reach, plus routing that carries its queries

Čitajte tablicu kao popis za provjeru, a ne kao opis. Ako se ime završne 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 nosi DNS po konvenciji, a OpenVPN operater može ondje objaviti i slušač, i upravo zato je taj broj loša oznaka. OpenVPN sesija na UDP 53 i dalje je OpenVPN sesija, a DNS upit poslan poslužitelju na portu 53 ne govori ništa o tome je li tunel dopušten. Retci proto i remote u profilu određuju vanjsku završnu 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 neki port odgovara, a ne da odgovara VPN usluga. Testirajte pravim klijentom i pravim profilom, jer samo to izvodi rukovanje koje usluga očekuje.

Dokažite slušač prije nego optužite mrežu

Na poslužitelju provjerite što je vezano pomoću ss -lunp | grep 53 i usporedite s protokolom i portom iz profila. Iz klijentove mreže pokrenite klijent s većom razinom detalja kako bi zapis pokazao koju je adresu i prijenos pokušao. Ako poslužitelj sluša, a klijentovi paketi ne dolaze, put ili pravila ih odbijaju, i to je razgovor s vlasnikom mreže, a ne razlog za promjenu porta.

Drugi port pomaže samo kada usluga ondje doista sluša i kada to implementacija dopušta. Premještanje slušača da bi se izbjeglo filtriranje upravljane mreže odluka je o pravilima, a ne korak u rješavanju problema. Pitajte vlasnika mreže što je dopušteno prije nego promijenite uslugu, jer zaobilazno rješenje koje krši pravila kasnije se ipak zatvara. Zapišite taj odgovor uz profil da sljedeća osoba ne ponovi zahtjev.

Provjerite DNS nakon tunela, odvojeno

Kad je tunel podignut, pregledajte stanje razrješivača na VPN sučelju i upitajte jedno interno i jedno javno ime. Ako interna imena zataje dok tunel prenosi promet, gurnute DNS postavke nisu primijenjene, što je pitanje integracije klijenta, a ne prijenosa. Ako javna imena zataje, a interna rade, pravilo podijeljenog tunela radi ono za što je postavljeno.

Ostavite DNS promjene vlasniku razrješivača. Prepisivanje upravljane konfiguracije razrješivača da bi jedan test prošao može pokvariti privatna imena za sve ostalo na računalu. Ako tunel gura razrješivač, a klijent ga ignorira, popravite integraciju klijenta umjesto da negdje drugdje dodate statički zapis. Statički zapisi skrivaju kvar dok netko ne promijeni mrežu. Zapišite koji razrješivač treba odgovarati na koji prostor imena.

Povezani članci