Dokumentasi split-tunnel butuh aturan DNS di samping setiap rute
Rute memutuskan berdasarkan alamat, resolver berdasarkan nama. Dokumentasikan kedua pemilih per alur, masing-masing dengan satu uji, atau catatan gagal saat DNS bergeser.
Catatan split-tunnel yang menyatakan "lalu lintas kantor lewat VPN" telah mendokumentasikan satu keputusan dan menyiratkan tiga lainnya. Pada lapisan paket, tabel perutean memilih antarmuka berdasarkan alamat tujuan; pada lapisan nama, resolver memilih server berdasarkan kueri, dan kedua pilihan dibuat secara independen. Karena itu, prefiks yang didokumentasikan dengan benar masih dapat menghasilkan mesin yang menyelesaikan nama internal ke alamat publik, atau tidak menyelesaikan apa pun sementara rutenya tampak sempurna.
Dua pemilih, satu upaya koneksi
Saat aplikasi terhubung ke files.corp.example, dua pencarian terjadi sebelum paket ada. Resolver memutuskan server mana yang menerima kueri, menggunakan domain pencarian, domain perutean per tautan, atau aturan profil eksplisit. Tabel perutean lalu memutuskan ke mana alamat hasil pergi, menggunakan kecocokan prefiks terpanjang dengan tujuan.
Tidak ada yang menghubungkan kedua keputusan itu. Zona privat dapat menjawab dengan 10.20.4.11 sementara tabel perutean mengirim 10.20.0.0/16 ke dalam terowongan, dan koneksinya berfungsi. Balik salah satunya dan ia gagal dengan cara yang tampak seperti yang lain: kebijakan DNS yang benar ditambah rute yang hilang memberi nama yang terselesaikan dan waktu habis, sedangkan rute yang benar ditambah resolver publik memberi alamat yang dirutekan dengan bersih ke tempat yang salah.
DNS cakrawala terbelah membuat ini lebih tajam. Nama yang sama dapat mengembalikan alamat privat dari resolver internal dan alamat publik dari resolver yang menghadap internet, sehingga catatan yang hanya merekam prefiks tidak dapat memprediksi alamat mana yang benar-benar akan dipakai klien. Tuliskan jalur resolver atau alamatnya hanya tebakan.
Apa yang dilewatkan catatan hanya-rute
Catatan hanya-rute tidak berguna untuk kegagalan split-tunnel yang paling umum: nama. Pengguna melaporkan bahwa intranet tidak dimuat, terowongan aktif, dan prefiksnya ada. Siapa pun yang mengambil tiket itu tidak punya catatan resolver mana yang seharusnya menjawab, tidak punya cara membedakan sufiks pencarian yang salah dari server yang diblokir, dan tidak punya garis dasar untuk dibandingkan.
Kelalaian kedua adalah daftar pengecualian. Desain split-tunnel ditentukan sama besar oleh apa yang tetap di luar terowongan seperti oleh apa yang masuk ke dalamnya, dan rentang yang dikecualikan biasanya yang pertama rusak, karena rute lokal yang lebih spesifik atau filter di sisi klien dapat menimpa maksud tanpa menyentuh profil.
Yang ketiga adalah sisi jauh terowongan. Rute klien hanya menaruh paket di kabel; gateway tetap harus meneruskannya dan punya jalur kembali. Panduan penerusan strongSwan mengingatkan bahwa aturan penerusan dan firewall di gateway adalah bagian dari fitur, bukan bagian dari perpipaan yang bisa Anda anggap ada.
Bidang yang membuat catatan dapat dijalankan
Satu baris per alur, dan alur adalah tujuan ditambah nama ditambah pemilik. Inilah bidang yang bertahan saat bersentuhan dengan insiden nyata:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
Baris "di mana ia tinggal" adalah yang dilewati orang. Prefiks yang didorong server, rute yang ditambahkan profil klien, dan rute yang diketik di shell berbeda dalam siapa yang dapat mengubahnya dan apakah bertahan setelah penyambungan ulang. Tanpa bidang itu, insinyur berikutnya tidak dapat mengetahui mana dari ketiganya yang sedang ia lihat.
Satu uji per aturan, bukan satu per terowongan
Setiap baris membutuhkan dua pemeriksaan tak berbahaya: satu yang melatih rute dan satu yang melatih nama. Untuk rute, minta sesuatu yang harus melintasi terowongan dan pastikan jalurnya, bukan keterjangkauannya, misalnya tracert -d 10.20.4.11 di Windows atau ip route get 10.20.4.11 di Linux. Untuk nama, kueri nama privat dan catat server mana yang menjawab, menggunakan resolvectl query files.corp.example atau dig files.corp.example terhadap resolver yang disebut catatan.
Tambahkan juga ekspektasi negatif: apa yang seharusnya terjadi saat terowongan mati. Aplikasi yang dikecualikan pada perangkat Android atau iOS dengan pemblokiran tanpa VPN aktif mungkin tidak punya konektivitas sama sekali, dan klien desktop dapat membiarkan aplikasi yang sama bekerja saat terowongan menyambung ulang. Merekam jawaban yang dimaksudkan mengubah "VPN merusak aplikasi saya" menjadi pernyataan yang dapat diperiksa.
Simpan catatan bersama konfigurasi
Simpan catatan di samping profil yang dijelaskannya dan beri versi bersama profil itu. Dokumen di wiki yang tidak diperbarui siapa pun adalah desas-desus; tabel di repositori yang sama dengan rute yang didorong dan kebijakan resolver dapat ditinjau dalam perubahan yang sama.
Saat sesuatu rusak, bandingkan rute yang diterapkan dan resolver efektif dengan catatan sebelum menambahkan pengecualian lain. Dua dari tiga penyebab umum — aturan ruang nama lama dan proses pembantu di luar kebijakan aplikasi — tampak persis seperti kerusakan VPN dan tidak terlihat jika catatan hanya mencantumkan prefiks.
Sebelum menyebut catatan selesai, pastikan catatan itu menjawab secara tertulis: prefiks mana, untuk keluarga alamat mana; ruang nama privat mana, dijawab resolver mana; nama mana yang sengaja tetap publik; di mana setiap aturan dikonfigurasi dan siapa pemiliknya; serta satu perintah yang membuktikan rute dan satu yang membuktikan nama. Jika salah satunya hilang, insiden berikutnya akan didiagnosis dari awal.