Hoe om VPN-DNS-roetering per skakel uit resolvectl te lees
resolvectl status wys die bedieners, domeine en die verstekroete per skakel. Lees hulle saam, vra dan die naam op en let op watter skakel geantwoord het.
Voer resolvectl status uit en jy kry 'n muur van per-skakel-blokke, elk met sy eie bedieners en sy eie domeinlyn. Die lyn wat roetering bepaal, is die domeinlys, nie die adres van die naambediener nie, want die plaaslike stut stuur elke navraag na watter skakel ook al die naam opeis. Lees daardie eise voordat jy die antwoord lees, vra dan die naam op en kyk watter skakel dit gelewer het. 'n Verkeerde antwoord van die regte skakel is 'n ander probleem as 'n regte antwoord van die verkeerde een.
Wat elke per-skakel-blok jou vertel
Elke blok lys die bedieners wat die oplosser vir daardie koppelvlak sal gebruik, die domeinlys en of die skakel die verstekroete is. Die domeinlys is 'n stel eise, en die oplosser pas die langste-agtervoegsel-ooreenkoms toe: 'n navraag vir host.corp.example word opgeeis deur 'n skakel met corp.example voor een wat net die verstekroete het. Twee skakels wat dieselfde agtervoegsel opeis, laat die uitkoms aan prioriteit en ordening oor, daarom verdien duplikate eerste aandag. Die huidige bedienerlyn wys watter van die gelyste bedieners op daardie oomblik in gebruik is.
'n Stutadres soos 127.0.0.53 in /etc/resolv.conf se net dat die stut vooraan is. Dit noem nie die opstroom wat geantwoord het nie, daarom loop 'n diagnose wat net op resolv.conf berus, vas.
Lees die drie soorte domeininskrywings korrek
| Inskrywing | Wat dit opeis | Gewone fout |
|---|---|---|
| corp.example | roeteringsdomein en soek-agtervoegsel: name daaronder gaan na hierdie skakel, en die string word by kaal name aangeheg | verwyder omdat roetering tog blyk te werk |
| ~corp.example | net-roete: name daaronder gaan na hierdie skakel, maar die agtervoegsel word nie aangeheg nie | aanvaar dat dit vir roetering nodig is |
| ~. | verstekroete: eis navrae wat geen ander skakel pas nie | aktief gelaat op 'n gesplete profiel, sodat openbare name deur die tonnel volg |
Die tilde verander soekgedrag, nie roetering nie. 'n Inskrywing sonder 'n tilde is beide 'n roeteringsdomein en 'n soekdomein, so name daaronder word na daardie skakel gestuur en enkel-etiket-name kry die agtervoegsel aangeheg. 'n Tilde-inskrywing roeteer dieselfde agtervoegsel terwyl dit uit die soeklys gehou word. Daarom verander die verwydering van 'n tilde watter kaal name oplos, en daarom is 'n ontbrekende tilde 'n soekprobleem eerder as 'n gesplete-DNS-fout.
Die verstekroete-inskrywing eis alles wat geen ander skakel pas nie. 'n Voltonnel-profiel wil dit gewoonlik he en 'n gesplete profiel gewoonlik nie, want openbare name reis dan na die private oplosser en kan daar misluk. Lees die tabel teen die profiel se bedoeling eerder as om vlae tussen profiele te kopieer. Wanneer twee skakels dieselfde agtervoegsel opeis, besleg die prioriteitsvraag voordat jy iets anders wysig.
Vra 'n naam op en sien watter skakel geantwoord het
Die query-subopdrag druk die adres, die protokol en die skakel of omvang wat die antwoord gelewer het. Toets een naam wat deur die private agtervoegsel geeis behoort te word en een gewone openbare naam, en vergelyk dan die gerapporteerde bronne. As die private naam van die draadlose skakel antwoord, ontbreek die eis of is die tonnel af; as 'n openbare naam op 'n gesplete profiel van die tonnel antwoord, is die verstekroete te breed. Daardie twee foute lyk identies in 'n blaaier en teenoorgesteld in hierdie uitset.
resolvectl status
resolvectl query host.corp.exampleLet ook op die gerapporteerde protokol, want 'n gekaste antwoord of een uit die gasheerlêer kan opdaag sonder dat enige opstroom geraadpleeg is. 'n Antwoord uit die kas bewys dat die naam op een of ander tydstip opgelos het, nie dat die huidige beleid dit korrek roeteer nie.
Hou naamroetering apart van pakketroetering
'n Oplosserbesluit skep nie 'n pad nie. Die gekose bediener het steeds 'n roete na sy adres nodig, en die teruggekeerde adres het steeds 'n roete in die private netwerk nodig, so 'n korrekte DNS-beleid kan saambestaan met 'n verbinding wat nooit oopmaak nie. Wanneer 'n naam oplos en die toepassing misluk, ondersoek die adres en die roete eerder as om DNS weer te verander. Naamoplossing en bereikbaarheid is twee vrae met twee verskillende eienaars.
Toepassings kan die stelseloplosser heeltemal omseil deur hul eie veilige DNS-instelling of 'n meegeleverde oplosser. Die resolvectl-uitslag beskryf die stelselpad, en 'n blaaier wat dit ignoreer, sal met elke toets wat jy doen verskil. Kontroleer daardie instelling voordat jy tot die gevolgtrekking kom dat die beleid stukkend is.
Teken die adres aan waarna die naam opgelos het, saam met die skakel. 'n Korrekte naam wat na die verkeerde adres wys, is 'n rekordprobleem eerder as 'n roeteringsprobleem.
Kontroleer weer nadat die skakel verander het
'n Herverbinding of 'n draadlose oorskakeling bou skakeltoestand weer op, en 'n netwerkbestuurder kan sy domeine en bedieners oor enigiets wat met die hand gestel is, herinstalleer. Vra daarna dieselfde twee name op en vergelyk met die aangetekende basislyn. As 'n handmatige wysiging verdwyn het, hoort die regstelling in die verbindingsprofiel eerder as in 'n opdrag in die terminaal. Om voor en na aan te teken, is wat dit sigbaar maak.
Deel net die name en bedienerkonteks wat die verslag nodig het, want interne agtervoegsels onthul topologie. Die systemd-resolved-dokumentasie oor domeinroetering dek die langste-ooreenkoms-reel en die tilde-gedrag, en as jy dit een keer lees, verhoed dit die meeste van die tabelle se foute hierbo: systemd-resolved-navraagroetering.