Geografik DNS va anycast: olgan VPN kirishingizni tekshirish
Geografik DNS va anycast kirish nuqtalarini turli qoidalar bilan tanlaydi. Javob qaysi resolverni aks ettirishini, so'ng tugun almashganda sessiya saqlanib qolishini tekshiring.
Yaqin DNS javobi muammo hal bo'lgandek tuyuladi, toki ulanish boshqa joyga tushmaguncha. Geografik DNS va anycast ikkalasi ham yo'lni qisqartirishga harakat qiladi va bu qarorni turli ma'lumotlarga asoslanib qabul qiladi. Hech biri yetib kelgan shlyuzingiz ochiqligiga, u mijozingiz kutgan identifikatsiyani ko'rsatishiga yoki sessiyangiz tugun almashishiga chidashiga kafolat bermaydi. Quyidagi tekshiruvlar shu to'rt savolni ajratadi.
Resolver aslida kimning joylashuvini bildirishini tekshiring
Topologiyaga sezgir so'rovga javob beradigan vakolatli server odatda so'ragan rekursiv resolverning manzilini ko'radi, ismni yozgan odamning manzilini emas. Markazlashgan resolver xizmat ko'rsatadigan mijozlardan uzoqda turishi mumkin va javob ularni emas, resolverni aks ettiradi. Bu nuqson emas; qo'shimcha ma'lumot berilmasa, protokol shunday ishlaydi. EDNS Client Subnet spetsifikatsiyasi ham cheklovni, ham ixtiyoriy choralarni tavsiflaydi.
EDNS Client Subnet har bir ishtirokchi uni qo'llab-quvvatlab yoqsa, manba tarmoq ma'lumotlarini olib yurishi mumkin. Bu ixtiyoriy, maxfiylik va keshlash oqibatlari bor va har qanday ommaviy resolver foydalanuvchining aniq joylashuvini bildiradi deb taxmin qilishga ruxsat emas. U atrofida loyihalashdan oldin resolver operatorlaridan so'rang.
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 marshrutlash nima qaror qilganini tekshiring
anycast bilan bir nechta joylashuv bitta xizmat manzili uchun ochiqlikni e'lon qiladi va tarmoq har bir mijozni marshrutlashi afzal ko'rgan tugunga yetkazadi. Bu tanlov xaritadagi masofa emas, BGP va atrofdagi siyosat tomonidan qilinadi. Topologik yaqinlik ham odatda yaxshiroq borish-kelish unumdorligini anglatmaydi, chunki qisqa ko'ringan yo'l tiqilib qolgan yoki assimetrik bo'lishi mumkin. Sizga berilgan manzil qaysi tugun javob bergani haqida hech narsa demaydi.
Xizmat ko'rsatuvchi joylashuvni xizmat tomonidan yoki uni nomlaydigan javobdan tasdiqlang, faqat DNS javobidan emas. traceroute -n 198.51.100.20 bosib o'tgan yo'lingizni ko'rsatadi va baribir uning oxiridagi xostni nomlamaydi, shuning uchun uni javob emas, yo'l sifatida o'qing.
Tugun almashganda sessiya saqlanib qolishini tekshiring
DNS so'rovi qisqa, VPN sessiyasi esa uzoq va ikkalasi butunlay boshqa holat talablariga ega. Marshrutlash sessiya o'rtasida siljishi mumkin va shunday bo'lganda keyingi paketlar tunnelingizni hech qachon ko'rmagan tugunga yetib borishi mumkin. Bu chidashiga implementatsiyaga bog'liq: umumiy holat, ataylab qayta ulanish yoki hujjatlashtirilgan nosozlik. Faqat manzil bularning hech birini bermaydi.
Siljishni taxmin qilish o'rniga kuzating. Yo'l o'zgarganda sudo tcpdump -ni any -c 20 esp tashqi paketlarni ko'rsatadi va hamkor manzilidagi to'satdan o'zgarish aynan sodir bo'layotgan siljishdir. Ishlatayotgan implementatsiyangiz uchun mo'ljallangan xatti-harakatni aniq belgilang, so'ng yo'l o'zgarishini majburlash orqali sinab ko'ring. Agar dizayn sessiya replikatsiyasini nazarda tutsa, mexanizmni nomlang va u qoplamaydigan nosozlikni ham nomlang.
Identifikatsiya hali ham mos kelishini tekshiring
Har bir kirish nuqtasi mijoz profilingiz kutgan identifikatsiyani ko'rsatishi kerak. Xizmat nomiga berilgan sertifikat tugunlar bo'ylab ishlaydi, tugun bo'yicha sertifikatlar esa mijozni yangi narsani qabul qilishga majbur qiladi va foydalanuvchilar ogohlantirishlarni bosib o'tishni aynan shu yerda o'rganadi. Kutilgan identifikatsiya va profilni kirish modeliga mos holda saqlang.
Buni noodatiy tugunga yetib borgan mijozdan tekshiring, chunki tugun bo'yicha sertifikat ko'rinadigan holat aynan shu. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com zanjir va nomlarni chop etadi, bu mijoz taqqoslaydigan narsaning o'zi. So'ng profilni toraytirish yoki sertifikat modelini o'zgartirish kerakligini hal qiling.
Faqat birinchi javobni emas, yozuvni tekshiring
Uchta stsenariyni baholang va har biri uchun to'rtta fakt yozing: oddiy kirish, bitta joylashuv mavjud emas va kelishilgan tiklash holati. To'rtta fakt ishlatilgan resolver, qaytarilgan manzil, xizmat ko'rsatgan joylashuv va yangi dastur natijasidir. Bu yozuv DNS tanlash muammosini shlyuz muammosidan, marshrutlash muammosidan yoki sessiya holati muammosidan ajratadi. Usiz to'rttasi ham mijozdan bir xil ko'rinadi.
dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health
Stsenariylarni faqat ofisdan emas, vakillik kirish tarmoqlaridan ishga tushiring, chunki butun savol turli mijozlar haqiqatda qaysi kirish nuqtasiga yetib borishidir. Bitta tarmoq bittaning namunasidir.