Cara membedakan rute yang didorong VPN dari rute statis di Linux

Sebuah prefiks muncul di laptop saat terowongan naik, jadi terasa seperti VPN yang memasangnya. Mungkin saja, tetapi hasil yang sama bisa datang dari skrip klien yang berjalan saat terhubung, profil koneksi yang mencantumkan subnet, atau rute statis yang sudah ada sejak awal dan baru mulai bekerja setelah antarmuka ada. Memilih pemilik yang salah berarti rute itu kembali setelah setiap pembersihan, dan orang berikutnya mengulangi perbaikan yang sama. Urutan di bawah memisahkan ketiganya sebelum apa pun diubah.

Langkah 1: sebutkan mekanisme yang memasang prefiks

Protokol yang berbeda menyediakan keterjangkauan dengan cara berbeda, dan menyebut semuanya sebagai pengumuman menyembunyikan perbedaannya. Server OpenVPN mendorong direktif rute melalui kanal kontrol dan klien memasangnya kecuali filter pull memblokirnya. Konfigurasi WireGuard mencantumkan prefiks yang diizinkan secara lokal, yang dipakai klien untuk perutean kunci kripto dan untuk rute yang ditambahkannya. Terowongan IPsec menyepakati pemilih lalu lintas dengan rekan, dan kernel memasang rute dari pemilih tersebut.

Tentukan mana dari itu yang dipakai terowongan Anda sebelum membaca tabel apa pun. Rute yang didorong saat terhubung bukan pengumuman protokol perutean, dan tidak menjanjikan prefiks itu terjangkau di balik ujung jauh. Catat mekanismenya di samping prefiks, karena itu menentukan di mana perbaikannya berada.

Langkah 2: bandingkan tabel sepanjang satu koneksi

Simpan tabel utama saat terowongan turun, naikkan, simpan lagi, dan bandingkan dua tangkapan. Apa pun yang muncul termasuk siklus hidup koneksi, dan apa pun yang bertahan termasuk konfigurasi lokal.

Tangkap dengan ip route show table main > /tmp/route-down.txt, hubungkan, dan tangkap lagi. Lakukan hal yang sama untuk ip -6 route jika situs memakai IPv6, karena prefiks yang hilang di sana menghasilkan kegagalan yang tampak tidak terkait perutean.

Langkah 3: baca metriknya, bukan hanya keberadaannya

Dua entri untuk prefiks yang sama bisa hidup berdampingan, dan kernel memilih metrik yang lebih rendah. Rute statis dengan metrik 50 akan terus mengalahkan rute yang didorong pada 100 meski keduanya terlihat, karena itu 'rutenya ada' dan 'lalu lintas memakainya' adalah pernyataan berbeda.

Tanyakan langsung ke kernel dengan ip route get 10.20.5.7 dan baca antarmuka yang dilaporkannya. Jika lalu lintas keluar lewat adaptor fisik sementara rute terowongan duduk di tabel, metrik atau panjang prefiks yang menjelaskannya, bukan klien VPN. Ulangi pencarian untuk host yang Anda tahu berada di balik terowongan dan untuk yang Anda tahu tidak, dan selisihnya menunjukkan apakah pembagian berperilaku sebagaimana mestinya.

Langkah 4: temukan entri yang bertahan lebih lama dari terowongan

Rute statis bertahan dari pemutusan karena desain, dan dari situlah entri basi berasal. Rute permanen yang menunjuk antarmuka yang sudah tidak ada bisa menelan subnet dengan diam-diam, dan yang menunjuk nama antarmuka yang dipakai ulang bisa mengirim lalu lintas privat lewat pintu yang salah setelah reboot.

Periksa sisi permanen di tempat yang dipakai distribusi Anda, entah unit systemd-networkd, profil NetworkManager, atau skrip di direktori up klien. Memperbaiki tabel yang hidup dengan ip route del hanya bertahan sampai koneksi berikutnya. Perlakukan penghapusan itu sebagai uji hipotesis, bukan sebagai perbaikannya.

Ketika ujung jauh memberi cakupan yang salah, angkat ke operator alih-alih menyaring semuanya. Membuang semua pengaturan yang didorong juga membuang DNS dan kebijakan terowongan terpisah yang menjadi sandaran profil.

Langkah 5: pastikan jalur balik sebelum menyalahkan klien

Untuk koneksi situs-ke-situs atau subnet di balik terowongan, sisi jauh membutuhkan rute balik ke alamat klien Anda dan penerusan aktif di gateway. Jalur satu arah terlihat persis seperti bug perutean klien, kecuali jabat tangan dan paket keluar keduanya berhasil.

Penyaringan jalur balik menambah perangkap kedua di gateway Linux. Balasan yang tiba di antarmuka berbeda dari yang diperkirakan rute dijatuhkan oleh mode ketat, dan jalur asimetris lewat dua penyedia memicunya dengan andal. Penghitung jatuhan di gateway, bukan di klien, memberi tahu Anda apakah penyaringan penyebabnya.

Langkah 6: uji sumber dayanya, bukan ping

Setelah rute yang dipilih benar, buka sumber daya sebenarnya dan pastikan lalu lintas baliknya. Balasan ping membuktikan jalur satu arah dan tidak apa pun tentang layanan, dan layanan yang menjawab pada koneksi ter-cache membuktikan lebih sedikit lagi.

Lalu ulangi seluruh pemeriksaan setelah menyambung ulang. Nilai urutan ini adalah ia meramalkan apa yang akan dilakukan koneksi berikutnya, karena itu perbandingan dan metrik keduanya masuk ke tiket.