Mengapa Rute Tunnel Penuh Memutus Server yang Membawanya

Aktifkan tunnel penuh dan setiap tujuan kini menjadi milik antarmuka VPN, termasuk mesin yang mengakhirinya. Paket luar yang membawa tunnel ditujukan ke mesin itu, sehingga rute akhirnya memakan transport yang menjadi dependensinya. Satu rute spesifik tambahan menyelesaikannya, dan alasannya layak dipahami. Tanpa alasan itu, pembangunan ulang berikutnya akan memasukkan lagi kesalahan yang sama.

Rute yang memakan transportnya sendiri

Enkapsulasi membungkus setiap paket dalam header kedua. Header luar ditujukan dari alamat fisik lokal ke alamat publik server, dan harus melewati tautan fisik sebelum tunnel mana pun bisa ada.

Sekarang biarkan pencarian alamat publik itu memilih tunnel. Untuk mengirim paket, mesin harus mengenkapsulasinya, yang memerlukan rute ke alamat yang sama, dan rute itu mengembalikan tunnel. Klien menangani ini dengan salah satu dari dua cara. Yang berhati-hati menolak memasang rute default dan melaporkan kesalahan, sedangkan yang kurang berhati-hati melaporkan keberhasilan lalu tidak memindahkan apa pun. Kegagalan senyap itulah yang memakan satu sore.

Kecocokan prefiks terpanjang menentukan pencarian sebelum metrik apa pun dilihat, sehingga rute satu alamat mengalahkan setiap rute default di mesin. Itulah seluruh mekanisme di balik perbaikan.

Pasang pengecualian sebelum rute default

Buat rute satu alamat untuk server, dengan gateway fisik sebagai hop berikutnya, sebelum rute default berpindah. Urutan penting: memasangnya belakangan berarti hidup dengan tunnel yang rusak selama Anda mengetik.

Sebagian besar klien melakukan ini tanpa diminta. OpenVPN mencari alamat jarak jauh dan menguncinya sebelum menulis ulang gateway default, dan opsi route-delay-nya ada untuk platform tempat urutan itu berlomba. wg-quick mengambil jalan yang sama sekali berbeda, menandai paket dan berkonsultasi dengan aturan kebijakan alih-alih menambahkan pengecualian. Mekanisme berbeda, kebutuhan sama: paket luar harus lolos dari tunnel yang dibuatnya.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

Keluaran pencarian adalah uji penerimaan. Ia harus menyebut perangkat fisik dan hop berikutnya yang fisik. Perangkat tunnel dalam jawaban itu berarti pengecualiannya hilang, atau ditempatkan setelah sesuatu yang mengalahkannya.

Bayangan cermin di server

Perangkap yang sama menunggu di sisi lain, terbalik. Beri server rute default melalui tunnel lain, atau dorong rute yang mencakup alamat publik klien, dan balasannya akan mendapat kebiasaan arah yang salah.

Bayangkan klien yang terhubung dan mengirim permintaan. Balasan ditujukan ke alamat publik klien itu, yang kini cocok dengan rute tunnel, sehingga berangkat dari antarmuka berbeda dengan membawa sumber yang tidak pernah diputar klien. Klien dapat menerima paket itu dan tetap membuangnya, karena tidak ada yang mengikatnya ke permintaan yang dikirim. Mulailah dari keputusan perutean server, bukan dari batas waktu klien, karena hanya satu dari keduanya yang menunjukkan pilihan sebenarnya.

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

Ada tiga perbaikan dan ketiganya tidak setara. Mengunci layanan ke alamat fisik, atau menerjemahkan sumber, keduanya menyembunyikan keputusan perutean alih-alih memperbaikinya. Mengirim lalu lintas balasan untuk kumpulan tunnel melalui tabel khusus memperbaiki penyebabnya, dan dua lainnya hanya dapat diterima selama desain perutean dibekukan.

Pengecualian yang terus dicuri tunnel

Sebagian kecil pekerjaan membutuhkan internet terbuka bahkan saat tunnel memiliki rute default, dan masing-masing perlu pengecualian sendiri. Pembaru DNS dinamis biasanya yang pertama rusak.

Ia me-resolve penyedia, membuka koneksi, dan mendapati paketnya sendiri berjalan melalui tunnel yang alamatnya berubah beberapa detik lalu, sehingga pembaruan gagal atau menerbitkan alamat yang salah. Tiga jalan keluar: kunci penyedia dengan rute host melalui gateway fisik, jalankan pembaruan sebelum tunnel naik, atau beri pembaru tabel kebijakan yang tidak pernah disentuh tunnel. Sinkronisasi waktu memiliki paparan yang sama pada perangkat yang menyala tanpa resolver, dan endpoint validasi sertifikat masuk daftar karena alasan yang sama.

Pengecualian yang tidak ditulis siapa pun adalah pengecualian yang akan dijatuhkan diam-diam oleh pembangunan ulang berikutnya.

Buktikan setelah menyambung ulang, bukan sebelumnya

Uji tiga tujuan, bukan satu: endpoint, alamat privat di balik tunnel, dan alamat publik di baliknya. Satu pencarian yang berhasil hampir tidak mengatakan apa pun tentang dua lainnya.

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

Lalu mulai ulang koneksinya, karena klien yang membangun ulang tabelnya saat menyambung ulang akan membuang rute yang Anda ketik dengan tangan. Dengan kill switch aktif, periksa bahwa endpoint diizinkan, atau tunnel tidak dapat kembali setelah perubahan jaringan dan gejalanya tampak seperti gangguan. Simpan pengecualian di profil atau berkas unit, bukan di riwayat shell, agar penyambungan ulang membuatnya lagi alih-alih menghapusnya.