Welke verbinding antwoordt: routingdomeinen voor split-tunnel-VPN-DNS

Houd gewoon browsen op de lokale verbinding terwijl bedrijfsnamen worden opgelost via de DNS-server die de tunnel levert. De standaardroute van de VPN uitzetten geeft je de eerste helft en laat de tweede ongebouwd. Wat volgt is de ontbrekende instelling, de leestekens die de betekenis veranderen, en het ene commando dat laat zien welke verbinding echt antwoordde. NetworkManager en systemd-resolved worden steeds verondersteld, omdat dat paar meestal het begin van de verwarring is.

Stap één: scheid de route van de resolver

ipv4.never-default beantwoordt een routeringsvraag en houdt NetworkManager tegen deze verbinding te installeren als de weg voor al het IPv4-verkeer. Een DNS-routingdomein beantwoordt een andere vraag: welke nameservers van welke verbinding een query voor een passend suffix ontvangen. Geen van beide impliceert de ander, en een profiel kan jarenlang het ene hebben terwijl het andere ontbreekt. Alleen route betekent dat de tunnel de bedrijfssubnetten draagt en de resolver bedrijfsnamen beantwoordt, terwijl al het andere met rust wordt gelaten.

Stel alleen de route-eigenschap in en interne namen falen, meestal met een time-out die klinkt als een kapotte tunnel. Stel alleen het domein in en je hebt stilletjes een zoeksuffix aan elke korte naam op de machine toegevoegd. Beide fouten sturen het ticket naar de VPN-server, die zelden het onderdeel is dat fout is.

Stap twee: voeg een alleen-routingdomein toe aan het profiel

Stel dat de verbinding corp-vpn heet, het bedrijfssuffix internal.example is en de resolver van de tunnel al bereikbaar is. Lees eerst de huidige waarden, want de commando's hieronder wijzigen eigenschappen die al vermeldingen kunnen bevatten.

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

Vervang door je eigen verbindingsnaam en suffix, want de waarden hierboven zijn illustratief. Het plusteken is belangrijker dan het lijkt: ermee wordt de waarde aan de bestaande lijst toegevoegd, terwijl zonder het de eigenschap wordt vervangen en niet-verwante domeinen verdwijnen uit een profiel dat gisteren nog werkte. De tilde verandert gedrag, niet stijl, en de alinea hieronder legt uit wat hij selecteert. Houd het lezen vóór het schrijven, zodat de vervangingsvorm je nooit verrast.

Een leidende tilde markeert een alleen-routingdomein, dus overeenkomende queries gaan naar de servers van deze verbinding en het suffix wordt niet aan korte namen toegevoegd. Haal de tilde weg en dezelfde tekenreeks wordt ook een zoeksuffix, een ander resultaat dat mensen zelden bedoelen. Beide instellingen hierboven zijn IPv4, dus een dual-stackprofiel heeft ipv6.never-default en hetzelfde routingdomein in ipv6.dns-search nodig, anders blijft de IPv6-kant de standaardroute gebruiken en falen interne namen daar.

Stap drie: vraag resolvectl welke verbinding antwoordde

Voer resolvectl status uit en lees de DNS-servers en domeinen van elke verbinding, voer dan resolvectl query host.internal.example uit tegen een echte interne naam die je mag bevragen. Het tweede commando is het enige directe bewijs dat het routingdomein zijn werk doet, omdat het de verbinding noemt die antwoordde. Een statuslijst alleen bewijst de configuratie; de query bewijst de resolutie.

systemd-resolved kiest het best passende routingdomein, dus een specifieker domein op een andere verbinding kan de race alsnog winnen. Komt de query terug van een verbinding die je niet verwachtte, lees dan de domeinlijsten voordat je de DNS-server van de VPN aanraakt. Een rootdomein van ~. past bij alles, en als het al aanwezig is wint je specifieke domein nog steeds voor zijn eigen namen terwijl de verbinding veel meer beantwoordt dan je vroeg. Verwijder of vernauw die rootvermelding wanneer de bedoeling alleen bedrijfsnamen was.

Als de VPN-verbinding helemaal geen DNS-server vermeldt, heeft de client er nooit een geregistreerd. Een routingdomein zonder server erachter faalt anders dan een ontbrekend domein, dus repareer eerst de registratie.

Stap vier: wanneer de naam oplost maar de dienst niet

Een correct antwoord bewijst alleen dat de resolutie werkte, en de toepassing heeft nog steeds een route naar het adres dat hij kreeg. Die route moet de zojuist geconfigureerde gesplitste standaardroute overleven, dus controleer hem voordat je DNS opnieuw de schuld geeft. Controleer daarna de bereikbaarheid op de poort van de dienst, want een bestandsshare of directorydienst faalt bij resolutie, routing of authenticatie en geeft in elk geval zeer vergelijkbare meldingen. Houd die drie lagen gescheiden wanneer je het resultaat rapporteert, anders controleert de volgende persoon DNS opnieuw dat al correct was.

De Samba-wijziging die naast deze vraag rondgaat, betreft de toegangslaag, niet de DNS-keuze. Die toepassen op een naamresolutiestoring is hoe een klein probleem een tweede krijgt.

Stap vijf: vervang de resolver niet om een ontbrekend domein te repareren

Advies dat het resolverbestand overschrijft of een andere resolverbeheerder installeert, lost een ander probleem op. Dat zijn systeemintegratiewijzigingen met hun eigen faalmodi, en geen ervan voegt een routingdomein toe dat nooit is geconfigureerd. Stel vast welke component de naamresolutie op de machine bezit voordat je hem vervangt, want op een NetworkManager-desktop met systemd-resolved is dat eigendom al gedefinieerd. Ertegen vechten is hoe een werkende opstelling iets wordt dat niemand kan reproduceren.

Werkvolgorde: bevestig dat de tunnel een resolver levert, voeg het alleen-routingdomein toe, verbind opnieuw via de profielbediening, verifieer de verbinding die antwoordt en test dan de dienst op zijn poort. Die volgorde laat een resultaat achter dat je zonder tweede gesprek aan de volgende persoon kunt overhandigen.