Saat rute split tunnel tumpang tindih: prefiks mana yang menang

Dua profil split tunnel, dua prefiks privat, dan satu host yang diklaim keduanya. Gejalanya jarang berupa kegagalan bersih: sebuah layanan berjalan pada Senin, kehabisan waktu setelah klien kedua tersambung ulang, dan berjalan lagi setelah reboot. Urutan Anda menyambungkan klien tidak menentukan hasilnya, begitu pula urutan baris di antarmuka klien. Jalankan pemeriksaan ini secara berurutan, dan berhenti pada pemeriksaan pertama yang tidak terpenuhi, karena pemeriksaan berikutnya baru bermakna bila yang sebelumnya benar.

1. Catat tujuan dan sumbernya

Mulailah dari alamat persis yang dituju permintaan yang gagal, bukan nama host dan bukan nama aplikasi. Resolusi nama itu sekali, catat setiap jawaban, dan pilih jawaban yang benar-benar dipakai alur yang gagal. Lalu catat alamat lokal alur yang sama, karena alamat sumber dapat mengubah aturan kebijakan mana yang cocok dan dengan demikian tabel mana yang diperiksa.

Permintaan ke salah satu dari beberapa catatan A bisa gagal sementara alamat saudaranya berhasil, yang tampak seperti tunnel tidak stabil padahal sebenarnya dua jalur berbeda. Jika tujuannya nama dengan beberapa jawaban, uji setiap jawaban secara terpisah sebelum mengubah apa pun.

2. Tanyakan kepada kernel rute mana yang dipilihnya

Jangan membaca tabel rute lalu menyimpulkan jawabannya. Ajukan pertanyaan yang sama dengan yang diajukan tumpukan, dengan alamat sumber yang sama: ip route get 10.20.4.10 from 10.8.0.2 di Linux, atau Find-NetRoute -RemoteIPAddress 10.20.4.10 di PowerShell. Keluarannya menyebut rute yang benar-benar akan dipakai, dan itu sering bukan rute yang Anda harapkan saat membaca tabel.

Di antara rute yang cocok, prefiks yang lebih spesifik biasanya menang: /24 mengalahkan /16 untuk alamat yang berada di dalam keduanya. Di antara kecocokan yang panjangnya sama, metrik yang lebih rendah menang, dan rute yang terpasang pada tautan yang mati dilewati. Dua tunnel yang mendorong /24 yang sama dengan metrik yang sama adalah kasus lain: kernel menyimpan kedua rute dan memilih di antaranya, sehingga hasilnya dapat bergantian alih-alih mengikuti urutan klien tersambung. Itulah tepatnya situasi yang menghasilkan pola Senin berhasil dan Selasa gagal, dan menyambung ulang dengan urutan berbeda tidak mengubahnya.

3. Periksa apakah aturan kebijakan mengalihkan pencarian

Sebelum tabel rute diperiksa, kernel menelusuri aturan kebijakannya. Sebuah aturan dapat mengirim lalu lintas dari sumber, pengguna, atau tanda firewall tertentu ke tabel yang sama sekali lain, sehingga prefiks pemenang di tabel utama mungkin tidak pernah diperiksa untuk alur itu. ip rule show mendaftarnya dalam urutan evaluasi, dan ip route show table 100 menunjukkan apa yang sebenarnya dimuat tabel yang dipilih.

Ada dua jebakan di sini. Aturan yang menunjuk ke tabel kosong menghasilkan pencarian yang jatuh ke aturan berikutnya, sehingga aturannya tampak tidak melakukan apa pun. Yang lain adalah nomor prioritas itu sendiri: aturan dibaca dalam urutan menaik, dan nilai bawaannya adalah 0 local, 32766 main, dan 32767 default. Aturan dengan nomor di bawah 32767 diperiksa sebelum aturan default yang menangkap semua. Aturan dengan nomor di atas 32767 berada di belakangnya dan hanya tercapai bila tidak ada tabel sebelumnya yang menjawab, yang dicegah oleh rute default biasa di main, sehingga dalam praktiknya tidak pernah tercapai dan diam-diam tidak melakukan apa pun sementara tampak terpasang. Jika klien menulis aturan dan rute, periksa keduanya, dan periksa lagi setelah sambung ulang, karena profil yang ditulis ulang dapat menambahkan aturan kedua dengan prioritas berbeda.

4. Pisahkan seri rute dari rencana alamat yang terduplikasi

Kadang prefiks sama sekali bukan masalahnya. Dua situs yang keduanya memakai 192.168.1.0/24 berarti alamat yang sama menandai dua host berbeda, dan tidak ada rute yang dapat membedakannya. Rute host ke salah satu dari dua jawaban hanya berfungsi sampai situs lain menjawab nama yang sama, dan kemudian pengecualian itu diam-diam menjadi penyebab masalahnya.

Petunjuknya adalah alamat tujuan identik di kedua jalur dan hanya pemilik yang dimaksud yang berbeda. Itu keputusan rencana alamat, bukan penyetelan perutean: nomori ulang satu sisi, taruh satu sisi di belakang gateway yang menerjemahkan, atau capai situs kedua lewat proxy yang meresolusi namanya sendiri. Menurunkan rute default atau menumpuk pengecualian host hanya memindahkan benturannya.

5. Pastikan resolver sepakat dengan rute

Nama yang teresolusi ke alamat privat yang salah menghasilkan semua gejala konflik perutean dan tidak satu pun penyebabnya. Bandingkan jawaban yang diterima host dengan alamat yang benar-benar dipakai tujuan, dan periksa resolver mana yang menjawab. Jika tunnel mendorong resolver, klien seharusnya memasangnya untuk alur yang memakai tunnel; jika tidak, host terus bertanya ke resolver lokal, yang mungkin menjawab dari domain pencarian atau catatan di cache.

Tanyai resolver secara langsung dan catat server yang menjawab. Jawaban di cache dengan TTL pendek juga dapat menjelaskan mengapa permintaan pertama setelah sambung ulang berperilaku berbeda dari yang kelima.

6. Sambung ulang, periksa keadaan yang diterapkan, lalu uji kedua alur

Setelah koreksi, sambung ulang dan periksa apa yang benar-benar dipasang klien alih-alih memercayai editor profil. Baca lagi aturan, tabel, dan jawaban ip route get yang dihasilkannya. Klien kedua dapat memasang ulang rutenya sendiri saat tersambung dan menciptakan kembali konflik, karena itu pemeriksaan keadaan harus dilakukan setelah klien terakhir tersambung, bukan sebelumnya.

Uji dua alur, bukan satu: permintaan yang tadinya gagal, dan sumber daya yang seharusnya memakai tunnel lain. Memindahkan semua lalu lintas privat ke satu koneksi akan membuat uji pertama lulus sekaligus merusak yang kedua, dan hanya uji berpasangan yang menangkapnya. Catat setiap pengecualian yang Anda pertahankan, beserta tujuan dan alasannya, agar orang berikutnya dapat membedakan rute host yang disengaja dari yang tersisa.