Klien OpenVPN sampai ke pelayan tetapi bukan hos LAN: senarai semak

Klien berkata bersambung, alamat terowong menjawab ping, dan tiada apa di LAN pejabat menjawab. Saya melihat ini selepas hampir setiap peningkatan klien, dan naluri pertama ialah membuka firewall, yang biasanya langkah salah: terowong baik, dan putusnya ada pada salah satu daripada tiga hop yang paket mesti lalui. Ikut laluan mengikut urutan paket, dahulu laluan klien, kemudian penghantaran pelayan, kemudian perjalanan balik, dan anda akan temui punca kerosakan dalam beberapa minit.

Langkah satu: perhatikan keputusan penghalaan klien

Sebelum menyentuh pelayan, buktikan klien menghantar paket ke dalam terowong. Tanya kernel antara muka mana yang akan digunakan untuk satu hos LAN tertentu, bukan membaca seluruh jadual:

ip route get 192.168.50.10

Jika jawapan menyebut penyesuai fizikal dan gerbang pejabat anda, tiada perubahan di sisi pelayan boleh membantu. OpenVPN hanya mengagihkan laluan apabila pelayan menolaknya, jadi cari push "route 192.168.50.0 255.255.255.0" dalam konfigurasi pelayan, dan sambungkan semula klien selepas itu. Kebanyakan klien menggunakan laluan yang ditolak semasa bersambung, bukan semasa anda memuat semula profil.

Pada Windows soalan yang sama mempunyai arahan lain. Find-NetRoute -RemoteIPAddress 192.168.50.10 mencetak antara muka dan hop seterusnya yang akan dipilih oleh tindanan, dan route print -4 menunjukkan sama ada awalan yang ditolak wujud langsung.

Langkah dua: sahkan pelayan akan menghantar paket itu

Jika laluan klien betul, paket sampai ke pelayan dan pelayan mesti bersetuju menghantarnya. Suis kernel ialah pintu pertama, dan sysctl net.ipv4.ip_forward mesti mengembalikan 1. Menetapkannya dengan echo 1 > /proc/sys/net/ipv4/ip_forward berfungsi sehingga but semula seterusnya, dan itulah sebabnya aduan yang sama kembali beberapa minggu kemudian.

Tuliskan di tempat yang bertahan selepas mula semula:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

Pintu kedua ialah jadual penapis. Hos dengan Docker dipasang selalunya membawa dasar FORWARD bernilai DROP, dan terowong mewarisi keputusan itu. iptables -L FORWARD -v -n menunjukkan dasar dan pembilang paket; jika dasarnya DROP, penghantaran memerlukan kebenaran jelas untuk arah terowong ke LAN dan satu lagi untuk balasan.

Langkah tiga: ikut paket ke LAN dan cari balasan

Perhatikan kedua-dua sisi pelayan serentak. Tangkap pada terowong dan pada antara muka LAN, ditapis kepada satu klien dan satu hos supaya output kekal boleh dibaca:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Permintaan yang muncul pada tun0 dan sekali lagi pada eth0 dengan sumber 10.8.0.x, diikuti kesunyian, bermakna paket tiba dan balasan pergi ke tempat lain. Hos LAN membalas gerbang lalainya, gerbang itu tiada laluan untuk kumpulan VPN, dan balasan mati pada penghala LAN. Ping hos LAN dari pelayan tidak membuktikan apa-apa tentang laluan ini, kerana trafik itu tidak pernah melintasi terowong.

Langkah empat: pilih antara terjemahan dan laluan balik

Dua pembaikan menutup lubang itu, dan pilihan ini mempunyai kesan di luar sama ada ping berfungsi. Terjemahan sumber menjadikan pelayan sebagai pengirim yang kelihatan:

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

Hadkan peraturan kepada kumpulan dan antara muka LAN, kemudian jadikannya kekal, jika tidak muat semula firewall seterusnya akan membuang pembaikan anda secara senyap. Kosnya ialah identiti: setiap klien kelihatan seperti pelayan VPN dalam log LAN dan peraturan akses, dan per-client policy becomes guesswork.

Laluan statik untuk 10.8.0.0/24 pada penghala LAN, menunjuk ke pelayan VPN, memastikan alamat klien kelihatan dan merupakan jawapan jangka panjang yang lebih baik apabila penghala itu milik anda. Banyak tapak menjalankan kedua-duanya untuk seketika, NAT untuk pembaikan segera dan laluan selepas dasar firewall ditulis. Jika pelayan ialah rakan site-to-site dan bukan kumpulan, sisi pelayan juga memerlukan iroute untuk subnet jauh, jika tidak laluan rakan wujud tetapi trafik klien tidak pernah dikaitkan dengannya.

Langkah lima: sahkan dari klien dan catat apa yang berubah

Tutup gelung dari klien, bukan dari pelayan. Sambung ke perkhidmatan sebenar pada hos LAN, kemudian sahkan pembilang terjemahan bergerak dengan iptables -t nat -L POSTROUTING -v -n, kerana peraturan tanpa paket ialah peraturan yang tidak pernah sepadan. conntrack -L -s 10.8.0.5 menunjukkan aliran dan keadaannya apabila anda perlukan bukti bahawa arah balik dijejaki.

Tinggalkan nota dalam konfigurasi pelayan: subnet mana, antara muka mana, peraturan mana, dan sama ada penghala LAN membawa laluan balik. Kali seterusnya peningkatan klien memadam laluan yang ditolak, nota itu menukar sesi memadam kebakaran menjadi pembaikan satu baris.