Twee VPN's, één resolver: wie het laatst schrijft, wint

Er zijn twee VPN-clients verbonden, één voor werk en één voor een labnetwerk, en interne namen worden alleen opgelost voor de client die als laatste verbinding maakte. Dat patroon lijkt op een bug in een van de clients. Meestal is het het voorspelbare resultaat van twee programma's die dezelfde resolverconfiguratie schrijven zonder afspraak over wie welke naam bezit.

De mythe: de nieuwste VPN bezit DNS

Er is geen algemene regel dat de nieuwste verbinding wint. Wat er gebeurt, hangt af van het platformmechanisme en van hoe elke client het schrijft. Een client die een resolverbestand vervangt, levert één uitkomst; een client die per link een domein toevoegt, een andere; een client die niets doet, laat de vorige toestand intact.

Het waargenomen gedrag is dus een eigenschap van de twee implementaties, geen gedocumenteerde prioriteit. Redeneren op basis van alleen de startvolgorde zal soms kloppen en soms fout zijn op manieren die moeilijk te reproduceren zijn. Schrijf de toewijzing op. Een ontwerp dat in twee clients leeft, is geen ontwerp.

Wijs naamruimten toe aan resolvers

Noem de privésuffixen en de resolver die elk netwerk vereist, en beslis dan waar openbare namen heen moeten. Die lijst is het ontwerp. Zonder die lijst nemen de clients de beslissing per ongeluk.

Een platform dat DNS per link of routingdomeinen ondersteunt, kan de splitsing bewust uitdrukken: het ene domein gaat naar de ene link, het andere domein naar de andere, en al het overige volgt een expliciete standaard. Twee platte scripts die hetzelfde bestand overschrijven kunnen dat ontwerp niet bewaren, omdat elk denkt de hele configuratie te bezitten.

Op Windows kan de beleidstabel voor naamresolutie suffixen naar specifieke servers sturen, en een VPN-client kan daar regels installeren. Controleer het beleid in plaats van de adapterlijst, want niet de adapterlijst lost de naam op.

Houd een bootstrap-pad aan

Elke client moet zijn eigen eindpunt vinden voordat hij de dienst kan gebruiken die dat eindpunt biedt. Als de hostnaam van het eindpunt alleen via de tunnel kan worden opgelost, en de tunnel de opgeloste hostnaam nodig heeft, heb je een cyclische afhankelijkheid die verschijnt als een verbindingstime-out. Houd één bootstrap-pad buiten beide tunnels. Het kost niets tot de dag waarop het de verbinding redt.

Kijk naar het pad naar elke resolver, niet alleen naar de naam die ervoor is geconfigureerd. Een resolver die alleen via de andere tunnel bereikbaar is, gedraagt zich als een ontbrekende, en het symptoom is een time-out in plaats van een routeringsfout.

Overlappende adressen zijn geen DNS-probleem

Twee privénetwerken met dezelfde adresreeks zijn niet te repareren met DNS-volgorde. Als beide tunnels 10.0.0.0/8 opeisen, wijst een correct opgeloste naam nog steeds naar een adres waar de host niet naar de juiste tunnel kan routeren. Dat vereist een oplossing op adresniveau, zoals aparte reeksen, een naamruimte of vertaling, niet nog een resolverinstelling. Dit vroeg beslissen voorkomt een lange omweg via een DNS-configuratie die nooit zou hebben gewerkt.

Vergelijk de adrestoewijzingen van beide tunnels voordat je de naamresolutie de schuld geeft. Wanneer beide kanten hetzelfde prefix pushen, houdt de host één route daarvoor, en een naam die via de tweede tunnel wordt opgelost, belandt toch op een adres dat de eerste tunnel bezit. Aparte reeksen, een naamruimte per netwerk of vertaling zijn de oplossingen; bevestig na elke clientverbinding dat de routetabel het pad toont dat je bedoelde.

Bewijs het met echte toepassingen

Kies twee hosts die alleen in hun eigen naamruimte bestaan en één openbare naam, en los ze vervolgens elk op via de client die ze zou moeten bezitten. Een correct antwoord van de verwachte resolver bewijst niet dat de toepassing de host bereikt, want de route naar dat adres kan nog steeds mislukken. Laat elke opzoeking volgen door een verbindingstest vanuit het programma dat de gebruiker werkelijk zal starten.

Een client met een eigen versleutelde DNS-optie kan het beleid omzeilen dat je zojuist hebt geverifieerd, dus controleer die instelling als onderdeel van de beoordeling. Verbind daarna beide clients opnieuw in de volgorde die de leverancier ondersteunt en herhaal de opzoekingen; als de antwoorden wisselen wanneer de volgorde verandert, bezit een concurrerende schrijver nog een deel van de configuratie. Zoek uit welk onderdeel de regel installeert - de client, het OS-profiel of een beheeragent - voordat je iets bewerkt. Noteer de volgorde en de eigenaren zodat de volgende persoon ze niet opnieuw hoeft te ontdekken.