Използва ли се наистина 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

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

Защо страницата за изтичане доказва по-малко, отколкото изглежда

Това, което показва страницата за тест на изтичане, е резолверът, който е говорил с оператора на теста, а не този, който вашата машина е попитала. Локален форуърдър, който рекурсира навън, слага своя изходен адрес на тази страница, а криптираните заявки могат да оставят страницата напълно празна. И двата резултата се разчитат погрешно, единият като изтичане, другият като гаранция, и нито едно от двете четения не следва от наблюдението.

Защитимото доказателство е прихващането: интерфейс, адрес на дестинация, отговор и времева марка. Направете едно преди тунелът да се вдигне и едно след това и ги сравнете следващия път, когато име се провали. Тази двойка казва и на следващия човек дали повредата е била в разпознаването, маршрутизацията или в собствената политика за достъп на резолвера.