Како да го читате 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.