Hvilket link svarer: routingdomæner til split-tunnel VPN-DNS

Hold almindelig browsing på det lokale link, mens virksomhedsnavne slås op via den DNS-server, tunnelen leverer. Slår du VPN'ens standardrute fra, får du den første halvdel og efterlader den anden ubygget. Det følgende er den manglende indstilling, den tegnsætning der ændrer dens betydning, og den ene kommando, der viser, hvilket link der faktisk svarede. NetworkManager og systemd-resolved forudsættes hele vejen, fordi det par er, hvor forvirringen normalt starter.

Trin et: adskil ruten fra resolveren

ipv4.never-default besvarer et routingspørgsmål og forhindrer NetworkManager i at installere denne forbindelse som vejen for al IPv4-trafik. Et DNS-routingdomæne besvarer et andet spørgsmål: hvilket links navneservere der modtager en forespørgsel for et matchende suffiks. Ingen af dem forudsætter den anden, og en profil kan bære den ene i årevis, mens den mangler den anden. Kun-rute betyder, at tunnelen bærer virksomhedens subnets, og dens resolver besvarer virksomhedsnavne, mens alt andet lades i fred.

Sæt kun ruteegenskaben, og interne navne fejler, normalt med en timeout der lyder som en brudt tunnel. Sæt kun domænet, og du har stille tilføjet et søgesuffiks til hvert kort navn på maskinen. Begge fejl sender sagen til VPN-serveren, som sjældent er den del, der er forkert.

Trin to: tilføj et kun-routing-domæne til profilen

Antag, at forbindelsen hedder corp-vpn, at virksomhedens suffiks er internal.example, og at tunnelens resolver allerede kan nås. Læs de nuværende værdier først, fordi kommandoerne nedenfor ændrer egenskaber, der måske allerede 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

Indsæt dit eget forbindelsesnavn og suffiks, fordi værdierne ovenfor er illustrative. Plustegnet betyder mere, end det ser ud: med det tilføjes værdien til den eksisterende liste, mens egenskaben uden det erstattes, og urelaterede domæner forsvinder fra en profil, der virkede i går. Tilden ændrer adfærd snarere end stil, og afsnittet nedenfor dækker, hvad den vælger. Behold læsningen før skrivningen, så erstatningsformen aldrig overrasker dig.

En indledende tilde markerer et kun-routing-domæne, så matchende forespørgsler går til dette links servere, og suffikset tilføjes ikke til korte navne. Fjern tilden, og den samme streng bliver også et søgesuffiks, hvilket er et andet resultat, som folk sjældent ønsker. Begge indstillinger ovenfor er IPv4, så en dual-stack-profil kræver ipv6.never-default og det samme routingdomæne i ipv6.dns-search, ellers fortsætter IPv6-siden med at bruge standardruten, og interne navne fejler der.

Trin tre: spørg resolvectl, hvilket link der svarede

Kør resolvectl status og læs hvert links DNS-servere og domæner, og kør derefter resolvectl query host.internal.example mod et rigtigt internt navn, du har tilladelse til at forespørge. Den anden kommando er det eneste direkte bevis på, at routingdomænet gør sit arbejde, fordi den navngiver det link, der svarede. En statusliste alene beviser konfiguration; forespørgslen beviser opslag.

systemd-resolved vælger det bedst matchende routingdomæne, så et mere specifikt domæne på et andet link kan stadig vinde kapløbet. Hvis forespørgslen kommer tilbage fra et link, du ikke forventede, så læs domænelisterne, før du rører VPN'ens DNS-server. Et roddomæne som ~. matcher alt, og hvis det allerede findes, vinder dit specifikke domæne stadig for sine egne navne, mens linket svarer på meget mere, end du bad om. Fjern eller indsnævr den rodpost, når hensigten kun var virksomhedsnavne.

Hvis VPN-linket slet ikke angiver nogen DNS-server, har klienten aldrig registreret en. Et routingdomæne uden server bag sig fejler anderledes end et manglende domæne, så ret registreringen først.

Trin fire: når navnet slås op, men tjenesten ikke virker

Et korrekt svar beviser kun, at opslaget virkede, og programmet har stadig brug for en rute til den adresse, det fik. Den rute skal overleve den delte standardrute, du lige har konfigureret, så tjek den, før du igen bebrejder DNS. Tjek derefter tilgængelighed på tjenestens port, fordi en filshare eller katalogtjeneste fejler på opslag, routing eller godkendelse og giver meget ens meddelelser i hvert tilfælde. Hold de tre lag adskilt, når du rapporterer resultatet, ellers tjekker den næste person DNS igen, som allerede var korrekt.

Den Samba-ændring, der cirkulerer sammen med dette spørgsmål, handler om adgangslaget, ikke DNS-valget. At anvende den på en fejl i navneopslag er, hvordan et lille problem får endnu et.

Trin fem: erstat ikke resolveren for at rette et manglende domæne

Råd, der overskriver resolverfilen eller installerer en anden resolvermanager, løser et andet problem. Det er systemintegrationsændringer med deres egne fejltilstande, og ingen af dem tilføjer et routingdomæne, der aldrig blev konfigureret. Fastslå, hvilken komponent der ejer navneopslag på maskinen, før du erstatter den, fordi ejerskabet på en NetworkManager-skrivebord med systemd-resolved allerede er defineret. At kæmpe imod det er, hvordan et fungerende setup bliver til noget, ingen kan gengive.

Arbejdsrækkefølge: bekræft, at tunnelen leverer en resolver, tilføj kun-routing-domænet, genopret forbindelsen via profilens kontroller, verificér det svarne link, og test derefter tjenesten på dens port. Den rækkefølge efterlader et resultat, du kan give videre til den næste person uden en ny samtale.