Geografický DNS a anycast: kontrola VPN vstupního bodu, který dostanete

Geografický DNS a anycast volí vstupní body podle různých pravidel. Zkontrolujte, který překladač odpověď odráží, a potom zda relace přežije změnu uzlu.

Blízká odpověď DNS vypadá jako vyřešený problém, dokud spojení nepřistane jinde. Geografický DNS i anycast se snaží zkrátit cestu a toto rozhodnutí činí z různých informací. Ani jedno nezaručuje, že brána, na kterou se dostanete, je dostupná, že představuje identitu, kterou váš klient očekává, ani že vaše relace přežije změnu uzlu. Následující kontroly tyto čtyři otázky oddělují.

Zkontrolujte, čí polohu překladač skutečně hlásí

Autoritativní server, který odpovídá na dotaz citlivý na topologii, obvykle vidí adresu rekurzivního překladače, který se ptal, nikoli adresu člověka, který jméno napsal. Centralizovaný překladač může sídlit daleko od klientů, kterým slouží, a odpověď odráží překladač, nikoli je. To není vada; tak se protokol chová, pokud se nedodají další informace. Specifikace klientské podsítě EDNS popisuje jak omezení, tak volitelné řešení.

Rozšíření klientské podsítě EDNS může nést informace o zdrojové síti, když je každý účastník podporuje a zapne. Je volitelné, má důsledky pro soukromí a kešování a není oprávněním předpokládat, že kterýkoli veřejný překladač hlásí přesnou polohu uživatele. Ptejte se provozovatelů překladačů, než na tom postavíte návrh.

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

Zkontrolujte, co rozhodlo směrování anycast

U anycast několik lokalit inzeruje dostupnost pro jednu adresu služby a síť doručí každého klienta tomu uzlu, kterému jeho směrování dává přednost. Tuto volbu činí BGP a okolní politika, nikoli vzdálenost na mapě. Ani topologická blízkost obvykle neznamená lepší výkon tam a zpět, protože cesta, která vypadá krátce, může být přetížená nebo asymetrická. Adresa, kterou jste dostali, neříká nic o tom, který uzel odpověděl.

Potvrďte lokalitu obsluhy ze strany služby nebo z odpovědi, která ji pojmenuje, ne jen z odpovědi DNS. traceroute -n 198.51.100.20 ukazuje cestu, kterou jste šli, a přesto nepojmenuje hostitele na jejím konci, takže ji čtěte jako cestu, nikoli jako odpověď.

Zkontrolujte, že relace přežije změnu uzlu

Dotaz DNS je krátký a relace VPN dlouhá a oba mají zcela odlišné nároky na stav. Směrování se může uprostřed relace posunout, a když se to stane, pozdější pakety mohou dorazit k uzlu, který váš tunel nikdy neviděl. Zda je to přežitelné, závisí na implementaci: sdílený stav, záměrné opětovné připojení nebo dokumentované selhání. Samotná adresa nedodá nic z toho.

Posun pozorujte, místo abyste ho předpokládali. sudo tcpdump -ni any -c 20 esp ukazuje vnější pakety, jak se cesta mění, a náhlá změna adresy protějšku je právě ten posun. Výslovně definujte zamýšlené chování pro implementaci, kterou provozujete, a pak ho otestujte vynucenou změnou cesty. Pokud návrh předpokládá replikaci relace, pojmenujte mechanismus a pojmenujte selhání, které nepokrývá.

Zkontrolujte, že identita stále odpovídá

Každý vstupní bod musí představit identitu, kterou váš klientský profil očekává. Certifikát vydaný pro jméno služby funguje napříč uzly, zatímco certifikáty pro jednotlivé uzly nutí klienta přijmout něco nového, a právě tam se uživatelé učí proklikat varování. Udržujte očekávanou identitu a profil v souladu s modelem vstupu.

Zkontrolujte to z klienta, který se dostal na neobvyklý uzel, protože to je případ, kdy se certifikát pro jednotlivý uzel stane viditelným. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com vypíše řetězec a jména, což je přesně to, co klient porovnává. Poté rozhodněte, zda se má profil zúžit, nebo změnit model certifikátu.

Zkontrolujte záznam, ne jen první odpověď

Vyhodnoťte tři scénáře a pro každý zapište čtyři fakta: běžný vstup, jedna nedostupná lokalita a dohodnutý případ obnovy. Čtyři fakta jsou použitý překladač, vrácená adresa, lokalita, která obsluhovala, a čerstvý výsledek aplikace. Tento záznam odděluje problém volby DNS od problému brány, problému směrování nebo problému stavu relace. Bez něj vypadají všechny čtyři z klientské strany stejně.

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

Spouštějte scénáře z reprezentativních přístupových sítí, ne jen z kanceláře, protože celá otázka je o tom, ke kterému vstupnímu bodu se různí klienti skutečně dostanou. Jedna síť je vzorek jednoho.

Související články