DNS geografi dan anycast: menyemak pintu masuk VPN yang anda dapat

Jawapan DNS berdekatan terasa seperti masalah yang sudah selesai sehingga sambungan mendarat di tempat lain. DNS geografi dan anycast kedua-duanya cuba memendekkan laluan, dan mereka membuat keputusan itu daripada maklumat yang berbeza. Kedua-duanya tidak menjamin bahawa gateway yang anda capai boleh dicapai, bahawa ia membentangkan identiti yang dijangka oleh klien anda, atau bahawa sesi anda bertahan apabila nod berubah. Semakan di bawah memisahkan empat soalan itu.

Semak lokasi siapa yang sebenarnya dilaporkan oleh penyelesai

Pelayan berwibawa yang menjawab pertanyaan sensitif topologi biasanya melihat alamat penyelesai rekursif yang bertanya, bukan alamat orang yang menaip nama itu. Penyelesai berpusat boleh berada jauh daripada klien yang dilayaninya, dan jawapan itu mencerminkan penyelesai dan bukan mereka. Itu bukan kecacatan; begitulah protokol berkelakuan melainkan maklumat tambahan dibekalkan. Spesifikasi EDNS Client Subnet menerangkan kedua-dua had dan remedi pilihan itu.

EDNS Client Subnet boleh membawa maklumat rangkaian asal apabila setiap peserta menyokong dan mengaktifkannya. Ia pilihan, ia mempunyai akibat privasi dan cache, dan ia bukan kebenaran untuk menganggap mana-mana penyelesai awam melaporkan lokasi pengguna yang tepat. Tanya pengendali penyelesai sebelum mereka bentuk berdasarkannya.

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

Semak apa yang diputuskan oleh penghalaan anycast

Dengan anycast, beberapa lokasi mengiklankan kebolehsampaian untuk satu alamat perkhidmatan, dan rangkaian menghantar setiap klien ke nod yang digemari oleh penghalaannya. Pilihan itu dibuat oleh BGP dan dasar di sekelilingnya, bukan oleh jarak pada peta. Kedekatan topologi juga tidak semestinya bermakna prestasi perjalanan pergi balik yang lebih baik, kerana laluan yang kelihatan pendek boleh sesak atau tidak simetri. Alamat yang diberi kepada anda tidak memberitahu apa-apa tentang nod mana yang menjawab.

Sahkan lokasi yang melayan daripada sisi perkhidmatan, atau daripada respons yang menamakannya, bukan daripada jawapan DNS semata-mata. traceroute -n 198.51.100.20 menunjukkan laluan yang anda ambil dan masih tidak menamakan hos di hujungnya, jadi bacalah ia sebagai laluan dan bukan sebagai jawapan.

Semak bahawa sesi bertahan apabila nod berubah

Pertanyaan DNS adalah pendek dan sesi VPN adalah panjang, dan kedua-duanya mempunyai keperluan keadaan yang sama sekali berbeza. Penghalaan boleh berubah di tengah sesi, dan apabila ia berbuat demikian, paket kemudian mungkin tiba di nod yang tidak pernah melihat terowong anda. Sama ada ia boleh bertahan bergantung pada pelaksanaan: keadaan dikongsi, sambung semula yang disengajakan, atau kegagalan yang didokumenkan. Alamat sahaja tidak membekalkan mana-mana daripada itu.

Perhatikan peralihan itu dan bukan menganggapnya. sudo tcpdump -ni any -c 20 esp menunjukkan paket luar semasa laluan berubah, dan perubahan mendadak pada alamat rakan ialah peralihan yang sedang berlaku. Takrifkan tingkah laku yang dimaksudkan secara eksplisit untuk pelaksanaan yang anda jalankan, kemudian ujinya dengan memaksa perubahan laluan. Jika reka bentuk menganggap replikasi sesi, namakan mekanisme itu dan namakan kegagalan yang tidak diliputinya.

Semak bahawa identiti masih sepadan

Setiap titik masuk perlu membentangkan identiti yang dijangka oleh profil klien anda. Sijil yang dikeluarkan untuk nama perkhidmatan berfungsi merentas nod, manakala sijil setiap nod memaksa klien menerima sesuatu yang baharu, dan di situlah pengguna belajar menekan melalui amaran. Pastikan identiti yang dijangka dan profil itu konsisten dengan model masuk.

Semak daripada klien yang sampai ke nod luar biasa, kerana itulah kes di mana sijil setiap nod menjadi kelihatan. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com mencetak rantaian dan nama, iaitu tepat apa yang klien bandingkan. Kemudian putuskan sama ada profil perlu disempitkan atau model sijil perlu diubah.

Semak rekod, bukan hanya jawapan pertama

Nilai tiga senario dan tulis empat fakta untuk setiap satu: kemasukan biasa, satu lokasi tidak tersedia, dan kes pemulihan yang dipersetujui. Empat fakta itu ialah penyelesai yang digunakan, alamat yang dikembalikan, lokasi yang melayaninya, dan hasil aplikasi yang baharu. Rekod itu memisahkan masalah pemilihan DNS daripada masalah gateway, masalah penghalaan atau masalah keadaan sesi. Tanpanya, keempat-empatnya kelihatan serupa dari klien.

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

Jalankan senario daripada rangkaian akses yang mewakili dan bukan hanya daripada pejabat, kerana keseluruhan persoalannya ialah titik masuk mana yang sebenarnya dicapai oleh klien yang berbeza. Satu rangkaian ialah sampel bagi satu.