Klien VPN sampai ke pelayan tetapi tidak ke LAN: pembaikan mana?

Klien membuat ping ke alamat terowong pelayan OpenVPN dan menerima jawapan, kemudian mencuba hos di LAN pelayan itu dan tidak menerima apa-apa. Pemisahan ini menyempitkan kerosakan dengan jelas: terowong sudah naik, penghantaran mungkin berfungsi, dan jawapan keluar melalui pintu yang tidak membawa pulang. Ada tiga pembaikan, dan yang betul bergantung pada apa yang anda kawal dan apa yang sanggup anda lepaskan. Jawab tiga soalan di bawah mengikut urutan dan pilihan itu bukan lagi soal selera.

Pertama, pastikan arah mana yang rosak

Permintaan tiba di antara muka terowong dengan alamat sumber daripada kumpulan VPN. Pelayan memajukannya ke hos di LAN, dan hos itu menjawab get laluan yang dinamakan jadualnya sendiri, biasanya penghala LAN. Jika penghala tiada laluan ke kumpulan itu, jawapan mati di situ atau merayau ke arah internet.

Uji kedua-dua mesin sebelum mengubah mana-mana satu. Tanya jadual penghalaan di pelayan bagaimana ia akan sampai ke klien; tanya hos di LAN bagaimana ia akan sampai ke alamat yang sama. Carian pertama biasanya menunjuk terowong dan yang kedua menunjuk penghala LAN, dan perbezaan itulah kerosakan dalam satu baris. Dua carian lebih murah daripada audit tembok api dan kedua-duanya menetapkan arah masalah.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Jika hos di LAN sudah menunjuk pelayan VPN, masalah anda ialah peraturan tembok api atau had MTU, bukan laluan balik yang hilang. Jangan tambah laluan untuk membetulkan penapis.

Soalan satu: bolehkah anda mengedit penghala LAN jauh itu?

Apabila penghala LAN itu milik anda, jawapan bersihnya ialah laluan statik ke kumpulan VPN dengan alamat LAN pelayan VPN sebagai lompatan seterusnya. Ia mengekalkan alamat sumber klien, yang penting apabila hos di LAN merekod, menapis atau mengehadkan kadar mengikut alamat. Ia juga tidak memerlukan penterjemahan di pelayan, jadi terowong kekal sebagai laluan penghalaan tulen. Kewajipan yang diciptanya ialah dokumentasi, kerana kumpulan, laluan dan konfigurasi pelayan mesti sepadan.

Ia gagal secara senyap pada hari seseorang menukar kumpulan itu. Tulis nilainya sekali dan anggap suntingan di mana-mana satu daripada tiga tempat sebagai suntingan pada ketiga-tiganya.

NAS atau suis Layer 3 yang menghoskan perkhidmatan itu memerlukan laluan yang sama, melainkan ia menghantar semuanya melalui penghala yang memilikinya. Periksa peranti yang menamatkan subrangkaian, bukan hanya yang menghadap internet. Rangkaian kecil selalunya ada tiga peranti yang ada pendapat tentang penghalaan.

Soalan dua: bolehkah LAN berhenti melihat alamat klien?

Apabila penghala itu milik orang lain, penterjemahan di pelayan VPN tidak memerlukan kerjasama. Hos di LAN melihat alamat LAN pelayan, menjawabnya, dan pelayan menterjemah balik. Itulah sebabnya perkakas dan peranan capaian jauh berasaskan NAT berkelakuan begitu.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Kosnya ialah atribusi: alamat setiap klien hilang daripada log LAN. Senarai kebenaran mana-mana di hos LAN kemudiannya mesti menamakan pelayan dan bukan kumpulan.

Pilih penterjemahan apabila kerjasama tiada, bukan apabila ia hanya menyusahkan. Ia menyembunyikan klien daripada setiap siasatan akan datang, termasuk yang memerlukan anda tahu komputer riba mana yang membuka sambungan. Ia juga boleh merosakkan protokol yang membenamkan alamat dalam muatan, kerana penterjemahan hidup di pengepala. Tiada pilihan yang lebih maju; kedua-duanya menjawab soalan berbeza tentang pemilikan.

Soalan tiga: adakah pelayan itu sendiri klien kepada terowong lain?

Bayangkan topologi yang lain: pelayan VPN juga mendail penyedia komersial, jadi ia mempunyai dua terowong dan dua set alamat. Trafik yang dimajukannya untuk kliennya sendiri keluar melalui penyedia itu, dan penyedia tidak akan menghalakan jawapan balik ke alamat kumpulan itu. Itulah sebabnya jawapan hilang walaupun kedua-dua terowong sihat.

Pembaikannya ialah menyamarkan terowong keluar juga, supaya penyedia hanya melihat alamat terowong pelayan. Arah sebaliknya memerlukan peraturannya sendiri, kerana pelayan yang memulakan sambungan ke salah satu kliennya sendiri ialah aliran berbeza. Tanpa peraturan itu klien menjawab alamat yang tidak dapat dihalakannya. Letakkan peraturan sempit sebelum mana-mana penyamaran luas supaya penterjemahan khusus menang.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Hos berbilang antara muka menambah kerosakan berkaitan yang kelihatan sama dari sisi klien. Jawapan keluar melalui antara muka dengan metrik lebih rendah kerana alamat sumber dipilih daripada jadual lain. Periksa laluan balik dengan carian dan jangan anggap laluan pergi sudah merangkuminya.

Kemudian sahkan kedua-dua arah dan kedua-dua saiz

Selepas perubahan, ping dari klien ke hos di LAN dan kemudian dari hos di LAN ke klien. Arah kedua itulah yang orang langkau, dan itulah yang mendedahkan peraturan penterjemahan yang tidak lengkap. Catat kedua-dua hasil dengan cap masa supaya regresi kemudian boleh dibandingkan.

Kemudian pindahkan data sebenar, kerana ping kecil yang berjaya sementara pemindahan besar tersekat ialah gejala MTU. Kerosakan itu muncul sejurus selepas anda mengucapkan tahniah kepada diri sendiri kerana membaiki laluan itu.

Akhir sekali, uji semula selepas but semula. Perintah laluan dan tembok api semasa berjalan tidak bertahan melaluinya, dan pembaikan yang hilang pada but berikutnya akan didiagnosis semula oleh seseorang dengan konteks lebih sedikit. Jadikan perubahan itu kekal dengan cara sistem anda sudah melakukannya, kemudian but semula sekali dengan sengaja.