Geografisk DNS och anycast: kontrollera VPN-ingången du får

Ett DNS-svar i närheten känns som ett löst problem tills anslutningen landar någon annanstans. Geografisk DNS och anycast försöker båda förkorta vägen, och de fattar beslutet utifrån olika information. Ingen av dem garanterar att ingångsporten du når är nåbar, att den presenterar den identitet din klient förväntar sig, eller att din session överlever ett nodbyte. Kontrollerna nedan skiljer de fyra frågorna.

Kontrollera vilken plats resolveraren faktiskt rapporterar

En auktoritativ server som svarar på en topologikänslig fråga ser normalt adressen till den rekursiva resolver som frågade, inte adressen till personen som skrev namnet. En centraliserad resolver kan stå långt från klienterna den betjänar, och svaret speglar resolvern och inte dem. Det är inget fel; så beter sig protokollet om inte extra information tillhandahålls. specifikationen för EDNS Client Subnet beskriver både begränsningen och den valfria åtgärden.

EDNS Client Subnet kan bära information om ursprungsnätverket när varje deltagare stöder och aktiverar det. Det är valfritt, det har konsekvenser för integritet och cachelagring, och det är inte tillstånd att anta att någon offentlig resolver rapporterar en exakt användarplats. Fråga resolveroperatörerna innan du designar kring det.

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

Kontrollera vad anycast-routningen beslutade

Med anycast annonserar flera platser nåbarhet för en tjänsteadress, och nätverket levererar varje klient till den nod som dess routning föredrar. Det valet görs av BGP och den omgivande policyn, inte av avstånd på en karta. Topologisk närhet innebär inte heller generellt bättre tur-och-retur-prestanda, eftersom vägen som ser kort ut kan vara överbelastad eller asymmetrisk. Adressen du fick säger ingenting om vilken nod som svarade.

Bekräfta den betjänande platsen från tjänstesidan, eller från ett svar som namnger den, i stället för bara från DNS-svaret. traceroute -n 198.51.100.20 visar vägen du tog och namnger fortfarande inte värden i slutet av den, så läs den som en väg och inte som ett svar.

Kontrollera att sessionen överlever ett nodbyte

En DNS-fråga är kort och en VPN-session är lång, och de två har helt olika krav på tillstånd. Routning kan förskjutas mitt i en session, och när det händer kan senare paket anlända till en nod som aldrig har sett din tunnel. Om det är överlevbart beror på implementeringen: delat tillstånd, en avsiktlig återanslutning eller ett dokumenterat fel. Adressen ensam ger inget av detta.

Observera förskjutningen i stället för att anta den. sudo tcpdump -ni any -c 20 esp visar de yttre paketen när vägen ändras, och en plötslig ändring av peeradressen är förskjutningen som sker. Definiera det avsedda beteendet explicit för den implementering du kör och testa det sedan genom att tvinga fram en vägändring. Om designen förutsätter sessionsreplikering, namnge mekanismen och namnge felet den inte täcker.

Kontrollera att identiteten fortfarande stämmer

Varje ingångspunkt måste presentera den identitet som din klientprofil förväntar sig. Ett certifikat utfärdat för tjänstenamnet fungerar över noder, medan certifikat per nod tvingar klienten att acceptera något nytt, och det är där användare lär sig att klicka sig igenom varningar. Håll den förväntade identiteten och profilen konsekventa med ingångsmodellen.

Kontrollera det från en klient som nådde en ovanlig nod, eftersom det är fallet där ett certifikat per nod blir synligt. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com skriver ut kedjan och namnen, vilket är exakt det klienten jämför. Bestäm sedan om profilen ska snävas in eller certifikatmodellen ändras.

Kontrollera posten, inte bara det första svaret

Utvärdera tre scenarier och skriv fyra fakta för varje: normal ingång, en plats otillgänglig och det överenskomna återställningsfallet. De fyra faktaen är resolvern som användes, adressen som returnerades, platsen som betjänade den och ett nytt applikationsresultat. Den posten skiljer ett DNS-valproblem från ett problem med ingångsporten, ett routningsproblem eller ett sessionstillståndsproblem. Utan den ser alla fyra identiska ut från klienten.

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

Kör scenarierna från representativa åtkomstnätverk och inte bara från kontoret, eftersom hela frågan handlar om vilken ingångspunkt olika klienter faktiskt når. Ett nätverk är ett urval av ett.