Геаграфічны 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

Запускайце сцэнарыі з прадстаўнічых сетак доступу, а не толькі з офіса, бо ўсё пытанне ў тым, да якога пункту ўваходу розныя кліенты насамрэч дабіраюцца. Адна сетка — гэта выбарка з аднаго.