Perutean VPN Berbasis Domain vs Rute IP: Mana yang Cocok?

Rute IP cocok dengan prefiks alamat, dan kernel menerapkannya tanpa bertanya lebih jauh. Aturan VPN berbasis domain cocok dengan nama, yang berarti sesuatu di dalam tumpukan harus memutuskan alamat mana yang dimaksud nama itu saat ini dan menjaga keputusan itu tetap mutakhir. Keduanya mekanisme berbeda dengan mode kegagalan berbeda, dan vendor memakai kata yang sama untuk keduanya. Membandingkannya dalam daftar fitur melewatkan intinya; bandingkanlah berdasarkan apa yang terjadi saat jawabannya berubah.

Pemisahan yang berguna adalah antara aturan yang me-resolve dan aturan yang tidak.

Dengan apa setiap aturan sebenarnya cocok

Aturan prefiks cocok dengan alamat tujuan di tabel perutean. Tidak ada yang di-resolve, tidak ada yang kedaluwarsa, dan kecocokannya tepat untuk setiap paket. Aturan domain cocok dengan permintaan nama dari aplikasi, yang RFC 1034 mendefinisikannya sebagai pohon label, bukan alamat. Sebagian produk me-resolve nama sekali lalu memasang alamat hasilnya sebagai rute, yang menjadikan aturan itu aturan IP dengan pengatur waktu penyegaran menempel padanya.

Ketahui mana dari keduanya yang Anda punya sebelum melakukan debug, karena kegagalannya terlihat sangat berbeda di tiap kasus.

Di mana aturan domain berada di dalam tumpukan

Jika produk mengimplementasikan aturan domain lewat proksi lokal, lalu lintas harus mencapai proksi itu, dan aplikasi yang mengabaikan proksi sistem melewati aturan sepenuhnya. Jika produk mengimplementasikannya dengan me-resolve nama dan menambahkan rute, alamatnya hanya sebaru penyegaran terakhir. Jika produk mengaitkan dirinya ke resolver, perilaku DNS menjadi bagian dari kebijakan perutean, dan resolver cadangan dapat membatalkannya diam-diam.

Bacalah model vendornya, bukan label setelannya. Dua klien dengan kotak bernama Split Tunnel bisa melakukan tiga hal berbeda.

Bandingkan apa yang rusak

Tiga hal rusak dengan cara berbeda. Perubahan alamat: nama host CDN dapat di-resolve ke kumpulan alamat berbeda dalam hitungan menit, sehingga daftar yang disalin cepat menua. Cakupan subdomain: aturan untuk example.com mungkin mencakup api.example.com atau tidak, dan dokumentasinya biasanya tegas soal itu. Kegagalan resolusi: ketika resolver gagal, klien yang me-resolve dapat beralih ke tunnelling lalu lintas, atau mengirimnya langsung.

Hanya yang kedua merupakan pertanyaan konfigurasi. Dua lainnya adalah pertanyaan desain tentang seberapa banyak produk bersedia menebak.

Kapan prefiks menjadi jawaban yang lebih baik

Untuk subnet privat yang stabil, prefiks eksplisit lebih jelas, lebih cepat, dan lebih mudah diaudit. Prefiks juga bertahan saat resolver mati, karena tidak ada yang perlu di-resolve. Gunakan aturan domain ketika layanan dihosting, ketika alamat berotasi, atau ketika Anda benar-benar tidak dapat menghitung kumpulan tujuannya. Jangan menggunakannya hanya karena nama host adalah hal yang kebetulan Anda ketahui.

Daftar statis yang ditebak adalah yang terburuk dari keduanya: tampak terpelihara, dan diam-diam melewatkan lalu lintas pada hari penyedia menambahkan host.

Verifikasi dengan permintaan baru

Uji dengan permintaan dingin setelah koneksi ulang normal, karena halaman yang di-cache mungkin tidak pernah menyentuh aturan. Resolve namanya, lalu periksa ke mana koneksi sebenarnya pergi. dig +short app.example.com memberikan kumpulan alamat saat ini, dan daftar koneksi klien memberi tahu Anda antarmuka mana yang membawa aliran itu.

Ulangi setelah interval penyegaran yang didokumentasikan produk. Jika kumpulan alamat bergeser dan aturannya tidak mengikuti, Anda telah menemukan perilaku sebenarnya.

Pisahkan juga kebijakan resolver. Aturan domain membutuhkan data nama yang benar, tetapi tidak dengan sendirinya menentukan resolver mana yang menjawab kueri.