Geograafiline DNS ja anycast: saadava VPN-sisendpunkti kontrollimine

Geograafiline DNS ja anycast valivad sisendpunkte erinevate reeglite järgi. Kontrollige, millist resolverit vastus peegeldab, ja seejärel, kas seanss peab vastu sõlme vahetusele.

Lähedane DNS-vastus tundub lahendatud probleemina, kuni ühendus maandub mujal. Geograafiline DNS ja anycast püüavad mõlemad teed lühendada ning teevad selle otsuse erineva teabe põhjal. Kumbki ei taga, et lüüs, milleni jõuate, on kättesaadav, et see esitab identiteedi, mida teie klient ootab, ega seda, et teie seanss peab vastu sõlme vahetusele. Alltoodud kontrollid eraldavad need neli küsimust.

Kontrollige, kelle asukohta resolver tegelikult teatab

Autoriteetne server, mis vastab topoloogiatundlikule päringule, näeb tavaliselt küsinud rekursiivse resolveri aadressi, mitte nime sisestanud inimese aadressi. Tsentraliseeritud resolver võib asuda oma klientidest kaugel ja vastus peegeldab pigem resolverit kui neid. See ei ole defekt; nii käitub protokoll, kui lisateavet ei anta. EDNS-i kliendi alamvõrgu spetsifikatsioon kirjeldab nii piirangut kui ka valikulist lahendust.

EDNS-i kliendi alamvõrk võib kanda lähtevõrgu teavet, kui iga osaleja seda toetab ja lubab. See on valikuline, sellel on tagajärjed privaatsusele ja vahemällu salvestamisele ning see ei ole luba eeldada, et mõni avalik resolver teatab kasutaja täpse asukoha. Küsige resolverite operaatoritelt, enne kui selle ümber projekteerite.

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

Kontrollige, mida anycast-marsruutimine otsustas

Anycasti puhul kuulutavad mitmed asukohad ühe teenuseaadressi kättesaadavust ja võrk toimetab iga kliendi sõlme, mida tema marsruutimine eelistab. Selle valiku teevad BGP ja ümbritsev poliitika, mitte kaugus kaardil. Ka topoloogiline lähedus ei tähenda üldiselt paremat edasi-tagasi jõudlust, sest lühikesena näiv tee võib olla ülekoormatud või asümmeetriline. Teile antud aadress ei ütle midagi selle kohta, milline sõlm vastas.

Kinnitage teenindav asukoht teenuse poolelt või vastusest, mis selle nimetab, mitte üksnes DNS-vastusest. traceroute -n 198.51.100.20 näitab teed, mille te läbisite, ega nimeta ikkagi hosti selle lõpus, seega lugege seda teena, mitte vastusena.

Kontrollige, et seanss peab vastu sõlme vahetusele

DNS-päring on lühike ja VPN-seanss pikk ning neil on täiesti erinevad olekunõuded. Marsruutimine võib seansi keskel nihkuda ja kui see juhtub, võivad hilisemad paketid jõuda sõlme, mis ei ole teie tunnelit kunagi näinud. Kas see on üleelatav, sõltub rakendusest: jagatud olek, teadlik taasühendus või dokumenteeritud tõrge. Aadress üksi ei anna neist ühtegi.

Jälgige nihet selle asemel, et seda eeldada. sudo tcpdump -ni any -c 20 esp näitab väliseid pakette tee muutumisel ja järsk muutus partneri aadressis ongi nihe. Määratlege kavatsetud käitumine selgesõnaliselt rakendusele, mida käitate, seejärel testige seda tee muutmisele sundides. Kui disain eeldab seansi replikatsiooni, nimetage mehhanism ja nimetage tõrge, mida see ei kata.

Kontrollige, et identiteet ikka klapib

Iga sisendpunkt peab esitama identiteedi, mida teie kliendiprofiil ootab. Teenuse nime jaoks välja antud sert sobib üle sõlmede, samas kui sõlmede kaupa serdid sunnivad klienti nõustuma millegi uuega ja just seal õpivad kasutajad hoiatusi läbi klõpsama. Hoidke oodatav identiteet ja profiil sisendmudeliga kooskõlas.

Kontrollige seda kliendist, mis jõudis ebatavalise sõlmeni, sest just sel juhul muutub sõlmede kaupa sert nähtavaks. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com prindib ahela ja nimed, mis on täpselt see, mida klient võrdleb. Seejärel otsustage, kas profiili tuleks kitsendada või serdimudelit muuta.

Kontrollige kirjet, mitte ainult esimest vastust

Hinnake kolme stsenaariumi ja kirjutage igaühe kohta neli fakti: tavaline sisend, üks kättesaamatu asukoht ja kokkulepitud taastumisjuhtum. Neli fakti on kasutatud resolver, tagastatud aadress, teenindanud asukoht ja värske rakenduse tulemus. See kirje eristab DNS-i valikuprobleemi lüüsi probleemist, marsruutimisprobleemist või seansi oleku probleemist. Ilma selleta näevad kõik neli kliendi poolelt ühesugused välja.

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

Käivitage stsenaariumid esinduslikest juurdepääsuvõrkudest, mitte ainult kontorist, sest kogu küsimus on selles, millise sisendpunktini erinevad kliendid tegelikult jõuavad. Üks võrk on ühe valim.

Seotud artiklid