Како читати рутирање VPN DNS-а по вези из resolvectl
resolvectl status приказује сервере, домене и подразумевану путању по вези. Прочитајте их заједно, затим питајте за име и забележите која веза је одговорила.
Покрените resolvectl status и добијате зид блокова по вези, сваки са својим серверима и својим редом домена. Ред који одлучује о рутирању је листа домена, а не адреса сервера имена, јер локални stub прослеђује сваки упит оној вези која полаже право на име. Прочитајте те тврдње пре него што прочитате одговор, затим питајте за име и проверите која веза га је произвела. Погрешан одговор са праве везе је други проблем од тачног одговора са погрешне.
Шта вам говори сваки блок по вези
Сваки блок наводи сервере које ће резолвер користити за тај интерфејс, листу домена и да ли је веза подразумевана путања. Листа домена је скуп тврдњи, а резолвер примењује подударање најдужег суфикса: упит за host.corp.example полаже веза која носи corp.example пре оне која носи само подразумевану путању. Две везе које полажу право на исти суфикс остављају исход приоритету и редоследу, зато дупликати заслужују пажњу први. Ред тренутног сервера показује који је од наведених сервера у употреби у том тренутку.
Stub адреса као 127.0.0.53 у /etc/resolv.conf каже само да је stub напред. Не именује горњи ток који је одговорио, зато дијагноза заснована само на resolv.conf застаје.
Правилно прочитајте три врсте записа домена
| Запис | На шта полаже право | Уобичајена грешка |
|---|---|---|
| corp.example | домен рутирања и суфикс претраге: имена испод њега иду на ову везу, а низ се додаје голим именима | уклоњен јер рутирање ионако изгледа да ради |
| ~corp.example | само путања: имена испод њега иду на ову везу, али суфикс се не додаје | претпостављено да је потребан за рутирање |
| ~. | подразумевана путања: полаже право на упите које ниједна друга веза не покрива | остављен активан на подељеном профилу, па јавна имена прате тунел |
Тилда мења понашање претраге, не рутирање. Запис без тилде је и домен рутирања и домен претраге, зато се имена испод њега шаљу на ту везу и именима са једном етикетом додаје се суфикс. Запис са тилдом рутира исти суфикс, али га држи изван листе претраге. Зато уклањање тилде мења која се гола имена разрешавају, и зато тилда која недостаје је проблем претраге, а не отказ подељеног DNS-а.
Запис подразумеване путање полаже право на све што ниједна друга веза не покрива. Профил пуног тунела обично га жели, а подељени профил обично не, јер јавна имена тада путују до приватног резолвера и могу тамо да откажу. Читајте табелу према намери профила, уместо да копирате заставице између профила. Када две везе полажу право на исти суфикс, решите питање приоритета пре него што уредите било шта друго.
Питајте за име и видећете која веза је одговорила
Поткоманда query штампа адресу, протокол и везу или опсег који су произвели одговор. Тестирајте једно име које треба да полаже приватни суфикс и једно обично јавно име, затим упоредите пријављене изворе. Ако приватно име одговара са бежичне везе, тврдња недостаје или је тунел доле; ако јавно име на подељеном профилу одговара из тунела, подразумевана путања је преширока. Ова два отказа изгледају исто у прегледачу, а супротно у овом излазу.
resolvectl status
resolvectl query host.corp.exampleПратите и пријављени протокол, јер одговор из кеша или из hosts датотеке може да стигне без питања било ког горњег тока. Одговор из кеша доказује да се име некада разрешило, а не да га тренутна политика исправно рутира.
Држите рутирање имена одвојено од рутирања пакета
Одлука резолвера не ствара пут. Изабрани сервер и даље треба путању до своје адресе, а враћена адреса и даље треба путању у приватну мрежу, па исправна DNS политика може постојати уз везу која се никада не отвара. Када се име разреши, а апликација откаже, прегледајте адресу и путању уместо да поново мењате DNS. Разрешавање имена и доступност су два питања са два различита власника.
Апликације могу потпуно заобићи системски резолвер кроз сопствено подешавање безбедног DNS-а или уграђени резолвер. Резултат resolvectl описује системску путању, а прегледач који га игнорише разилазиће се са сваким вашим тестом. Проверите то подешавање пре него што закључите да је политика сломљена.
Запишите адресу на коју се име разрешило поред везе. Тачно име које показује на погрешну адресу је проблем записа, а не рутирања.
Проверите поново након што се веза промени
Поновно повезивање или промена бежичне мреже поново гради стање везе, а мрежни менаџер може поново да инсталира своје домене и сервере преко свега што је постављено ручно. Затим питајте за иста два имена и упоредите са забележеном основном линијом. Ако је ручна измена нестала, исправка припада профилу везе а не команди у шкољци. Управо записивање пре и после чини то видљивим.
Делите само имена и контекст сервера који су потребни извештају, јер унутрашњи суфикси откривају топологију. Документација systemd-resolved о рутирању домена покрива правило најдужег подударања и понашање тилде, и једно читање спречава већину грешака из табеле горе: рутирање упита у systemd-resolved.