Penghalaan VPN Berasaskan Domain lwn Laluan IP: Mana Satu Sesuai?

Laluan IP sepadan dengan awalan alamat, dan kernel menggunakannya tanpa bertanya lebih lanjut. Peraturan VPN berasaskan domain sepadan dengan nama, bermakna sesuatu dalam tindanan perlu memutuskan alamat mana yang dimaksudkan nama itu sekarang dan mengekalkan keputusan itu terkini. Kedua-duanya mekanisme berbeza dengan mod kegagalan berbeza, dan vendor menggunakan perkataan yang sama untuk kedua-duanya. Membandingkannya dalam senarai ciri terlepas maksudnya; bandingkan dari segi apa yang berlaku apabila jawapannya berubah.

Pemisahan yang berguna ialah antara peraturan yang menyelesaikan dan peraturan yang tidak.

Apa yang sebenarnya dipadankan oleh setiap peraturan

Peraturan awalan sepadan dengan alamat destinasi dalam jadual penghalaan. Tiada apa yang diselesaikan, tiada apa yang luput, dan padanan itu tepat untuk setiap paket. Peraturan domain sepadan dengan permintaan nama daripada aplikasi, yang RFC 1034 mentakrifkannya sebagai pokok label dan bukan alamat. Sesetengah produk menyelesaikan nama sekali dan memasang alamat yang terhasil sebagai laluan, yang menjadikan peraturan itu peraturan IP dengan pemasa penyegaran terpasang.

Ketahui mana antara kedua-duanya yang anda ada sebelum menyahpepijat, kerana kegagalan kelihatan sangat berbeza dalam setiap kes.

Di mana peraturan domain berada dalam tindanan

Jika produk melaksanakan peraturan domain melalui proksi tempatan, trafik mesti sampai ke proksi itu, dan aplikasi yang mengabaikan proksi sistem memintas peraturan sepenuhnya. Jika ia melaksanakannya dengan menyelesaikan nama dan menambah laluan, alamat hanya segar sehingga penyegaran terakhir. Jika ia mengaitkan dirinya pada penyelesai, tingkah laku DNS menjadi sebahagian daripada dasar penghalaan, dan penyelesai sandaran boleh membatalkannya secara senyap.

Baca model vendor dan bukan label tetapan. Dua klien dengan kotak bernama Split Tunnel boleh melakukan tiga perkara berbeza.

Bandingkan apa yang rosak

Tiga perkara rosak secara berbeza. Perubahan alamat: nama hos CDN boleh diselesaikan kepada set alamat berbeza dalam beberapa minit, jadi senarai yang disalin cepat menjadi lapuk. Skop subdomain: peraturan untuk example.com mungkin meliputi api.example.com atau tidak, dan dokumentasi biasanya jelas tentang yang mana. Kegagalan penyelesaian: apabila penyelesai gagal, klien yang menyelesaikan mungkin beralih kepada tunnel trafik, atau menghantarnya terus.

Hanya yang kedua ialah persoalan konfigurasi. Dua lagi ialah persoalan reka bentuk tentang berapa banyak produk bersedia meneka.

Bila awalan ialah jawapan yang lebih baik

Untuk subnet peribadi yang stabil, awalan eksplisit lebih jelas, lebih pantas dan lebih mudah diaudit. Ia juga bertahan apabila penyelesai ranap, kerana tiada apa yang perlu diselesaikan. Gunakan peraturan domain apabila perkhidmatan dihoskan, apabila alamat berputar, atau apabila anda benar-benar tidak dapat menyenaraikan set destinasi. Jangan gunakannya semata-mata kerana nama hos ialah perkara yang kebetulan anda tahu.

Senarai statik yang diteka ialah yang paling teruk daripada kedua-duanya: ia kelihatan terjaga, dan ia terlepas trafik secara senyap pada hari penyedia menambah hos.

Sahkan dengan permintaan baharu

Uji dengan permintaan sejuk selepas sambungan semula biasa, kerana halaman dalam cache mungkin tidak pernah menyentuh peraturan itu. Selesaikan nama, kemudian periksa ke mana sambungan itu sebenarnya pergi. dig +short app.example.com memberikan set alamat semasa, dan senarai sambungan klien memberitahu anda antara muka mana yang membawa aliran itu.

Ulang selepas selang penyegaran yang didokumenkan oleh produk. Jika set alamat beranjak dan peraturan tidak mengikutinya, anda telah menemui tingkah laku sebenar.

Asingkan juga dasar penyelesai. Peraturan domain memerlukan data nama yang betul, tetapi ia tidak dengan sendirinya menentukan penyelesai mana yang menjawab pertanyaan itu.