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 при собственика на резолвера. Презаписването на управлявана конфигурация на резолвер, за да мине един тест, може да счупи частните имена за всичко останало на машината. Ако тунелът изпраща резолвер, а клиентът го игнорира, поправете интеграцията на клиента, вместо да добавяте статичен запис някъде другаде. Статичните записи скриват отказа, докато някой не смени мрежата. Запишете кой резолвер се очаква да отговаря за всяко именно пространство.