DNS geografis dan anycast: memeriksa entri VPN yang Anda dapat

Jawaban DNS yang dekat terasa seperti masalah yang selesai sampai koneksi mendarat di tempat lain. DNS geografis dan anycast keduanya mencoba memperpendek jalur, dan mereka mengambil keputusan itu dari informasi yang berbeda. Keduanya tidak menjamin bahwa gateway yang Anda capai dapat dijangkau, bahwa gateway itu menampilkan identitas yang diharapkan klien Anda, atau bahwa sesi Anda bertahan saat simpul berganti. Pemeriksaan di bawah ini memisahkan keempat pertanyaan tersebut.

Periksa lokasi siapa yang sebenarnya dilaporkan resolver

Server otoritatif yang menjawab kueri peka topologi biasanya melihat alamat resolver rekursif yang bertanya, bukan alamat orang yang mengetik nama itu. Resolver terpusat bisa berada jauh dari klien yang dilayaninya, dan jawaban itu mencerminkan resolver, bukan mereka. Itu bukan cacat; begitulah perilaku protokol kecuali informasi tambahan diberikan. Spesifikasi EDNS Client Subnet menjelaskan batasan sekaligus solusi opsionalnya.

EDNS Client Subnet dapat membawa informasi jaringan asal bila setiap peserta mendukung dan mengaktifkannya. Sifatnya opsional, ia punya konsekuensi privasi dan cache, dan itu bukan izin untuk menganggap bahwa resolver publik mana pun melaporkan lokasi pengguna yang presisi. Tanyakan kepada operator resolver sebelum merancang di sekitarnya.

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

Periksa apa yang diputuskan perutean anycast

Dengan anycast, beberapa lokasi mengiklankan keterjangkauan untuk satu alamat layanan, dan jaringan mengantarkan setiap klien ke simpul yang dipilih peruteannya. Pilihan itu dibuat oleh BGP dan kebijakan di sekitarnya, bukan oleh jarak di peta. Kedekatan topologis juga umumnya tidak berarti kinerja bolak-balik yang lebih baik, karena jalur yang tampak pendek bisa padat atau asimetris. Alamat yang Anda terima tidak mengatakan apa pun tentang simpul mana yang menjawab.

Konfirmasi lokasi pelayanan dari sisi layanan, atau dari jawaban yang menyebutkannya, bukan hanya dari jawaban DNS. traceroute -n 198.51.100.20 menunjukkan jalur yang Anda lalui dan tetap tidak menyebutkan host di ujungnya, jadi bacalah sebagai jalur, bukan sebagai jawaban.

Periksa bahwa sesi bertahan saat simpul berganti

Kueri DNS itu singkat dan sesi VPN itu panjang, dan keduanya punya kebutuhan status yang sama sekali berbeda. Perutean bisa bergeser di tengah sesi, dan ketika itu terjadi, paket berikutnya bisa tiba di simpul yang belum pernah melihat terowongan Anda. Apakah itu bisa bertahan bergantung pada implementasinya: status bersama, penyambungan ulang yang disengaja, atau kegagalan yang terdokumentasi. Alamat saja tidak menyediakan satu pun dari itu.

Amati pergeserannya alih-alih menganggapnya. sudo tcpdump -ni any -c 20 esp menunjukkan paket luar saat jalur berubah, dan perubahan mendadak pada alamat rekan adalah pergeseran yang sedang terjadi. Tentukan perilaku yang dimaksud secara eksplisit untuk implementasi yang Anda jalankan, lalu ujilah dengan memaksa perubahan jalur. Jika rancangan mengasumsikan replikasi sesi, sebutkan mekanismenya dan sebutkan kegagalan yang tidak dicakupnya.

Periksa bahwa identitas masih cocok

Setiap titik masuk harus menampilkan identitas yang diharapkan profil klien Anda. Sertifikat yang diterbitkan untuk nama layanan berlaku di semua simpul, sedangkan sertifikat per simpul memaksa klien menerima sesuatu yang baru, dan di situlah pengguna belajar mengabaikan peringatan. Jaga identitas yang diharapkan dan profil tetap konsisten dengan model entri.

Periksa dari klien yang mencapai simpul tidak biasa, karena itulah kasus ketika sertifikat per simpul menjadi terlihat. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com mencetak rantai dan nama-namanya, yang persis itulah yang dibandingkan klien. Lalu putuskan apakah profil harus dipersempit atau model sertifikat diubah.

Periksa catatannya, bukan hanya jawaban pertama

Nilai tiga skenario dan tulis empat fakta untuk masing-masing: entri normal, satu lokasi tidak tersedia, dan kasus pemulihan yang disepakati. Empat fakta itu adalah resolver yang dipakai, alamat yang dikembalikan, lokasi yang melayani, dan hasil aplikasi yang baru. Catatan itu memisahkan masalah pemilihan DNS dari masalah gateway, masalah perutean, atau masalah status sesi. Tanpa itu, keempatnya tampak identik dari sisi 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 skenario dari jaringan akses yang representatif, bukan hanya dari kantor, karena seluruh pertanyaannya adalah titik masuk mana yang benar-benar dicapai klien yang berbeda. Satu jaringan adalah sampel dari satu.