Klien VPN pada pelayan LAN: mengapa balasan keluar melalui laluan yang salah

Gejala mengikut satu corak: hos berfungsi, kemudian ia menyambung ke VPN sebagai klien, dan kini klien LAN mencapainya manakala balasannya hilang. Tangkapan pada hos menunjukkan balasan keluar melalui peranti terowong dan bukan antara muka LAN. Tiada apa yang rosak pada terowong, dan pembaikannya ialah laluan, bukan sambungan semula. Lakukan empat pemeriksaan di bawah mengikut urutan dan berhenti pada yang pertama gagal.

Balasan ialah paket baharu, bukan pembalikan

Elok ditinggalkan tanggapan bahawa balasan menempuh semula laluan yang dilalui permintaan. Penghalaan diputuskan setiap paket, setiap arah, pada hos penghantar. Permintaan yang tiba dari 10.64.0.23 di dalam terowong tidak mencipta laluan balik; apabila hos membalas, balasan itu dipadankan dengan jadual sebagai paket baharu dan keluar melalui laluan yang menang.

Sebab itulah klien terowong penuh pada mesin yang juga melayani LAN menghasilkan kegagalan yang mengelirukan. Klien memasang laluan lalai, atau dua separuh laluan lalai yang disukai sesetengah klien, dan balasan kepada klien LAN kini sepadan dengan terowong. Ia pergi kepada penyedia, yang tiada sebab untuk memajukannya, dan klien LAN melihat tamat masa walaupun hos hidup dan membalas secara tempatan. Tangkapan menjelaskannya dengan jelas, dan jadual penghalaan menerangkannya.

Ingat dua subrangkaian semasa membaca selebihnya. Satu ialah kumpulan alamat VPN tempat klien jauh datang, dalam contoh ini 10.64.0.0/24. Satu lagi ialah LAN yang mesti terus berfungsi, 172.16.24.0/24 dengan penghalanya di 172.16.24.1. Pepijatnya ialah trafik antara keduanya diputuskan oleh laluan lalai.

Buktikan dengan tangkapan dan carian

Sebelum mengubah apa-apa, sahkan peranti mana yang akan digunakan oleh balasan. Carian lebih pantas daripada tangkapan dan menjawab soalan yang sama yang akan dijawab oleh kernel apabila paket dibina.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Baca balasan dalam dua bahagian. Jika ia menyebut dev tun0, hos akan merangkum balasan dan menyerahkannya kepada penyedia, dan klien LAN tidak akan pernah melihatnya. Jika ia menyebut dev eth0 tetapi klien masih mendapat tamat masa, laluan sudah betul dan paket dibuang kemudian, yang merupakan masalah lain dengan pembaikan lain.

Tangkapan pada langkah yang sama menyelesaikan keraguan yang tidak dapat diselesaikan oleh ping. Balasan gema yang tiba di klien LAN membuktikan ada laluan yang berfungsi, bukan antara muka mana yang membawanya, jadi jalankan tangkapan pada hos itu sendiri dan perhatikan dari mana bingkai keluar. Pencetak pada subrangkaian yang sama terus membalas, kerana laluan langsungnya lebih khusus daripada laluan lalai terowong. Port yang dimajukan gagal sama seperti mana-mana aliran lain, kerana jadual memilih antara muka dan sambungan tidak.

Pasang laluan paling sempit yang mengalahkan terowong

Panjang awalan yang menentukan, bukan metrik, jadi laluan untuk kumpulan klien melalui penghala LAN mengalahkan mana-mana laluan lalai yang dipasang oleh klien VPN. Pembedahan metrik tidak perlu, dan laluan lalai boleh kekal tepat di tempat klien meletakkannya.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Gunakan replace dan bukan add, kerana klien yang menyambung semula sudah memasang entrinya sendiri dan add kedua gagal dengan ralat laluan sudah wujud yang dibaca seperti masalah kebenaran. Pada hos Windows persamaannya ialah route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, di mana -p mengekalkan entri merentas but semula, kerana klien mungkin membina semula jadual apabila terowong naik semula. Pada hos Windows semasa persamaan yang disokong ialah New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, dengan perintah route lama dikekalkan sebagai bentuk legasi.

Satu perincian menentukan sama ada ini betul atau hanya munasabah: hop seterusnya mesti penghala yang benar-benar memiliki laluan balik kepada klien. Menghalakan laluan ke alamat yang dicapai melalui terowong itu sendiri mencipta gelung yang muncul sebagai kehilangan berselang dan bukan kegagalan bersih. Sahkan hop seterusnya berada pada subrangkaian LAN sebelum mengesahkan baris itu.

Kekalkan balasan selepas sambungan semula

Laluan yang ditambah dengan tangan bertahan paling lama sehingga sambungan semula berikutnya. Jika kumpulan klien dinamik, pinkan dalam konfigurasi pelayan supaya awalan yang anda halakan kekal sebagai awalan yang diterima klien; jika tidak entri menunjuk julat kosong dan gejala kembali selepas beberapa minggu tanpa sebab jelas. Menulis laluan ke skrip up klien sendiri ialah pilihan boleh dipercayai yang lain, kerana ia berjalan selepas klien menulis semula jadual.

Tembok api stateful masih boleh mengalahkan laluan yang betul. Jika tangkapan kini menunjukkan balasan keluar melalui eth0 dan klien masih mendapat tamat masa, periksa sama ada hos membuang paket sebelum dihantar. Penapisan laluan balik yang ketat dan net.ipv4.conf.all.rp_filter yang ditetapkan kepada 1 membuang paket yang sumbernya tidak akan dihalakan balik melalui antara muka tempat ia tiba, dan itulah tepat kes tidak simetri yang baru anda cipta dan kemudian betulkan, dan keadaan conntrack menceritakan kisah yang sama untuk port yang dimajukan.

Pemeriksaan terakhir ialah yang orang langkau: ulangi carian selepas terowong turun dan naik semula. Empat nilai harus sepadan dengan apa yang anda catat: destinasi, hop seterusnya, peranti dan sumber yang dipilih. Jika mana-mana bergerak, klien telah menulis semula jadual dan pembaikannya terletak pada cangkuknya, bukan pada sejarah shell.