Извештаји који кажу да је VPN блокиран на порту 53 мешају три запажања која отказују из различитих разлога. Разрешавање имена крајње тачке дешава се пре него што тунел уопште постоји, шифровани пренос је засебан разговор, а DNS упити који се изводе после су трећи. Сваки има свој потпис квара, и само се један од њих уопште тиче DNS-а.

Разврстајте пакете према намени пре него што било шта промените, јер поправка следи фазу.

Три разговора, један број порта

Први разговор је тражење имена крајње тачке: ваш рачунар пита свој конфигурисани резолвер где се налази vpn.example.com, а тај одговор долази обичним DNS-ом пре него што клијент пошаље иједан тунелски пакет. Други је сам OpenVPN пренос, који се повезује на адресу коју је тражење дало, на оном протоколу и порту које профил наведе. Трећи се дешава након што је тунел подигнут, када апликације траже имена, а гурнута подешавања резолвера одлучују ко одговара.

Та три могу успети или отказати независно. Клијент може савршено разрешити своју крајњу тачку и ипак не стићи до слушаоца, а може и успоставити тунел док свако интерно тражење имена отказује јер DNS подешавања никада нису стигла.

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

Читајте табелу као списак за проверу, а не као опис. Ако се име крајње тачке не разреши, ништа касније не може радити и тунел никада не почиње.

Број порта не именује апликацију

Порт 53 носи DNS по конвенцији, а OpenVPN оператер може тамо да објави и слушаоца, и управо зато је тај број лоша ознака. OpenVPN сесија на UDP 53 и даље је OpenVPN сесија, а DNS упит послат серверу на порту 53 не говори ништа о томе да ли је тунел дозвољен. Редови proto и remote у профилу одређују спољну крајњу тачку; број порта сам по себи не одређује ништа.

То сече на обе стране при дијагностици: генеричка UDP сонда на порт 53 доказује да неки порт одговара, а не да одговара VPN услуга. Тестирајте правим клијентом и правим профилом, јер само то изводи руковање које услуга очекује.

Докажите слушаоца пре него што оптужите мрежу

На серверу проверите шта је везано помоћу ss -lunp | grep 53 и упоредите са протоколом и портом из профила. Из клијентове мреже покрените клијент са већом разином детаља како би запис показао коју је адресу и пренос покушао. Ако сервер слуша, а клијентови пакети не долазе, пут или правила их одбијају, и то је разговор са власником мреже, а не разлог за промену порта.

Други порт помаже само када услуга тамо заиста слуша и када то имплементација дозвољава. Премештање слушаоца да би се избегло филтрирање управљане мреже одлука је о правилима, а не корак у решавању проблема. Питајте власника мреже шта је дозвољено пре него што промените услугу, јер заобилазно решење које крши правила касније се ипак затвара. Запишите тај одговор уз профил да следећа особа не понови захтев.

Проверите DNS након тунела, одвојено

Кад је тунел подигнут, прегледајте стање резолвера на VPN интерфејсу и упитајте једно интерно и једно јавно име. Ако интерна имена отказују док тунел преноси саобраћај, гурнута DNS подешавања нису примењена, што је питање интеграције клијента, а не преноса. Ако јавна имена отказују, а интерна раде, правило подељеног тунела ради оно за шта је постављено.

Оставите DNS промене власнику резолвера. Преписивање управљане конфигурације резолвера да би један тест прошао може покварити приватна имена за све остало на рачунару. Ако тунел гура резолвер, а клијент га игнорише, поправите интеграцију клијента уместо да негде другде додате статички запис. Статички записи крију квар док неко не промени мрежу. Запишите који резолвер треба да одговара на који простор имена.

Повезани чланци