Географски DNS и аникаст: проверка на входната точка на VPN, която получавате

Близък отговор от DNS изглежда като решен проблем, докато връзката не се озове другаде. Географският DNS и аникастът и двата се опитват да скъсят пътя и вземат това решение от различна информация. Нито едно от тях не гарантира, че шлюзът, до който стигате, е достъпен, че представя самоличността, която клиентът ви очаква, или че сесията ви оцелява при смяна на възел. Проверките по-долу разделят тези четири въпроса.

Проверете чие местоположение всъщност съобщава резолверът

Авторитетен сървър, който отговаря на чувствителна към топологията заявка, обикновено вижда адреса на рекурсивния резолвер, който е попитал, а не адреса на човека, който е въвел името. Централизиран резолвер може да стои далеч от клиентите, които обслужва, и отговорът отразява резолвера, а не тях. Това не е дефект; така се държи протоколът, освен ако не се подаде допълнителна информация. Спецификацията на клиентската подмрежа в EDNS описва както ограничението, така и незадължителното решение.

Разширението за клиентска подмрежа в EDNS може да носи информация за мрежата на произход, когато всеки участник го поддържа и включи. То е незадължително, има последици за поверителността и кеширането и не е разрешение да се предполага, че който и да е публичен резолвер съобщава точно местоположение на потребителя. Попитайте операторите на резолвери, преди да проектирате около него.

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

Проверете какво е решила маршрутизацията на аникаста

При аникаст няколко местоположения обявяват достижимост за един адрес на услуга и мрежата доставя всеки клиент до възела, който маршрутизацията му предпочита. Този избор се прави от 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

Изпълнявайте сценариите от представителни мрежи за достъп, а не само от офиса, защото целият въпрос е коя входна точка достигат различните клиенти в действителност. Една мрежа е извадка от една.