Földrajzi DNS és anycast: a kapott VPN-belépés ellenőrzése
A földrajzi DNS és az anycast különböző szabályok szerint választ belépési pontokat. Ellenőrizze, melyik feloldót tükrözi a válasz, majd hogy a munkamenet túléli-e a csomópontváltást.
Egy közeli DNS-válasz megoldott problémának tűnik, amíg a kapcsolat máshol nem landol. A földrajzi DNS és az anycast is lerövidíteni próbálja az útvonalat, és ezt a döntést különböző információkból hozzák. Egyik sem garantálja, hogy az átjáró, amelyet elér, elérhető, hogy azt a személyazonosságot mutatja, amelyet az ügyfele elvár, vagy hogy a munkamenete túléli a csomópontváltást. Az alábbi ellenőrzések választják szét ezt a négy kérdést.
Ellenőrizze, kinek a helyét jelenti valójában a feloldó
A topológiára érzékeny lekérdezést megválaszoló hiteles kiszolgáló általában a kérdező rekurzív feloldó címét látja, nem annak a személynek a címét, aki beírta a nevet. Egy központosított feloldó távol lehet az általa kiszolgált ügyfelektől, és a válasz a feloldót tükrözi, nem őket. Ez nem hiba; így viselkedik a protokoll, hacsak nem adnak meg további információt. Az EDNS ügyfélalhálózat specifikációja leírja a korlátot és a választható megoldást is.
Az EDNS ügyfélalhálózat hordozhatja a forráshálózat információit, ha minden résztvevő támogatja és engedélyezi. Választható, következményei vannak az adatvédelemre és a gyorsítótárazásra, és nem jogosít fel arra, hogy bármely nyilvános feloldó pontos felhasználói helyet jelentsen. Kérdezze meg a feloldók üzemeltetőit, mielőtt erre épít.
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
Ellenőrizze, mit döntött az anycast útválasztás
Az anycastnál több hely hirdeti egy szolgáltatási cím elérhetőségét, és a hálózat minden ügyfelet ahhoz a csomóponthoz juttat el, amelyet az útválasztása előnyben részesít. Ezt a választást a BGP és a környező szabályzat hozza, nem a térképen mért távolság. A topológiai közelség sem jelent általában jobb oda-vissza teljesítményt, mert a rövidnek tűnő útvonal lehet túlterhelt vagy aszimmetrikus. A kapott cím semmit sem mond arról, melyik csomópont válaszolt.
Erősítse meg a kiszolgálási helyet a szolgáltatás oldaláról, vagy olyan válaszból, amely megnevezi, nem csak a DNS-válaszból. traceroute -n 198.51.100.20 megmutatja a megtett útvonalat, és még mindig nem nevezi meg a hosztot a végén, ezért útvonalként olvassa, nem válaszként.
Ellenőrizze, hogy a munkamenet túléli a csomópontváltást
A DNS-lekérdezés rövid, a VPN-munkamenet hosszú, és a kettő állapotigénye teljesen eltér. Az útválasztás elmozdulhat a munkamenet közepén, és amikor ez megtörténik, a későbbi csomagok olyan csomóponthoz érkezhetnek, amely soha nem látta az alagútját. Hogy ez túlélhető-e, a megvalósítástól függ: megosztott állapot, szándékos újracsatlakozás vagy dokumentált hiba. A cím önmagában ezek egyikét sem adja.
Figyelje meg az elmozdulást ahelyett, hogy feltételezné. sudo tcpdump -ni any -c 20 esp mutatja a külső csomagokat, ahogy az útvonal változik, és a partner címének hirtelen változása maga az elmozdulás. Határozza meg kifejezetten a szándékolt viselkedést a futtatott megvalósításhoz, majd tesztelje útvonalváltozás kikényszerítésével. Ha a tervezés munkamenet-replikációt feltételez, nevezze meg a mechanizmust és a hibát, amelyet nem fed le.
Ellenőrizze, hogy a személyazonosság még mindig egyezik
Minden belépési pontnak azt a személyazonosságot kell bemutatnia, amelyet az ügyfélprofilja elvár. A szolgáltatás nevére kiállított tanúsítvány csomópontokon át működik, míg a csomópontonkénti tanúsítványok arra kényszerítik az ügyfelet, hogy valami újat fogadjon el, és itt tanulják meg a felhasználók, hogy átkattintsanak a figyelmeztetéseken. Tartsa az elvárt személyazonosságot és a profilt összhangban a belépési modellel.
Ellenőrizze egy olyan ügyféltől, amely szokatlan csomóponthoz ért el, mert ez az az eset, amikor a csomópontonkénti tanúsítvány láthatóvá válik. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com kiírja a láncot és a neveket, ami pontosan az, amit az ügyfél összehasonlít. Ezután döntse el, hogy a profilt szűkíteni kell-e, vagy a tanúsítványmodellt módosítani.
Ellenőrizze a feljegyzést, ne csak az első választ
Értékeljen három forgatókönyvet, és írjon négy tényt mindegyikhez: normál belépés, egy elérhetetlen hely, és a megbeszélt helyreállítási eset. A négy tény a használt feloldó, a visszaadott cím, a kiszolgáló hely és egy friss alkalmazáseredmény. Ez a feljegyzés elválasztja a DNS-kiválasztás problémáját az átjáró, az útválasztás vagy a munkamenet-állapot problémájától. Enélkül mind a négy azonosnak látszik az ügyfél oldaláról.
dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health
Futtassa a forgatókönyveket reprezentatív hozzáférési hálózatokból, ne csak az irodából, mert az egész kérdés az, hogy a különböző ügyfelek valójában melyik belépési pontot érik el. Egy hálózat egy mintája egynek.