Kva kobling svarar: rutingsdomene for split-tunnel VPN-DNS

Hald vanleg nettlesing på den lokale koblinga medan selskapsnamn blir løyste gjennom DNS-tenaren tunnelen leverer. Slår du av standardruta til VPN-en, får du fyrste halvdel og lèt andre halvdel stå ubygd. Det som følgjer, er innstillinga som manglar, teiknsetjinga som endrar tydinga, og den einaste kommandoen som viser kva kobling som faktisk svara. NetworkManager og systemd-resolved er føresett heile vegen, fordi det paret er der forvirringa vanlegvis byrjar.

Steg éin: skil ruta frå oppløysaren

ipv4.never-default svarar på eit rutingsspørsmål og hindrar NetworkManager i å installere denne tilkoplinga som vegen for all IPv4-trafikk. Eit DNS-rutingsdomene svarar på eit anna spørsmål: kva namnetenarar på kva kobling som får ei førespurnad for eit samsvarande suffiks. Ingen av dei føreset den andre, og ein profil kan bære den eine i årevis medan den andre manglar. Berre rute tyder at tunnelen ber selskapsneta og oppløysaren svarar på selskapsnamn, medan alt anna blir late i fred.

Set berre ruteeigenskapen, og interne namn feilar, vanlegvis med ein tidsavbrot som høyrest ut som ein øydelagd tunnel. Set berre domenet, og du har stille lagt til eit søkjesuffiks på kvart kortnamn på maskina. Begge feila sender saka til VPN-tenaren, som sjeldan er delen som er feil.

Steg to: legg til eit reint rutingsdomene i profilen

Anta at tilkoplinga heiter corp-vpn, at selskapsuffikset er internal.example, og at oppløysaren til tunnelen alt er tilgjengeleg. Les dei gjeldande verdiane fyrst, fordi kommandoane nedanfor endrar eigenskapar som kanskje alt har oppføringar.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

Byt ut med ditt eige tilkoplingsnamn og suffiks, fordi verdiane ovanfor er illustrative. Plussteiknet tyder meir enn det ser ut som: med det blir verdien lagd til i den eksisterande lista, medan eigenskapen utan det blir erstatta og urelaterte domene forsvinn frå ein profil som verka i går. Tilden endrar åtferd snarare enn stil, og avsnittet nedanfor dekkjer kva han vel. Hald lesinga før skrivinga, så erstatningsforma aldri overraskar deg.

Ein innleiande tilde markerer eit reint rutingsdomene, så samsvarande førespurnader går til tenarane på denne koblinga, og suffikset blir ikkje lagt til kortnamn. Fjern tilden, og same strengen blir også eit søkjesuffiks, noko som er eit anna resultat folk sjeldan ønskjer. Begge innstillingane ovanfor er IPv4, så ein dual-stack-profil treng ipv6.never-default og det same rutingsdomenet i ipv6.dns-search, elles held IPv6-sida fram med å bruke standardruta, og interne namn feilar der.

Steg tre: spør resolvectl kva kobling som svara

Køyr resolvectl status og les DNS-tenarane og domena til kvar kobling, og køyr deretter resolvectl query host.internal.example mot eit ekte internt namn du har lov til å spørje om. Den andre kommandoen er det einaste direkte provet på at rutingsdomenet gjer jobben sin, fordi han namngir koblinga som svara. Ei statusliste åleine provar konfigurasjonen; førespurnaden provar oppløysinga.

systemd-resolved vel det best samsvarande rutingsdomenet, så eit meir spesifikt domene på ei anna kobling kan framleis vinne kappløpet. Kjem førespurnaden tilbake frå ei kobling du ikkje venta, les domenelistene før du rører DNS-tenaren til VPN-en. Eit rotdomene som ~. samsvarar med alt, og viss det alt finst, vinn det spesifikke domenet ditt framleis for sine eigne namn medan koblinga svarar på mykje meir enn du bad om. Fjern eller snevra inn den rotoppføringa når hensikta berre var selskapsnamn.

Viss VPN-koblinga ikkje listar opp nokon DNS-tenar i det heile, har klienten aldri registrert ein. Eit rutingsdomene utan tenar bak seg feilar annleis enn eit manglande domene, så reparer registreringa fyrst.

Steg fire: når namnet blir løyst, men tenesta ikkje

Eit riktig svar provar berre at oppløysinga verka, og applikasjonen treng framleis ei rute til adressa han fekk. Den ruta må overleve den delte standardruta du nettopp konfigurerte, så sjekk henne før du igjen gir DNS skulda. Sjekk deretter tilgjenge på porten til tenesta, fordi ei filutdeling eller ein katalogteneste feilar på oppløysing, ruting eller autentisering og gir svært like meldingar i kvart tilfelle. Hald dei tre laga frå kvarandre når du rapporterer resultatet, elles sjekkar neste person DNS på nytt som alt var riktig.

Samba-endringa som sirkulerer saman med dette spørsmålet, gjeld tilgangslaget, ikkje DNS-valet. Å bruke henne på ein namneoppløysingsfeil er korleis eit lite problem får endå eit.

Steg fem: ikkje byt ut oppløysaren for å rette eit manglande domene

Råd som skriv over oppløysarfilen eller installerer ein annan oppløysarhandsamar, løyser eit anna problem. Det er systemintegrasjonsendringar med sine eigne feilmodusar, og ingen av dei legg til eit rutingsdomene som aldri vart konfigurert. Fastslå kva komponent som eig namneoppløysinga på maskina før du byter han ut, fordi på ein NetworkManager-skrivebord med systemd-resolved er det eigarskapet alt definert. Å kjempe mot det er korleis eit fungerande oppsett blir noko ingen kan gjenskape.

Arbeidsrekkjefølgje: stadfest at tunnelen leverer ein oppløysar, legg til det reine rutingsdomenet, kople til på nytt via kontrollane i profilen, verifiser koblinga som svarar, og test deretter tenesta på porten. Den rekkjefølgja lèt etter seg eit resultat du kan overlevere til neste person utan ein ny samtale.