Географски DNS и anycast: проверка на влезот што го добивате

Блискиот DNS одговор изгледа како решен проблем сѐ додека врската не слета на друго место. Географскиот DNS и anycast и двата се обидуваат да ја скратат патеката, а таа одлука ја носат врз основа на различни информации. Ниту едното не гарантира дека порталот до кој стигнувате е достапен, дека го претставува идентитетот што вашиот клиент го очекува или дека вашата сесија преживува промена на јазол. Проверките подолу ги раздвојуваат тие четири прашања.

Проверете чија локација навистина ја пријавува резолверот

Авторитативен сервер што одговара на топологиски чувствително барање обично ја гледа адресата на рекурзивниот резолвер што прашал, а не адресата на лицето што го внело името. Централизиран резолвер може да стои далеку од клиентите на кои им служи, а одговорот го одразува резолверот, а не нив. Тоа не е дефект; така се однесува протоколот освен ако не се доставени дополнителни информации. Спецификацијата EDNS Client Subnet ги опишува и ограничувањето и изборното решение.

EDNS Client Subnet може да носи информации за изворната мрежа кога секој учесник го поддржува и го вклучува. Изборен е, има последици за приватноста и кеширањето и не е дозвола да се претпостави дека кој било јавен резолвер пријавува прецизна локација на корисникот. Прашајте ги операторите на резолверот пред да дизајнирате врз основа на него.

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

Проверете што одлучило anycast рутирањето

Со anycast, неколку локации рекламираат достапност за една адреса на услуга, а мрежата го доставува секој клиент до јазолот што неговото рутирање го претпочита. Таа одлука ја носат BGP и околната политика, а не растојанието на карта. Топологиската близина исто така генерално не значи подобри перформанси на повратно патување, бидејќи патеката што изгледа кратка може да биде затната или асиметрична. Адресата што ви е дадена не ви кажува ништо за тоа кој јазол одговорил.

Потврдете ја локацијата што служи од страната на услугата или од одговор што ја именува, а не само од DNS одговорот. traceroute -n 198.51.100.20 ја покажува патеката што ја поминавте и сѐ уште не го именува домаќинот на нејзиниот крај, затоа читајте ја како патека, а не како одговор.

Проверете дали сесијата преживува промена на јазол

DNS барањето е кратко, а VPN сесијата е долга и двете имаат сосема различни барања за состојба. Рутирањето може да се премести во средината на сесијата, и кога тоа ќе се случи, подоцнежните пакети може да пристигнат на јазол што никогаш не го видел вашиот тунел. Дали тоа е преживувачко зависи од имплементацијата: споделена состојба, намерно повторно поврзување или документиран неуспех. Самата адреса не дава ниту едно од тие.

Набљудувајте го преместувањето наместо да го претпоставувате. sudo tcpdump -ni any -c 20 esp ги покажува надворешните пакети како што се менува патеката, а нагла промена на адресата на партнерот е преместувањето што се случува. Дефинирајте го наменетото однесување експлицитно за имплементацијата што ја водите, потоа тестирајте го со присилување на промена на патеката. Ако дизајнот претпоставува репликација на сесијата, именувајте го механизмот и именувајте го неуспехот што тој не го покрива.

Проверете дали идентитетот сѐ уште се совпаѓа

Секоја влезна точка мора да го претстави идентитетот што го очекува вашиот клиентски профил. Сертификат издаден за името на услугата работи низ јазлите, додека сертификатите по јазол го принудуваат клиентот да прифати нешто ново, и токму таму корисниците учат да кликнуваат низ предупредувања. Чувајте го очекуваниот идентитет и профилот конзистентни со моделот на влез.

Проверете го од клиент што стигнал до необичен јазол, бидејќи тоа е случајот кога сертификатот по јазол станува видлив. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com ги печати синџирот и имињата, што е точно она што клиентот го споредува. Потоа одлучете дали профилот треба да се стесни или моделот на сертификат да се смени.

Проверете го записот, не само првиот одговор

Оценете три сценарија и запишете четири факти за секое: нормален влез, една недостапна локација и договорениот случај на обновување. Четирите факти се резолверот што се користи, адресата што се враќа, локацијата што го обслужила и свеж резултат од апликацијата. Тој запис го раздвојува проблемот со DNS изборот од проблем со порталот, проблем со рутирањето или проблем со состојбата на сесијата. Без него, сите четири изгледаат идентично од клиентот.

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

Извршете ги сценаријата од репрезентативни пристапни мрежи, а не само од канцеларијата, бидејќи целото прашање е за тоа до која влезна точка различните клиенти навистина стигнуваат. Една мрежа е примерок од еден.