Vilken anslutning svarar: routningsdomäner för split-tunnel-VPN-DNS

Behåll vanlig surfning på den lokala anslutningen medan företagsnamn löses via DNS-servern som tunneln tillhandahåller. Stänger du av VPN:ns standardrutt får du första halvan och lämnar andra halvan obyggd. Det som följer är inställningen som saknas, skiljetecknet som ändrar dess betydelse och det enda kommandot som visar vilken anslutning som faktiskt svarade. NetworkManager och systemd-resolved förutsätts hela vägen, eftersom det paret är där förvirringen vanligtvis börjar.

Steg ett: separera rutten från resolvern

ipv4.never-default besvarar en routningsfråga och hindrar NetworkManager från att installera den här anslutningen som vägen för all IPv4-trafik. En DNS-routningsdomän besvarar en annan fråga: vilken anslutnings namnservrar som tar emot en fråga för ett matchande suffix. Ingen av dem förutsätter den andra, och en profil kan bära den ena i åratal medan den andra saknas. Bara rutt betyder att tunneln bär företagets subnät och att dess resolver svarar på företagsnamn, medan allt annat lämnas ifred.

Sätt bara rutt-egenskapen och interna namn misslyckas, vanligtvis med en timeout som låter som en trasig tunnel. Sätt bara domänen och du har tyst lagt till ett söksuffix på varje kort namn på maskinen. Båda felen skickar ärendet till VPN-servern, som sällan är delen som är fel.

Steg två: lägg till en ren routningsdomän i profilen

Anta att anslutningen heter corp-vpn, att företagets suffix är internal.example och att tunnelns resolver redan går att nå. Läs de aktuella värdena först, eftersom kommandona nedan ändrar egenskaper som kanske redan har poster.

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 mot ditt eget anslutningsnamn och suffix, eftersom värdena ovan är illustrativa. Plustecknet betyder mer än det ser ut som: med det läggs värdet till i den befintliga listan, medan egenskapen utan det ersätts och orelaterade domäner försvinner från en profil som fungerade igår. Tilden ändrar beteende snarare än stil, och stycket nedan förklarar vad den väljer. Behåll läsningen före skrivningen, så att ersättningsformen aldrig överraskar dig.

En inledande tilde markerar en ren routningsdomän, så matchande frågor går till den här anslutningens servrar och suffixet läggs inte till på korta namn. Ta bort tilden och samma sträng blir också ett söksuffix, ett annat resultat som folk sällan avser. Båda inställningarna ovan är IPv4, så en dual-stack-profil behöver ipv6.never-default och samma routningsdomän i ipv6.dns-search, annars fortsätter IPv6-sidan att använda standardrutten och interna namn misslyckas där.

Steg tre: fråga resolvectl vilken anslutning som svarade

Kör resolvectl status och läs varje anslutnings DNS-servrar och domäner, kör sedan resolvectl query host.internal.example mot ett verkligt internt namn som du får fråga om. Det andra kommandot är det enda direkta beviset på att routningsdomänen gör sitt jobb, eftersom det namnger anslutningen som svarade. En statuslista ensam bevisar konfigurationen; frågan bevisar upplösningen.

systemd-resolved väljer den bäst matchande routningsdomänen, så en mer specifik domän på en annan anslutning kan fortfarande vinna kapplöpningen. Om frågan kommer tillbaka från en anslutning du inte väntade dig, läs domänlistorna innan du rör VPN:ns DNS-server. En rotdomän som ~. matchar allt, och om den redan finns vinner din specifika domän ändå för sina egna namn medan anslutningen svarar på mycket mer än du bad om. Ta bort eller snäva in den rotposten när avsikten bara var företagsnamn.

Om VPN-anslutningen inte listar någon DNS-server alls har klienten aldrig registrerat någon. En routningsdomän utan server bakom sig misslyckas annorlunda än en saknad domän, så reparera registreringen först.

Steg fyra: när namnet löses men tjänsten inte

Ett korrekt svar bevisar bara att upplösningen fungerade, och programmet behöver fortfarande en rutt till adressen det fick. Den rutten måste överleva den delade standardrutt du just konfigurerade, så kontrollera den innan du skyller på DNS igen. Kontrollera sedan nåbarheten på tjänstens port, eftersom en filutdelning eller katalogtjänst misslyckas vid upplösning, routning eller autentisering och ger mycket liknande meddelanden i varje fall. Håll de tre lagren åtskilda när du rapporterar resultatet, annars kontrollerar nästa person DNS igen som redan var korrekt.

Samba-ändringen som cirkulerar vid sidan av den här frågan gäller åtkomstlagret, inte DNS-valet. Att tillämpa den på ett namnmpplösningsfel är hur ett litet problem får ett andra.

Steg fem: byt inte ut resolvern för att reparera en saknad domän

Råd som skriver över resolverfilen eller installerar en annan resolverhanterare löser ett annat problem. Det är systemintegrationsändringar med sina egna fellägen, och ingen av dem lägger till en routningsdomän som aldrig konfigurerades. Fastställ vilken komponent som äger namnmpplösningen på maskinen innan du byter ut den, eftersom på ett NetworkManager-skrivbord med systemd-resolved är det ägarskapet redan definierat. Att kämpa mot det är hur en fungerande setup blir något ingen kan återskapa.

Arbetsordning: bekräfta att tunneln tillhandahåller en resolver, lägg till den rena routningsdomänen, återanslut via profilens kontroller, verifiera anslutningen som svarar och testa sedan tjänsten på dess port. Den ordningen lämnar ett resultat du kan lämna över till nästa person utan ett nytt samtal.