Как да четем маршрутизирането на VPN DNS за всяка връзка от изхода на resolvectl
resolvectl status показва сървъри, домейни и маршрута по подразбиране за всяка връзка. Четете ги заедно, после заявете името и отбележете коя връзка е отговорила.
Изпълнете resolvectl status и получавате стена от блокове за всяка връзка, всеки със свои сървъри и свой ред за домейни. Редът, който решава маршрутизирането, е списъкът с домейни, а не адресът на сървъра за имена, защото локалната подставка препраща всяка заявка към връзката, която претендира името. Прочетете тези претенции, преди да четете отговора, после заявете името и проверете коя връзка го е създала. Грешен отговор от правилната връзка е различен проблем от правилен отговор от грешната.
Какво ви казва всеки блок за връзка
Всеки блок изброява сървърите, които резолверът ще използва за този интерфейс, списъка с домейни и дали връзката е маршрутът по подразбиране. Списъкът с домейни е набор от претенции и резолверът прилага съвпадение по най-дълъг суфикс: заявка за host.corp.example се претендира от връзка с corp.example преди такава само с маршрута по подразбиране. Две връзки, претендиращи един и същ суфикс, оставят изхода на приоритет и подредба, затова дубликатите заслужават внимание първи. Текущият ред на сървъра показва кой от изброените сървъри се използва в този момент.
Адрес на подставка като 127.0.0.53 в /etc/resolv.conf казва само, че подставката е отпред. Той не назовава горния поток, който е отговорил, затова диагностика само по resolv.conf зацикля.
Четете трите вида записи за домейн правилно
| Запис | Какво претендира | Обичайна грешка |
|---|---|---|
| corp.example | домейн за маршрутизиране и суфикс за търсене: имената под него отиват към тази връзка, а низът се добавя към голите имена | премахнат, защото маршрутизирането уж работи |
| ~corp.example | само маршрут: имената под него отиват към тази връзка, но суфиксът не се добавя | приема се, че е нужен за маршрутизирането |
| ~. | маршрут по подразбиране: претендира заявки, които никоя друга връзка не покрива | оставен активен в разделен профил, така че публичните имена минават през тунела |
Тилдата променя поведението при търсене, а не маршрутизирането. Запис без тилда е едновременно домейн за маршрутизиране и домейн за търсене, затова имената под него се изпращат към тази връзка и към едносегментните имена се добавя суфиксът. Запис с тилда маршрутизира същия суфикс, но го държи извън списъка за търсене. Затова премахването на тилда променя кои голи имена се разпознават и затова липсващата тилда е проблем с търсенето, а не отказ на разделен DNS.
Записът за маршрута по подразбиране претендира всичко, което никоя друга връзка не покрива. Профилът с пълен тунел обикновено го иска, а разделеният обикновено не, защото публичните имена тогава пътуват до частния резолвер и могат да се провалят там. Четете таблицата спрямо намерението на профила, вместо да копирате флагове между профили. Когато две връзки претендират един суфикс, решете въпроса с приоритета, преди да редактирате друго.
Заявете име и вижте коя връзка е отговорила
Подкомандата query отпечатва адреса, протокола и връзката или обхвата, които са създали отговора. Тествайте едно име, което трябва да бъде претендирано от частния суфикс, и едно обикновено публично име, после сравнете отчетените източници. Ако частното име отговаря от безжичната връзка, претенцията липсва или тунелът е спрян; ако публично име в разделен профил отговаря от тунела, маршрутът по подразбиране е твърде широк. Тези два отказа изглеждат еднакво в браузър и противоположно в този изход.
resolvectl status
resolvectl query host.corp.exampleНаблюдавайте и отчетения протокол, защото кеширан отговор или такъв от файла на хостовете може да дойде без никакво запитване до горен поток. Отговор от кеша доказва, че името се е разпознало някога, а не че текущата политика го маршрутизира правилно.
Пазете маршрутизирането на имена отделно от маршрутизирането на пакети
Решението на резолвера не създава път. Избраният сървър все още се нуждае от маршрут до своя адрес, а върнатият адрес все още се нуждае от маршрут към частната мрежа, така че правилна DNS политика може да съществува заедно с връзка, която никога не се отваря. Когато име се разпознае, а приложението се провали, прегледайте адреса и маршрута, вместо да сменяте DNS отново. Разпознаването на имена и достижимостта са два въпроса с двама различни собственици.
Приложенията могат напълно да заобиколят системния резолвер чрез собствена настройка за защитен DNS или вграден резолвер. Резултатът от resolvectl описва системния път и браузър, който го игнорира, ще е в разрез с всеки ваш тест. Проверете тази настройка, преди да заключите, че политиката е счупена.
Запишете адреса, до който се разпозна името, заедно с връзката. Правилно име, сочещо към грешен адрес, е проблем със записа, а не с маршрутизирането.
Проверете отново след промяна на връзката
Повторно свързване или смяна на безжична мрежа преизгражда състоянието на връзката и мрежовият мениджър може да преинсталира своите домейни и сървъри върху всичко зададено на ръка. Заявете същите две имена след това и сравнете със записаната базова линия. Ако ръчна редакция е изчезнала, поправката е в профила на връзката а не в команда на обвивката. Записът преди и след е това, което прави разликата видима.
Споделяйте само имената и контекста на сървърите, които докладът изисква, защото вътрешните суфикси разкриват топология. Документацията на systemd-resolved за маршрутизиране на домейни покрива правилото за най-дълго съвпадение и поведението на тилдата и едно прочитане предотвратява повечето грешки от таблицата по-горе: маршрутизиране на заявки в systemd-resolved.