Två VPN:er, en resolver: den som skrev sist vinner

Två VPN-klienter är anslutna, en för arbete och en för ett laboratorienätverk, och interna namn löses bara för den klient som anslöt sist. Mönstret ser ut som en bugg i en av klienterna. Vanligtvis är det det förutsägbara resultatet av två program som skriver samma resolverkonfiguration utan överenskommelse om vem som äger vilket namn.

Myten: den nyaste VPN:en äger DNS

Det finns ingen generell regel att den senaste anslutningen vinner. Vad som händer beror på plattformsmekanismen och på hur varje klient skriver den. En klient som ersätter en resolverfil ger ett resultat; en klient som lägger till en domän per länk ger ett annat; en klient som inte gör något lämnar det tidigare tillståndet intakt.

Det observerade beteendet är alltså en egenskap hos de två implementationerna, inte en dokumenterad prioritet. Att resonera kring det bara utifrån startordningen blir ibland rätt och ibland fel på sätt som är svåra att reproducera. Skriv ner mappningen i stället. En design som lever i två klienter är inte en design.

Koppla namnrymder till resolvers

Lista de privata suffixen och den resolver som varje nätverk kräver, och bestäm sedan vart offentliga namn ska gå. Den listan är designen. Utan den fattar klienterna beslutet av misstag.

En plattform som stöder DNS per länk eller routningsdomäner kan uttrycka uppdelningen medvetet: en domän går till en länk, en annan domän till den andra, och allt annat följer en uttrycklig standard. Två platta skript som skriver över samma fil kan inte bevara den designen, eftersom var och en tror att den äger hela konfigurationen.

På Windows kan tabellen för namnmatchning styra suffix till specifika servrar, och en VPN-klient kan installera regler där. Kontrollera policyn i stället för adapterlistan, eftersom det inte är adapterlistan som löser namnet.

Håll en bootstrap-väg

Varje klient måste hitta sin egen slutpunkt innan den kan använda tjänsten som slutpunkten erbjuder. Om slutpunktens värdnamn bara kan lösas genom tunneln, och tunneln behöver det lösta värdnamnet, har du ett cirkulärt beroende som visar sig som en anslutningstimeout. Håll en bootstrap-väg utanför båda tunnlarna. Den kostar inget förrän den dagen den räddar anslutningen.

Titta på vägen till varje resolver, inte bara namnet som är konfigurerat för den. En resolver som bara nås genom den andra tunneln beter sig som en som saknas, och symptomet är en timeout i stället för ett routningsfel.

Överlappande adresser är inte ett DNS-problem

Två privata nätverk med samma adressområde kan inte åtgärdas med DNS-ordning. Om båda tunnlarna gör anspråk på 10.0.0.0/8 pekar ett korrekt löst namn fortfarande på en adress som värden inte kan routa till rätt tunnel. Det kräver en lösning på adressnivå, som separata områden, en namnrymd eller översättning, inte ännu en resolverinställning. Att avgöra detta tidigt förhindrar en lång omväg genom en DNS-konfiguration som aldrig skulle ha fungerat.

Jämför adresstilldelningarna för båda tunnlarna innan du skyller på namnmatchningen. När båda sidorna trycker på samma prefix behåller värden en enda rutt för det, och ett namn som löses genom den andra tunneln hamnar ändå på en adress som den första tunneln äger. Separata områden, en namnrymd per nätverk eller översättning är rättelserna; efter att varje klient anslutit, bekräfta att routingtabellen visar den väg du avsåg.

Bevisa det med riktiga program

Välj två värdar som bara finns i sin egen namnrymd och ett offentligt namn, och lös sedan var och en genom den klient som borde äga den. Ett korrekt svar från den förväntade resolvern bevisar inte att programmet når värden, eftersom vägen till den adressen fortfarande kan misslyckas. Följ varje uppslagning med ett anslutningstest från det program som användaren faktiskt kommer att köra.

En klient med eget krypterat DNS-alternativ kan kringgå policyn du just verifierade, så kontrollera den inställningen som en del av granskningen. Återanslut sedan båda klienterna i den ordning leverantören stöder och upprepa uppslagningarna; om svaren byter plats när ordningen ändras äger en konkurrerande skribent fortfarande en del av konfigurationen. Ta reda på vilken komponent som installerar regeln - klienten, OS-profilen eller en hanteringsagent - innan du redigerar något. Anteckna ordningen och ägarna så att nästa person inte behöver upptäcka dem igen.