Penghala LAN dan klien VPN: dua peranti, dua jadual laluan

Dua peranti memajukan paket dan setiap satu menyimpan jadualnya sendiri. Penghala LAN tahu bahawa awalan jauh milik klien VPN, dan klien VPN tahu cara mencapai awalan itu melalui terowongnya. Konfigurasikan hanya jadual pertama dan paket tiba di mesin yang tiada laluan sepadan, jadi ia keluar semula melalui laluan lalai. Itulah keseluruhan kegagalan, dan dari sisi LAN ia kelihatan seperti gelung penghalaan, kerana hampir begitulah.

Lukis kedua-dua lompatan sebelum menyentuh laluan

Ambil susun atur ilustratif: hos LAN pada 192.168.50.0/24, penghala biasa pada 192.168.50.1, klien khusus pada 192.168.50.15, dan LAN jauh pada 10.60.0.0/24 yang hanya boleh dicapai melalui terowong yang dipegang klien itu. Tiada satu pun daripada kedua-dua julat persendirian bertindih dengan yang lain, dan terowong itu mempunyai pelan alamatnya sendiri.

Kedua-dua julat persendirian penting kerana ia menentukan peranti mana yang boleh menjawab. Pihak jauh akan melihat paket datang dari alamat terowong klien, dan balasannya mesti mencari jalan kembali ke 192.168.50.0/24. Jika hanya arah keluar dikonfigurasikan, permintaan mungkin berfungsi sementara balasan hilang.

Langkah 1: halakan penghala ke klien, bukan ke terowong

Pada penghala LAN, tambah laluan destinasi yang lompatan seterusnya ialah alamat LAN klien:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Rekod itu berkata “hantar ke mesin yang boleh membuat terowong”. Ia tidak berkata apa-apa tentang cara terowong dibina, dan ia bukan pengganti laluan klien sendiri. Pada penghala terurus, persamaannya hidup di halaman laluan statik peranti; pada penghala Linux ia tergolong dalam konfigurasi antara muka yang memiliki LAN, bukan dalam shell yang akan anda tutup.

Periksa jawapan arahan kedua. Jika ia melaporkan klien sebagai gateway dan antara muka LAN sebagai device, lompatan pertama betul dan kerja selebihnya ada pada mesin lain.

Langkah 2: beri klien laluan sendiri di sisi terowong

Klien kini menerima paket untuk 10.60.0.0/24 dan melihat jadualnya sendiri. Jika konfigurasi terowongnya memasang laluan untuk awalan itu, paket itu diteruskan secara disulitkan. Jika tidak, paket itu sepadan dengan lalai biasa dan kembali ke 192.168.50.1, yang menghantarnya semula kepada klien.

Lihat sebelum menambah apa-apa:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Laluan awalan yang tiada dalam semua jadual ialah penemuan yang anda cari. Tambahnya melalui konfigurasi terowong itu sendiri, supaya sambungan semula seterusnya memasangnya semula; ip route add manual hilang bersama sesi dan membuat kesalahan kembali pada masa yang paling tidak sesuai. Lompatan seterusnya ialah antara muka terowong atau alamat yang VPN berikan sebagai rakan sejawatnya, bergantung pada klien, dan alamat rakan sejawat patut datang dari profil semasa dan bukan dari nota lama.

Gelung itu, apabila berlaku, tidak terhingga dalam praktiknya: TTL menurun pada setiap laluan dan paket mati dengan mesej masa melebihi. Itulah sebabnya traceroute berulang boleh mencadangkan kitaran manakala klien yang semata-mata tidak memajukan menggugurkan paket yang sama secara senyap.

Langkah 3: benarkan pemajuan dan pilih laluan balik

Menerima dan memajukan ialah kebenaran yang berbeza. net.ipv4.ip_forward=1 pada klien membenarkan transit pada peringkat kernel, dan peraturan firewall masih perlu membenarkannya antara antara muka LAN dan terowong. Peraturan yang membenarkan akses ke halaman pengurusan klien sendiri tidak akan membenarkan transit ke LAN jauh, dan perbezaannya mudah terlepas apabila hos yang sama menjawab ping secara setempat.

Pihak jauh mempunyai masalah cermin. Ia mesti tahu bahawa 192.168.50.0/24 boleh dicapai melalui klien yang disahkan ini. Dengan OpenVPN itu biasanya bermaksud laluan bagi setiap klien yang ditolak oleh konfigurasi pelayan, atau fail khusus klien pada pelayan yang mengisytiharkan LAN di belakang klien. Tanpanya, LAN jauh sama ada menggugurkan balasan atau menghantarnya ke get laluan lalainya sendiri, iaitu internet.

Terjemahan sumber ialah alternatif apabila awalan LAN tidak boleh diumumkan. Peraturan masquerade berskop pada klien menulis semula sumber kepada alamat terowong, dan balasan kemudian kembali secara semula jadi. Ia juga menyembunyikan hos LAN mana yang membuat permintaan, dan ia sendiri tidak membenarkan pihak jauh memulakan sambungan ke dalam. Pilih pertukaran itu dengan sengaja daripada menambah masquerade menyeluruh dan menemui kesan sampingannya kemudian.

Langkah 4: jadikan kedua-dua keputusan kekal, kemudian uji laluan sebenar

Setiap laluan mempunyai pemilik, dan pemiliknya ialah konfigurasi yang dijana semula semasa but atau semasa sambung semula. Pada penghala ia mungkin entri laluan statik; pada klien ia mungkin profil VPN, NetworkManager atau systemd-networkd. Sahkan dengan menyambung semula terowong dan memulakan semula klien, kemudian baca jadual itu semula dan bukan mempercayai suntingan itu.

Kekalkan utuh laluan lalai yang membawa sambungan luar terowong. Menggantikannya untuk “memudahkan” persediaan memecahkan laluan disulitkan sebelum mana-mana trafik dalam boleh menggunakannya, dan gejalanya ialah terowong yang tidak pernah terbentuk semula selepas perubahan itu.

Uji dari hos LAN biasa, bukan dari klien, kerana permintaan yang berasal dari klien tidak pernah menggunakan lompatan pertama penghala. Ambil perkhidmatan yang hanya wujud pada LAN jauh dan sahkan badan balasan, kemudian lihat pembilang atau log klien untuk melihat transit berlaku. traceroute dalaman yang menunjukkan lompatan persendirian membuktikan pemajuan, bukan penyulitan: laluan luar ialah pemerhatian berasingan, dan hanya pembilang antara muka terowong itu sendiri menunjukkan apa yang keluar melaluinya.