Apakah tunnel penuh lebih sederhana daripada daftar tunnel terpisah yang panjang?

Daftar tunnel terpisah dimulai dengan tiga aplikasi dan berakhir dengan mencakup sebagian besar mesin, dan setiap baris baru adalah pengecualian seseorang. Pada titik itu daftar telah diam-diam menjadi default dengan langkah tambahan. Tunnel penuh membalik susunannya: semuanya masuk ke tunnel kecuali pengecualian yang terdokumentasi mengatakan sebaliknya. Apakah itu lebih sederhana bergantung pada gateway dan pada layanan lokal yang akan Anda rusak.

Mulailah dengan menghitung aturan yang Anda pelihara

Hitung entrinya, lalu hitung berapa banyak yang punya pemilik bernama dan tanggal verifikasi terakhir. Angka kedua itulah yang penting, karena pengecualian yang tidak dimiliki siapa pun tidak dapat dievaluasi ketika perangkat lunak yang dirujuknya diganti nama atau diganti. Aturan yang terikat pada jalur eksekusi gagal secara diam-diam setelah pembaruan, dan kegagalannya tampak seperti VPN yang tidak stabil, bukan seperti aturan yang kedaluwarsa. Tuliskan daftar itu sebelum Anda punya pendapat tentangnya.

Setiap entri harus menjawab tiga pertanyaan: apa yang rusak tanpanya, siapa yang memutuskan itu, dan bagaimana Anda akan menyadari bahwa alasannya sudah berakhir. Entri yang tidak dapat menjawab ketiganya adalah kandidat untuk dihapus, bukan dimigrasikan, dan menghapusnya lebih dulu membuat perbandingan nanti jujur.

Jika sebagian besar entri merutekan porsi besar lalu lintas, Anda sudah menjalankan tunnel penuh dengan beban pemeliharaan yang menempel. Keputusannya lalu tentang di mana default itu tinggal, bukan tentang apakah harus ada.

Periksa apakah gateway dapat memikul default itu

Tunnel penuh memindahkan setiap paket ke satu perangkat, yang sekaligus mengubah beban CPU perangkat itu, tabel conntrack, penerjemahan alamat, dan kebutuhan bandwidth hulu. Gateway yang dengan nyaman melayani beberapa subnet internal mungkin tidak dirancang untuk seluruh penjelajahan seorang pengguna. Lihat jumlah sesi bersamaan terbesar yang Anda perkirakan, bukan rata-ratanya, karena puncaknya yang pecah lebih dulu.

ip -s link show dev tun0
conntrack -C
ss -s

Ukur beban kerja yang sama sebelum dan sesudah perubahan alih-alih bernalar dari spesifikasi. Satu sore penggunaan biasa di satu mesin akan menunjukkan apakah gateway mendekati batas, dan itu tidak memakan biaya apa pun dibandingkan menemukannya pada Senin pagi.

Periksa juga MTU jalur dari ujung ke ujung, karena default penuh mengekspos setiap aplikasi pada ukuran paket maksimum tunnel. Aplikasi yang bekerja di luar tunnel sekarang mungkin bergantung pada perilaku fragmentasi yang tidak pernah perlu Anda pikirkan.

Pastikan layanan lokal dan DNS privat masih berfungsi

Daftarkan apa yang harus tetap lokal berdasarkan protokol, bukan berdasarkan nama aplikasi: protokol penemuan untuk printer dan layar, jembatan rumah pintar, halaman manajemen router, server pengembangan lokal yang dicapai dengan nama yang hanya diselesaikan di LAN. Hal-hal itu rusak ketika rute default mulai menunjuk ke tunnel, dan rusak secara diam-diam karena tidak ada yang mencatat kesalahan di klien.

DNS privat adalah ketergantungan lainnya. Jika nama internal sebelumnya diselesaikan oleh resolver tunnel, tidak ada yang berubah; jika diselesaikan secara lokal, default penuh harus membawanya ke resolver yang mengenal zona. Uji satu nama internal dan satu nama publik setelah perubahan alih-alih menganggap daftar resolver bertahan.

Tuliskan pengecualian lokal ke dalam profil yang memilikinya. Pengecualian yang hanya disimpan di ingatan seseorang adalah hal pertama yang hilang pada migrasi berikutnya.

Migrasikan satu profil dan verifikasi batasnya

Ubah profil melalui konfigurasinya sendiri alih-alih menumpuk default baru di atas rute manual yang ditinggalkan eksperimen sebelumnya. Rute sisa itulah penyebab biasa migrasi yang tampak berhasil dan berperilaku tidak konsisten sehari kemudian. Simpan profil lama tetap tersedia agar pengembalian adalah pilihan, bukan pembangunan ulang.

Lalu verifikasi dua batas secara terpisah: bahwa tujuan publik dan privat keduanya berfungsi, dan bahwa lalu lintas yang tidak diinginkan tidak keluar di luar tunnel. Pemuatan halaman yang berhasil membuktikan yang pertama dan tidak mengatakan apa pun tentang yang kedua.

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

Ulangi pemeriksaan setelah menyambung ulang dan setelah pemutusan, karena sakelar yang memblokir lalu lintas selama pemutusan adalah sifat yang berbeda dari rute yang pulih dengan benar sesudahnya. Desain yang lebih sederhana adalah yang cakupan sebenarnya masih dapat Anda jelaskan setelah aplikasi atau jaringan berubah.