Cara membezakan laluan yang ditolak VPN daripada laluan statik di Linux

Awalan muncul pada komputer riba apabila terowong naik, jadi terasa seolah-olah VPN yang memasangnya. Mungkin ya, tetapi hasil yang sama boleh datang daripada skrip klien yang berjalan semasa menyambung, profil sambungan yang menyenaraikan subnet, atau laluan statik yang sudah ada sejak awal dan hanya mula berfungsi apabila antara muka wujud. Memilih pemilik yang salah bermakna laluan itu kembali selepas setiap pembersihan, dan orang seterusnya mengulangi pembetulan yang sama. Urutan di bawah memisahkan ketiga-tiganya sebelum apa-apa diubah.

Langkah 1: namakan mekanisme yang memasang awalan

Protokol berbeza menyediakan kebolehcapaian dengan cara berbeza, dan menyebut semuanya sebagai pengumuman menyembunyikan perbezaannya. Pelayan OpenVPN menolak arahan laluan melalui saluran kawalan dan klien memasangnya melainkan penapis pull menyekatnya. Konfigurasi WireGuard menyenaraikan awalan yang dibenarkan secara setempat, yang digunakan klien untuk penghalaan kunci kripto dan untuk laluan yang ditambahnya. Terowong IPsec bersetuju pemilih trafik dengan rakan sebaya, dan kernel memasang laluan daripada pemilih tersebut.

Tentukan yang mana antaranya terowong anda gunakan sebelum membaca mana-mana jadual. Laluan yang ditolak semasa menyambung bukan pengumuman protokol penghalaan dan tidak menjanjikan awalan itu boleh dicapai di belakang hujung jauh. Catat mekanisme di sebelah awalan, kerana ia menentukan di mana pembetulan itu terletak.

Langkah 2: bandingkan jadual sepanjang satu sambungan

Simpan jadual utama semasa terowong turun, naikkannya, simpan semula dan bandingkan dua tangkapan. Apa-apa yang muncul tergolong dalam kitaran hayat sambungan, dan apa-apa yang kekal tergolong dalam konfigurasi setempat.

Tangkap dengan ip route show table main > /tmp/route-down.txt, sambung dan tangkap semula. Lakukan perkara sama untuk ip -6 route jika tapak menggunakan IPv6, kerana awalan yang tiada di sana menghasilkan kegagalan yang kelihatan tidak berkaitan dengan penghalaan.

Langkah 3: baca metrik, bukan hanya kewujudan

Dua entri untuk awalan yang sama boleh wujud bersama, dan kernel memilih metrik yang lebih rendah. Laluan statik dengan metrik 50 akan terus menewaskan laluan yang ditolak pada 100 walaupun kedua-duanya kelihatan, kerana itu 'laluan itu ada' dan 'trafik menggunakannya' ialah pernyataan berbeza.

Tanya kernel secara langsung dengan ip route get 10.20.5.7 dan baca antara muka yang dilaporkannya. Jika trafik keluar melalui penyesuai fizikal sementara laluan terowong duduk dalam jadual, metrik atau panjang awalan yang menjelaskannya, bukan klien VPN. Ulang carian untuk hos yang anda tahu berada di belakang terowong dan yang anda tahu tidak, dan perbezaannya menunjukkan sama ada pembahagian berkelakuan seperti yang dimaksudkan.

Langkah 4: cari entri yang hidup lebih lama daripada terowong

Laluan statik bertahan daripada pemutusan secara reka bentuk, dan dari situlah entri usang datang. Laluan kekal yang menunjuk ke antara muka yang tidak lagi wujud boleh menelan subnet secara senyap, dan yang menunjuk ke nama antara muka yang digunakan semula boleh menghantar trafik peribadi keluar melalui pintu yang salah selepas but semula.

Semak bahagian kekal di tempat yang digunakan oleh distribusi anda, sama ada unit systemd-networkd, profil NetworkManager atau skrip dalam direktori up klien. Membetulkan jadual hidup dengan ip route del hanya bertahan sehingga sambungan seterusnya. Anggap penghapusan itu sebagai ujian hipotesis, bukan pembaikannya.

Apabila hujung jauh memberikan liputan yang salah, bawa perkara itu kepada pengendali dan bukannya menapis semuanya. Membuang semua tetapan yang ditolak juga membuang DNS dan dasar terowong berpecah yang bergantung pada profil.

Langkah 5: sahkan laluan balik sebelum menyalahkan klien

Untuk sambungan tapak-ke-tapak atau subnet di belakang terowong, bahagian jauh memerlukan laluan balik ke alamat klien anda dan pemajuan dihidupkan pada gateway. Laluan sehala kelihatan tepat seperti pepijat penghalaan klien, kecuali jabat tangan dan paket keluar kedua-duanya berjaya.

Penapisan laluan songsang menambah perangkap kedua pada gateway Linux. Balasan yang tiba pada antara muka berbeza daripada yang diramalkan laluan digugurkan oleh mod ketat, dan laluan tidak simetri melalui dua pembekal mencetuskannya dengan pasti. Pembilang gugur pada gateway, bukan pada klien, memberitahu anda sama ada penapisan itu puncanya.

Langkah 6: uji sumber itu, bukan ping

Setelah laluan yang dipilih betul, buka sumber sebenar dan sahkan trafik balik. Balasan ping membuktikan laluan dalam satu arah dan tiada apa-apa tentang perkhidmatan, dan perkhidmatan yang menjawab pada sambungan cache membuktikan lebih sedikit lagi.

Kemudian ulangi seluruh pemeriksaan selepas menyambung semula. Nilai urutan ini ialah ia meramalkan apa yang akan dilakukan sambungan seterusnya, kerana itu perbandingan dan metrik kedua-duanya masuk ke dalam tiket.