Aturan domain VPN rusak saat CDN mengubah alamatnya

Anda menyalin alamat dari satu pencarian ke aturan perutean Anda, situs berfungsi, dan seminggu kemudian tidak lagi. Tidak ada yang berubah pada aturan itu. Layanan berpindah ke alamat tepi lain, klien menyelesaikan nama host lain, atau sesi beralih ke IPv6. Keputusan di depan Anda adalah apakah aturan berbasis nama atau rentang eksplisit adalah instrumen yang tepat untuk layanan ini, dan tiga kondisi memutuskannya. Uraian berikut memisahkan nama dari alamat, karena hanya satu di antaranya yang stabil.

Mengapa satu pencarian bukan inventaris

Jaringan pengiriman konten menjawab dengan alamat yang dipilih untuk resolver, wilayah, dan momen. Tanyakan dua kali dari jaringan berbeda dan Anda bisa mendapat jawaban berbeda. Tanyakan sekali dan perlakukan jawaban itu sebagai daftar alamat layanan, maka aturan yang Anda tulis adalah cuplikan, bukan aturan. Itulah seluruh masalah memperlakukan jawaban DNS sebagai konfigurasi.

Ada celah kedua. Satu nama host yang terlihat jarang mencakup seluruh aplikasi, karena login, media, dan lalu lintas API sering memakai nama terpisah. Aturan yang dibangun dari nama host di bilah alamat bisa mencakup halaman dan melewatkan video, yang terbaca sebagai kegagalan sebagian, bukan kesalahan perutean.

Celah ketiga adalah keluarga alamat. Aturan khusus v4 tidak mengatakan apa pun tentang catatan AAAA yang mungkin lebih disukai klien.

Tiga kondisi yang menentukan aturan domain atau rentang

Pertama, apakah layanan menerbitkan kumpulan prefiks stabil yang dapat Anda miliki dan dokumentasikan? Jika ya, rentang eksplisit jujur dan murah. Jika tidak, aturan domain adalah satu-satunya mekanisme yang dapat mengikuti layanan.

Kedua, apakah mekanisme domain klien Anda menyegarkan? Aturan yang diselesaikan sekali saat terhubung dan tidak pernah lagi adalah cuplikan dengan branding lebih baik. Ketiga, apakah mekanisme itu mencakup subdomain dan kedua keluarga alamat, atau hanya nama yang Anda ketik?

Jawab ketiganya dan pilihannya biasanya jelas. Menebak menghasilkan aturan yang berfungsi saat uji dan gagal di produksi.

Uji sesi, bukan halaman

Muat halaman, lalu lakukan operasi yang penting: masuk, mulai pemutaran, unggah berkas. Masing-masing bisa mencapai host berbeda, dan yang gagal adalah yang dilewatkan aturan Anda.

Daftar apa yang benar-benar dihubungi sesi, bukan apa yang ditampilkan halaman:

dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5

Jaga resolver tetap terlihat selama perbandingan, karena aturan yang berfungsi dari satu resolver dan gagal dari resolver lain memberi tahu Anda tentang jawaban CDN, bukan tentang terowongan. TTL pendek juga berarti jawaban yang Anda catat punya masa berlaku.

Apa yang sebenarnya dicakup setiap mekanisme

Kedua mekanisme tampak dapat dipertukarkan di halaman pengaturan dan berperilaku berbeda di baliknya.

Rute alamat kernel mencocokkan prefiks. Ia tidak tahu apa itu nama host, jadi tidak dapat mengikuti layanan yang berganti alamat. Aturan domain menyelesaikan nama dan merutekan hasilnya; ia mengikuti layanan tetapi bergantung pada resolver, perilaku penyegaran, dan penanganan subdomain oleh klien, jadi aturan yang mengikuti nama harus diuji dengan resolver yang benar-benar dipakai klien.

Tidak ada yang menjadi superset yang lain, karena itu mencampurnya tanpa catatan menimbulkan kebingungan nanti.

Periksa ulang setelah layanan berubah

Setelah pembaruan klien atau perubahan layanan, jalankan lagi uji sesi yang sama. Daftar alamat yang dulu berfungsi adalah bukti untuk periode itu, bukan inventaris permanen infrastruktur layanan.

Catat mekanisme mana yang mencakup nama host mana, dan tanggal terakhir Anda memverifikasinya.

Catatan itu adalah perbedaan antara aturan yang dapat Anda pertahankan dan aturan yang tidak berani disentuh siapa pun. Jika layanan menerbitkan daftar prefiksnya sendiri, gunakan itu dan sebutkan tanggalnya. Jika tidak, katakan begitu, dan simpan aturan domain beserta perilaku penyegarannya tertulis di sampingnya.