OpenVPN на порце 53: тры размовы, якія людзі блытаюць
Пошук імені канчатковага пункта, зашыфраваны транспарт і DNS пасля тунэля — гэта тры асобныя размовы. Вызначце, які этап не спрацаваў, перш чым змяняць порт або рэзалвер.
Справаздачы пра тое, што VPN заблакаваны на порце 53, змешваюць тры назіранні, якія не спрацоўваюць па розных прычынах. Пошук імені канчатковага пункта адбываецца да таго, як існуе хоць які-небудзь тунэль, зашыфраваны транспарт — гэта асобная размова, а DNS-запыты, зробленыя пасля, — трэцяя. Кожнае з іх мае свой подпіс адмовы, і толькі адно з іх наогул пра DNS.
Сартуйце пакеты па прызначэнні, перш чым нешта змяняць, бо выпраўленне ідзе за этапам.
Тры размовы, адзін нумар порта
Першая размова — гэта пошук імені для канчатковага пункта: ваша машына пытаецца ў настроенага рэзалвера, дзе знаходзіцца vpn.example.com, і гэты адказ прыходзіць праз звычайны DNS яшчэ да таго, як кліент адправіць хоць адзін пакет тунэля. Другая — гэта сам транспарт OpenVPN, які падключаецца да адраса, атрыманага ў выніку пошуку, па тым пратаколе і порце, якія ўказвае профіль. Трэцяя адбываецца пасля ўзняцця тунэля, калі праграмы запытваюць імёны і перададзеныя налады рэзалвера вырашаюць, хто адказвае.
Гэтыя тры могуць паспяхова ці няўдачна завяршацца незалежна. Кліент можа ідэальна вызначыць свой канчатковы пункт і ўсё ж не дасягнуць слухача, а таксама можа ўстанавіць тунэль, пакуль кожны ўнутраны пошук імені не спрацоўвае, бо налады DNS так і не прыйшлі.
| 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 |
Чытайце табліцу як кантрольны спіс, а не як апісанне. Калі імя канчатковага пункта не вызначаецца, нічога далейшага не можа працаваць, і тунэль ніколі не пачнецца.
Нумар порта не называе праграму
Порт 53 традыцыйна нясе DNS, і аператар OpenVPN таксама можа апублікаваць там слухача, менавіта таму нумар дрэнна ідэнтыфікуе. Сеанс OpenVPN на UDP 53 застаецца сеансам OpenVPN, а DNS-запыт да сервера на порце 53 нічога не кажа пра тое, ці дазволены тунэль. Радкі proto і remote у профілі вызначаюць знешні канчатковы пункт; нумар порта сам па сабе нічога не вызначае.
Гэта рэжа ў абодва бакі пры дыягностыцы: звычайны UDP-зонд на порт 53 даказвае, што порт адказвае, а не што служба VPN адказвае. Тэстуйце сапраўдным кліентам і сапраўдным профілем, бо толькі гэта практыкуе тое рукапацісканне, якога чакае служба.
Дакажыце існаванне слухача, перш чым вінаваціць сетку
На серверы пацвердзіце, што звязана, з дапамогай ss -lunp | grep 53 і параўнайце з пратаколам і портам профілю. З сеткі кліента запусціце кліент з вышэйшай шматслоўнасцю, каб журнал паказваў, да якога адраса і транспарту ён спрабаваў далучыцца. Калі сервер слухае, а пакеты кліента не прыходзяць, шлях або палітыка адмаўляюць іх, і гэта размова для ўладальніка сеткі, а не прычына змяняць парты.
Іншы порт дапамагае толькі тады, калі служба сапраўды слухае там і разгортванне гэта дазваляе. Перамяшчэнне слухача, каб пазбегнуць фільтравання кіраванай сеткі, — гэта рашэнне аб палітыцы, а не крок пошуку няспраўнасцей. Спытайце ўладальніка сеткі, што дазволена, перш чым змяняць службу, бо абыходнае рашэнне, якое парушае палітыку, усё роўна потым зачыняць. Запішыце гэты адказ побач з профілем, каб наступны чалавек не паўтараў запыт.
Праверце DNS пасля тунэля, асобна
Пасля ўзняцця тунэля агледзіце стан рэзалвера на інтэрфейсе VPN і запытайце адно ўнутранае імя і адно публічнае. Калі ўнутраныя імёны не спрацоўваюць, пакуль тунэль нясе трафік, перададзеныя налады DNS не былі ўжытыя, і гэта пытанне інтэграцыі кліента, а не транспарту. Калі публічныя імёны не спрацоўваюць, а ўнутраныя працуюць, палітыка раздзеленага тунэля робіць тое, для чаго была наладжана.
Трымайце змены DNS у ўладальніка рэзалвера. Перазапіс кіраванай канфігурацыі рэзалвера, каб прайшоў адзін тэст, можа зламаць прыватныя імёны для ўсяго астатняга на машыне. Калі тунэль перадае рэзалвер, а кліент ігнаруе яго, папраўце інтэграцыю кліента, а не дадавайце статычны запіс у іншым месцы. Статычныя запісы хаваюць адмову, пакуль нехта не зменіць сетку. Запішыце, які рэзалвер павінен адказваць за кожную прастору імёнаў.