Så här läser du VPN-DNS-routning per anslutning från resolvectl
resolvectl status visar servrar, domäner och standardvägen per anslutning. Läs dem tillsammans, fråga sedan efter namnet och notera vilken anslutning som svarade.
Kör resolvectl status och du får en vägg av block per anslutning, var och en med egna servrar och egen domänrad. Raden som avgör routningen är domänlistan, inte namneserverns adress, eftersom den lokala stubben vidarebefordrar varje fråga till den anslutning som gör anspråk på namnet. Läs dessa anspråk innan du läser svaret, fråga sedan efter namnet och kontrollera vilken anslutning som skapade det. Ett felaktigt svar från rätt anslutning är ett annat problem än ett korrekt svar från fel anslutning.
Vad varje block per anslutning berättar
Varje block listar de servrar som resolvern använder för det gränssnittet, domänlistan och om anslutningen är standardvägen. Domänlistan är en mängd anspråk, och resolvern tillämpar matchning på längsta suffix: en fråga om host.corp.example görs anspråk på av en anslutning med corp.example före en som bara har standardvägen. Två anslutningar som gör anspråk på samma suffix lämnar resultatet till prioritet och ordning, därför förtjänar dubbletter uppmärksamhet först. Raden för aktuell server visar vilken av de listade servrarna som används i det ögonblicket.
En stubadress som 127.0.0.53 i /etc/resolv.conf säger bara att stubben står framför. Den namnger inte uppströmskällan som svarade, därför stannar en diagnos som bara bygger på resolv.conf.
Läs de tre typerna av domänposter korrekt
| Post | Vad den gör anspråk på | Vanligt fel |
|---|---|---|
| corp.example | routningsdomän och söksuffix: namn under den går till den här anslutningen, och strängen läggs till nakna namn | borttagen eftersom routningen verkar fungera ändå |
| ~corp.example | endast väg: namn under den går till den här anslutningen, men suffixet läggs inte till | antogs vara nödvändig för routningen |
| ~. | standardväg: gör anspråk på frågor som ingen annan anslutning täcker | lämnad aktiv på en delad profil, så offentliga namn följer tunneln |
Tilden ändrar sökbeteendet, inte routningen. En post utan tilde är både routningsdomän och sökdomän, så namn under den skickas till den anslutningen och namn med en enda etikett får suffixet tillagt. En tilde-post routar samma suffix men håller det utanför söklistan. Därför ändrar borttagandet av en tilde vilka nakna namn som löses, och därför är en saknad tilde ett sökproblem och inte ett fel i delad DNS.
Posten för standardvägen gör anspråk på allt som ingen annan anslutning täcker. En fulltunnelprofil vill oftast ha den och en delad profil oftast inte, eftersom offentliga namn då reser till den privata resolvern och kan misslyckas där. Läs tabellen mot profilens avsikt i stället för att kopiera flaggor mellan profiler. När två anslutningar gör anspråk på samma suffix, avgör prioritetsfrågan innan du redigerar något annat.
Fråga efter ett namn och se vilken anslutning som svarade
Underkommandot query skriver ut adressen, protokollet och den anslutning eller det omfång som skapade svaret. Testa ett namn som det privata suffixet bör göra anspråk på och ett vanligt offentligt namn, jämför sedan de rapporterade källorna. Om det privata namnet svarar från den trådlösa anslutningen saknas anspråket eller så är tunneln nere; om ett offentligt namn på en delad profil svarar från tunneln är standardvägen för bred. Dessa två fel ser likadana ut i en webbläsare och motsatta i denna utdata.
resolvectl status
resolvectl query host.corp.exampleHåll också koll på det rapporterade protokollet, eftersom ett cachat svar eller ett svar från hosts-filen kan komma utan att någon uppström tillfrågas. Ett svar från cachen bevisar att namnet löstes någon gång, inte att den nuvarande policyn routar det korrekt.
Håll namnroutning åtskild från paketroutning
Ett resolverbeslut skapar ingen väg. Den valda servern behöver fortfarande en väg till sin adress, och den returnerade adressen behöver fortfarande en väg in i det privata nätet, så en korrekt DNS-policy kan samexistera med en anslutning som aldrig öppnas. När ett namn löses och programmet misslyckas, undersök adressen och vägen i stället för att ändra DNS igen. Namnuppslagning och nåbarhet är två frågor med två olika ägare.
Program kan kringgå systemresolvern helt genom sin egen inställning för säker DNS eller en inbyggd resolver. resolvectl-resultatet beskriver systemvägen, och en webbläsare som ignorerar det kommer att vara oenig med varje test du gör. Kontrollera den inställningen innan du drar slutsatsen att policyn är trasig.
Anteckna adressen som namnet löstes till bredvid anslutningen. Ett korrekt namn som pekar på fel adress är ett postproblem och inte ett routningsproblem.
Kontrollera igen efter att anslutningen har ändrats
En återanslutning eller ett trådlöst byte bygger upp anslutningens tillstånd på nytt, och en nätverkshanterare kan installera om sina domäner och servrar över allt som satts för hand. Fråga sedan efter samma två namn och jämför med den registrerade baslinjen. Om en manuell ändring har försvunnit, hör rättelsen hemma i anslutningsprofilen och inte i ett skalkommando. Det är registreringen före och efter som gör det synligt.
Dela bara de namn och det serverkontext som rapporten behöver, eftersom interna suffix avslöjar topologin. systemd-resolved-dokumentationen om domänroutning täcker regeln om längsta matchning och tildens beteende, och en genomläsning förhindrar de flesta tabellfel ovan: frågeroutning i systemd-resolved.