Hvilken kobling svarer: rutingsdomener for split-tunnel VPN-DNS

Hold vanlig nettlesing på den lokale koblingen mens selskapsnavn løses gjennom DNS-serveren tunnelen leverer. Slår du av VPN-ens standardrute, får du første halvdel og lar andre halvdel stå ubygd. Det som følger, er innstillingen som mangler, tegnsettingen som endrer betydningen, og den ene kommandoen som viser hvilken kobling som faktisk svarte. NetworkManager og systemd-resolved forutsettes hele veien, fordi det paret er der forvirringen vanligvis starter.

Trinn én: skill ruten fra oppløseren

ipv4.never-default svarer på et rutingsspørsmål og hindrer NetworkManager i å installere denne tilkoblingen som veien for all IPv4-trafikk. Et DNS-rutingsdomene svarer på et annet spørsmål: hvilken koblings navneservere som mottar en forespørsel for et samsvarende suffiks. Ingen av dem forutsetter den andre, og en profil kan bære den ene i årevis mens den mangler den andre. Bare rute betyr at tunnelen bærer selskapets subnett og oppløseren svarer på selskapsnavn, mens alt annet lates i fred.

Sett bare ruteegenskapen, og interne navn feiler, vanligvis med en tidsavbrudd som høres ut som en ødelagt tunnel. Sett bare domenet, og du har stille lagt til et søkesuffiks på hvert kortnavn på maskinen. Begge feilene sender saken til VPN-serveren, som sjelden er delen som er feil.

Trinn to: legg til et rent rutingsdomene i profilen

Anta at tilkoblingen heter corp-vpn, at selskapssuffikset er internal.example, og at tunnelens oppløser allerede er tilgjengelig. Les gjeldende verdier først, fordi kommandoene nedenfor endrer egenskaper som kanskje allerede har oppføringer.

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

Bytt ut med ditt eget tilkoblingsnavn og suffiks, fordi verdiene ovenfor er illustrerende. Plusstegnet betyr mer enn det ser ut som: med det legges verdien til i den eksisterende listen, mens egenskapen uten det erstattes og urelaterte domener forsvinner fra en profil som virket i går. Tilden endrer atferd snarere enn stil, og avsnittet nedenfor dekker hva den velger. Behold lesingen før skrivingen, så erstatningsformen aldri overrasker deg.

En innledende tilde markerer et rent rutingsdomene, så samsvarende forespørsler går til denne koblingens servere, og suffikset legges ikke til kortnavn. Fjern tilden, og samme streng blir også et søkesuffiks, noe som er et annet resultat folk sjelden ønsker. Begge innstillingene ovenfor er IPv4, så en dual-stack-profil trenger ipv6.never-default og det samme rutingsdomenet i ipv6.dns-search, ellers fortsetter IPv6-siden å bruke standardruten, og interne navn feiler der.

Trinn tre: spør resolvectl hvilken kobling som svarte

Kjør resolvectl status og les hver koblings DNS-servere og domener, og kjør deretter resolvectl query host.internal.example mot et ekte internt navn du har lov til å spørre om. Den andre kommandoen er det eneste direkte beviset på at rutingsdomenet gjør jobben sin, fordi den navngir koblingen som svarte. En statusliste alene beviser konfigurasjonen; spørringen beviser oppløsningen.

systemd-resolved velger det best samsvarende rutingsdomenet, så et mer spesifikt domene på en annen kobling kan fortsatt vinne kappløpet. Hvis spørringen kommer tilbake fra en kobling du ikke forventet, les domenelistene før du rører VPN-ens DNS-server. Et rotdomene som ~. samsvarer med alt, og hvis det allerede finnes, vinner det spesifikke domenet ditt fortsatt for sine egne navn mens koblingen svarer på mye mer enn du ba om. Fjern eller snevre inn den rottoppføringen når hensikten bare var selskapsnavn.

Hvis VPN-koblingen ikke lister opp noen DNS-server i det hele tatt, har klienten aldri registrert en. Et rutingsdomene uten server bak seg feiler annerledes enn et manglende domene, så reparer registreringen først.

Trinn fire: når navnet løses, men tjenesten ikke

Et riktig svar beviser bare at oppløsningen virket, og applikasjonen trenger fortsatt en rute til adressen den fikk. Den ruten må overleve den delte standardruten du nettopp konfigurerte, så sjekk den før du igjen gir DNS skylden. Sjekk deretter tilgjengeligheten på tjenestens port, fordi en filutdeling eller katalogtjeneste feiler på oppløsning, ruting eller autentisering og gir svært like meldinger i hvert tilfelle. Hold de tre lagene atskilt når du rapporterer resultatet, ellers sjekker neste person DNS på nytt som allerede var riktig.

Samba-endringen som sirkulerer sammen med dette spørsmålet, gjelder tilgangslaget, ikke DNS-valget. Å bruke den på en navneoppløsningsfeil er hvordan et lite problem får enda et.

Trinn fem: ikke bytt ut oppløseren for å rette et manglende domene

Råd som overskriver oppløserfilen eller installerer en annen oppløserbehandler, løser et annet problem. Det er systemintegrasjonsendringer med sine egne feilmoduser, og ingen av dem legger til et rutingsdomene som aldri ble konfigurert. Fastslå hvilken komponent som eier navneoppløsningen på maskinen før du bytter den ut, fordi på et NetworkManager-skrivebord med systemd-resolved er det eierskapet allerede definert. Å kjempe mot det er hvordan et fungerende oppsett blir noe ingen kan gjenskape.

Arbeidsrekkefølge: bekreft at tunnelen leverer en oppløser, legg til det rene rutingsdomenet, koble til på nytt via profilens kontroller, verifiser koblingen som svarer, og test deretter tjenesten på porten. Den rekkefølgen etterlater et resultat du kan overlevere til neste person uten en ny samtale.