Дали DNS-от на вашиот VPN навистина се користи? Фатете порта 53 и погледнете

Прашајте ги повеќето луѓе што прави VPN клиент со DNS и тие ќе речат дека го поставува решавачот, па барањата патуваат внатре во тунелот. Туркањето е вистинско; претпоставката дека тоа станува барање не е. Помеѓу турена опција и пакет на жицата стојат три фази, и секоја пропаѓа независно на начини што сите изгледаат како расипан DNS сервер. Затоа страницата за тест на истекување и работен прелистувач можат да се разидат околу истиот компјутер во истиот момент.

Турената опција не е барање

Првата фаза е серверот да нуди поставки, на пример турена DNS опција што именува решавач внатре во тунелот. Втората фаза е клиентот да ги примени тие поставки на интерфејс. Третата фаза е апликацијата навистина да испрати барање до таа адреса. Неуспехот во втората фаза ја остава опцијата видлива во дневникот на врската додека списокот со решавачи останува непроменет, а неуспехот во третата фаза остава сосема точен список со решавачи неискористен.

Повеќето отстранување на дефекти ги спојува тие три во едно и го обвинува VPN серверот, кој обично е единствената страна што може да докаже дека го сторила својот дел. Наместо тоа прочитајте ја вистинската состојба на решавачот на клиентот, потоа гледајте како едно барање излегува. Тие две набљудувања ја делат конфигурацијата од рутирањето и од политиката, и чинат околу пет минути. Чувајте ги снимките, зашто следниот инженер го сака пред и потоа, а не нивниот опис.

Проверете што навистина држи интерфејсот

На Linux системскиот решавач може да биде обичната датотека, NetworkManager или systemd-resolved, и тоа кој од нив го поседува одлучува каде ќе слета турен сервер. Процесот OpenVPN од командната линија сам не го ажурира системскиот решавач, па документираната интеграција е up/down скрипта или менаџер за врски што веќе знае како да ги примени поставките. Пуштањето и двете е ефикасен начин да создадете трка.

resolvectl status
cat /etc/resolv.conf

На Windows списокот е по адаптер, па тунелскиот адаптер може да ги држи внатрешните сервери додека физичкиот адаптер ги задржува локалните и победува за некои имиња. Споредете ги двата адаптери наместо тој што претпоставувате дека е активен.

Следете едно барање надвор од машината

Снимете ги двете интерфејси истовремено, потоа решете едно име што треба да го користи внатрешниот решавач. Тој пар снимки одговара на она на што не може да одговори ниту еден излез од конфигурацијата.

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

Барање што се појавува на физичкиот интерфејс и никогаш во тунелот значи дека клиентот избрал погрешен решавач. Барање што не се појавува на ниту еден од двата значи дека апликацијата одговорила од кешот, прашала stub што слуша на loopback, или користела шифриран решавач чиј сообраќај никогаш не се појавува како порта 53. Снимете ги и одговорите, не само барањата, зашто барање што излегува низ тунелот со одговор од јавна адреса е друг дефект од воопшто нестигнување на одговор.

Огнениот ѕид што прифаќа само сопствен DNS

Комерцијалните клиенти понекогаш инсталираат свои филтерски синџири. Еден документиран образец дозволува DNS до сопствениот решавач на клиентот и го фрла целиот останат UDP сообраќај на порта 53 што се обидува да излезе од интерфејс што не е loopback, вклучително сообраќај што корисникот намерно го рутирал на друго место. Барањата на демонот исчезнуваат без трага, што се чита како дефект на решавачот, а не како филтер.

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

Ако правило за фрлање се оценува пред вашето исклучок, додаденото правило никогаш не се достигнува, затоа вметнете го на првата позиција и ограничете ја дестинацијата на решавачот што навистина го мислите.

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

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

Зошто страницата за истекување докажува помалку отколку што изгледа

Она што го покажува страницата за тест на истекување е решавачот што зборувал со операторот на тестот, не тој што го консултирала вашата машина. Локалниот препраќач што рекурзира нанадвор ја става својата излезна адреса на таа страница, а шифрираните барања можат да ја остават страницата сосема празна. Двата резултати се читаат погрешно, едниот како истекување а другиот како гаранција, и ниту едно читање не произлегува од набљудувањето.

Одбранливиот доказ е снимката: интерфејс, целна адреса, одговор и временска ознака. Земете една пред тунелот да се подигне и една потоа, и споредете ги следниот пат кога некое име ќе пропадне. Тој пар му кажува и на следниот човек дали дефектот бил во решавањето, рутирањето или во сопствената политика за пристап на решавачот.