Дозволете 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 на портата, потврдете метод за враќање што не зависи од решавање имиња. Расипан резолвер го отежнува пристапот до секоја алатка за поправка, вклучително и тие со кои би ја вратиле промената. Држете локална конзола или пат надвор од опсегот отворен додека не се докаже новата политика. Отстранете го само откако политиката ќе издржи повторно поврзување.
По повторно поврзување или ажурирање на политиката на прелистувачот, повторно проверете ја ефективната состојба, бидејќи двете можат да го сменат резолверот без да го сменат вашето правило. Барањето е познат примач и заштитен пат за барањата, а не утешна ознака за резолвер на една слика од екранот. Спецификацијата RFC 8484 за DNS over HTTPS е референцата за шифрираниот пат што вашето правило за порта не го гледа.