Разрешете DNS само през вашия VPN резолвер: преглед стъпка по стъпка
Проследете едно търсене на име от браузъра до отговора. Вижте къде се избира резолверът, къде защитната стена го налага и какво правилото за порт 53 никога не покрива.
Проследете едно търсене на име от момента, в който го въведете. Браузърът пита операционната система, операционната система пита резолвера, който нейната политика избира, а заявката напуска устройството през някакъв интерфейс с някакъв транспорт. Вашият VPN дизайн казва, че отговорът трябва да дойде от определен резолвер по определен път. Разликата между тези две твърдения е това, което конфигурирате и после налагате.
Стъпка 1: назовете резолвера и пътя
Запишете три неща, преди да пипате защитна стена: адреса на резолвера, протокола и порта, които очаквате, и интерфейса, през който заявката трябва да излезе. Без този списък правилото е догадка за трафик, а не изпълнение на решение. VPN може да носи данни на приложения, докато DNS следва отделна уредба, и само по себе си това не е грешка. То е това, което се случва, когато никой не е казал на клиента друго.
Изричното назоваване на пътя е разликата между дизайн и случайност. То ви дава и нещо за по-късно тестване, защото всяко наблюдение може да се сравни с писмено очакване. Дръжте списъка в билета за промяната, а не в нечия глава.
Стъпка 2: задайте политиката там, където тя наистина живее
Изборът на резолвер принадлежи на клиента: мрежовата конфигурация на операционната система, собствените настройки на VPN клиента или управлявана политика на браузъра. Задайте я първо там, с механизма, който платформата поддържа, защото защитна стена не може да накара клиент да избере резолвер, за който никога не е чувал. При клиент с разделен тунел кажете изрично кои домейни отиват към вътрешния резолвер. В управляван парк политиката на браузъра често е единственият лост за DoH, защото браузърът може да избере свой шифрован резолвер независимо от системната настройка.
Пропуснете това и отидете направо на защитната стена, и получавате правило, което разрешава правилния резолвер, плюс клиент, който никога не го използва. Правилото изглежда вярно, а журналите на резолвера остават празни, което е объркваща двойка при отстраняване на проблеми. Първо конфигурирайте избора, после го наложете.
Стъпка 3: наложете пътя тясно
Сега добавете мрежовото разрешение за позволения път: адреса на резолвера, протокола и порта и интерфейса, през който трябва да излезе. Дръжте правилото ограничено до този резолвер, вместо да разрешавате целия изходящ DNS. Трите пътя по-долу са тези, по които може да тръгне модерен клиент, и само първият се покрива от правило за порт 53.
| Path | Port | Who controls it |
|---|---|---|
| Classic DNS | UDP and TCP 53 | System resolver settings |
| DNS over TLS | TCP 853 | Resolver or stub configuration |
| DNS over HTTPS | TCP 443 | Browser or application policy |
Да блокирате DoH и DoT е законно; да предполагате, че правило за порт 53 вече ги е блокирало, не е. Браузър с DoH решава имена по път, който вашето правило никога не е описвало, а приложение със собствен резолвер прави същото. Запишете всеки път, който смятате да разрешите, и всеки, който смятате да откажете. Правило, което не назовава път, не е взело решение за него.
Стъпка 4: следете частни и публични имена
Разделеният DNS умишлено изпраща само частни пространства от имена към вътрешен резолвер, докато публичните имена отиват другаде, така че повече от един резолвер в дизайна не е изтичане. Изтичането е заявка, която е трябвало да отиде към вашия резолвер, но се появява другаде, или недостъпен предвиден път, който кара клиента тихо да се върне назад. Тези два случая са това, което да търсите. Проследете вътрешно и публично име при предвидената политика и отбележете кой резолвер е отговорил на всяко.
Тестов сайт, който показва вашия резолвер, е подсказка, не доказателство, защото вижда само заявките, които са стигнали до него. Запишете заявката от страната на клиента, когато трябва да знаете кой път е поела в действителност, и сравнете двете наблюдения. Когато се разминават, сте намерили връщане назад, което никой не е документирал.
Ако адресът на резолвера е верен, но е недостъпен, проблемът е в маршрутизиране или филтриране, а не в политика. Проследете заявката до този адрес и потвърдете, че отговорът се връща през очаквания интерфейс, преди да променяте каквато и да е настройка на резолвера.
Стъпка 5: оставете път за връщане
Преди да затегнете достъпа до DNS на шлюза, потвърдете метод за възстановяване, който не зависи от решаване на имена. Счупен резолвер прави всеки инструмент за ремонт по-трудно достъпен, включително тези, с които бихте отменили промяната. Дръжте локална конзола или извънлентов път отворени, докато новата политика бъде доказана. Премахнете го едва след като политиката е преживяла повторно свързване.
След повторно свързване или обновяване на политиката на браузъра прегледайте ефективното състояние отново, защото и двете могат да сменят резолвера, без да сменят вашето правило. Изискването е известен получател и защитен път за заявките, а не успокояващ етикет на резолвер на един екран screenshot. Спецификацията RFC 8484 за DNS over HTTPS е справката за шифрования път, който вашето правило за порт не вижда.