Heograpikong DNS at anycast: pagsusuri sa VPN entry na nakukuha mo

Ang malapit na sagot ng DNS ay parang lutas na problema hanggang sa mapunta ang koneksyon sa ibang lugar. Sinusubukan ng heograpikong DNS at anycast na paikliin ang landas, at ginagawa nila ang desisyong iyon mula sa magkaibang impormasyon. Wala sa kanila ang sinisiguro na naaabot ang gateway na narating mo, na ipinapakita nito ang pagkakakilanlang inaasahan ng iyong kliyente, o na nakakaligtas ang iyong sesyon sa pagbabago ng node. Hinihiwalay ng mga pagsusuri sa ibaba ang apat na tanong na iyon.

Suriin kung kaninong lokasyon ang aktwal na iniuulat ng resolver

Ang awtoritatibong server na sumasagot sa isang query na sensitibo sa topolohiya ay karaniwang nakikita ang address ng recursive resolver na nagtanong, hindi ang address ng taong nag-type ng pangalan. Ang sentralisadong resolver ay maaaring nasa malayo sa mga kliyenteng pinaglilingkuran nito, at ang sagot ay sumasalamin sa resolver at hindi sa kanila. Iyon ay hindi depekto; ganoon ang pag-uugali ng protocol maliban kung may ibinigay na karagdagang impormasyon. Ang espesipikasyon ng EDNS Client Subnet ay naglalarawan ng parehong limitasyon at opsyonal na lunas.

Ang EDNS Client Subnet ay maaaring magdala ng impormasyon ng pinagmulang network kapag sinusuportahan at pinagana ito ng bawat kalahok. Ito ay opsyonal, may mga kahihinatnan sa privacy at caching, at hindi ito pahintulot na ipagpalagay na ang anumang pampublikong resolver ay nag-uulat ng tumpak na lokasyon ng user. Tanungin ang mga operator ng resolver bago magdisenyo sa paligid nito.

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

Suriin kung ano ang pinagpasyahan ng pagruruta ng anycast

Sa anycast, maraming lokasyon ang nag-aanunsyo ng pagiging maabot para sa isang address ng serbisyo, at dinadala ng network ang bawat kliyente sa node na pinipili ng pagruruta nito. Ang pagpiling iyon ay ginagawa ng BGP at ng nakapaligid na patakaran, hindi ng distansya sa mapa. Ang topolohikal na kalapitan ay karaniwang hindi rin katumbas ng mas mahusay na pagganap ng round-trip, dahil ang landas na mukhang maikli ay maaaring siksikan o asymmetric. Ang address na ibinigay sa iyo ay walang sinasabi tungkol sa kung aling node ang sumagot.

Kumpirmahin ang lokasyong naglilingkod mula sa panig ng serbisyo, o mula sa isang sagot na nagpangalan nito, sa halip na mula lamang sa sagot ng DNS. Ipinapakita ng traceroute -n 198.51.100.20 ang landas na tinahak mo at hindi pa rin pinapangalanan ang host sa dulo nito, kaya basahin ito bilang landas at hindi bilang sagot.

Suriin na nakakaligtas ang sesyon sa pagbabago ng node

Ang query ng DNS ay maikli at ang sesyon ng VPN ay mahaba, at ang dalawa ay may ganap na magkaibang mga pangangailangan sa estado. Maaaring lumipat ang pagruruta sa gitna ng sesyon, at kapag nangyari iyon, ang mga susunod na packet ay maaaring dumating sa isang node na hindi pa nakakita ng iyong tunnel. Kung ito ay makakaligtas ay depende sa implementasyon: ibinahaging estado, sinadyang muling pagkonekta, o dokumentadong pagkabigo. Ang address lamang ay wala sa mga iyon.

Obserbahan ang paglilipat sa halip na ipagpalagay ito. Ipinapakita ng sudo tcpdump -ni any -c 20 esp ang mga panlabas na packet habang nagbabago ang landas, at ang biglang pagbabago sa address ng peer ay ang paglilipat na nangyayari. Tahasang tukuyin ang nilalayong pag-uugali para sa implementasyong pinapatakbo mo, pagkatapos ay subukan ito sa pamamagitan ng pagpilit ng pagbabago ng landas. Kung ipinapalagay ng disenyo ang replikasyon ng sesyon, pangalanan ang mekanismo at pangalanan ang pagkabigong hindi nito sakop.

Suriin na tumutugma pa rin ang pagkakakilanlan

Ang bawat entry point ay dapat magpakita ng pagkakakilanlang inaasahan ng iyong profile ng kliyente. Ang sertipikadong inisyu para sa pangalan ng serbisyo ay gumagana sa mga node, habang ang mga sertipiko kada node ay pumipilit sa kliyente na tanggapin ang bago, at doon natututo ang mga user na i-click ang mga babala. Panatilihing pare-pareho ang inaasahang pagkakakilanlan at profile sa modelo ng pagpasok.

Suriin ito mula sa isang kliyenteng nakarating sa kakaibang node, dahil iyon ang kaso kung saan nagiging nakikita ang sertipiko kada node. Ipinapakita ng openssl s_client -connect vpn.example.com:443 -servername vpn.example.com ang chain at mga pangalan, na eksaktong inihahambing ng kliyente. Pagkatapos ay magpasya kung dapat paliitin ang profile o baguhin ang modelo ng sertipiko.

Suriin ang talaan, hindi lamang ang unang sagot

Tayahin ang tatlong senaryo at magsulat ng apat na katotohanan para sa bawat isa: normal na pagpasok, isang lokasyong hindi available, at ang napagkasunduang kaso ng pagbawi. Ang apat na katotohanan ay ang ginamit na resolver, ang ibinalik na address, ang lokasyong naglingkod, at isang bagong resulta ng aplikasyon. Hinihiwalay ng talaang iyon ang problema sa pagpili ng DNS mula sa problema sa gateway, problema sa pagruruta o problema sa estado ng sesyon. Kung wala iyon, ang apat ay magkamukha mula sa kliyente.

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

Patakbuhin ang mga senaryo mula sa mga representatibong access network at hindi lamang mula sa opisina, dahil ang buong tanong ay kung aling entry point ang aktwal na nararating ng iba't ibang kliyente. Ang isang network ay isang sample ng isa.