Klien OpenVPN mencapai server tetapi tidak host LAN: daftar periksa

Klien bilang terhubung, alamat tunnel menjawab ping, dan tidak ada yang merespons di LAN kantor. Saya melihat ini setelah hampir setiap pembaruan klien, dan naluri pertama adalah membuka firewall, yang biasanya langkah keliru: tunnel baik-baik saja, dan putusnya ada di salah satu dari tiga lompatan yang harus dilewati paket. Telusuri jalur sesuai urutan yang diambil paket, pertama rute klien, lalu penerusan di server, lalu perjalanan balik, dan Anda akan menemukan pemilik kesalahan dalam beberapa menit.

Langkah satu: amati keputusan perutean klien

Sebelum menyentuh server, buktikan bahwa klien mengirim paket ke tunnel. Tanyakan ke kernel antarmuka mana yang akan dipakai untuk satu host LAN tertentu, alih-alih membaca seluruh tabel:

ip route get 192.168.50.10

Jika jawabannya menyebut adaptor fisik dan gateway kantor Anda, tidak ada perubahan di sisi server yang bisa membantu. OpenVPN hanya membagikan rute saat server mendorongnya, jadi cari push "route 192.168.50.0 255.255.255.0" di konfigurasi server, lalu sambungkan ulang klien setelahnya. Sebagian besar klien menerapkan rute yang didorong saat terhubung, bukan saat Anda memuat ulang profil.

Di Windows pertanyaan yang sama punya perintah lain. Find-NetRoute -RemoteIPAddress 192.168.50.10 mencetak antarmuka dan lompatan berikutnya yang akan dipilih tumpukan, dan route print -4 menunjukkan apakah prefiks yang didorong ada sama sekali.

Langkah dua: pastikan server akan meneruskan paket

Jika rute klien benar, paket sampai ke server dan server harus setuju meneruskannya. Sakelar kernel adalah gerbang pertama, dan sysctl net.ipv4.ip_forward harus mengembalikan 1. Menyetelnya dengan echo 1 > /proc/sys/net/ipv4/ip_forward bertahan sampai reboot berikutnya, dan itulah tepatnya sebabnya keluhan yang sama kembali berminggu-minggu kemudian.

Tuliskan di tempat yang bertahan setelah restart:

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

Gerbang kedua adalah tabel filter. Host yang terpasang Docker sering membawa kebijakan FORWARD bernilai DROP, dan tunnel mewarisi keputusan itu. iptables -L FORWARD -v -n menampilkan kebijakan sekaligus penghitung paket; jika kebijakannya DROP, penerusan membutuhkan izin eksplisit untuk arah tunnel ke LAN dan satu lagi untuk balasannya.

Langkah tiga: ikuti paket ke LAN dan cari balasannya

Pantau kedua sisi server sekaligus. Tangkap di tunnel dan di antarmuka LAN, disaring ke satu klien dan satu host agar keluarannya tetap terbaca:

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

Permintaan yang muncul di tun0 dan lagi di eth0 dengan sumber 10.8.0.x, lalu sunyi, berarti paket tiba dan balasannya pergi ke tempat lain. Host LAN membalas ke gateway bawaannya, gateway itu tidak punya rute untuk kumpulan VPN, dan balasannya mati di router LAN. Mem-ping host LAN dari server tidak membuktikan apa pun tentang jalur ini, karena lalu lintas itu tidak pernah melintasi tunnel.

Langkah empat: pilih antara translasi dan rute balik

Dua perbaikan menutup celahnya, dan pilihannya punya akibat di luar apakah ping berfungsi. Translasi sumber membuat server menjadi pengirim yang tampak:

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

Batasi aturan ke kumpulan dan antarmuka LAN, lalu jadikan permanen, atau pemuatan ulang firewall berikutnya diam-diam menghapus perbaikan Anda. Harganya adalah identitas: setiap klien tampak seperti server VPN di log LAN dan aturan akses, dan per-client policy becomes guesswork.

Rute statis untuk 10.8.0.0/24 di router LAN, menunjuk ke server VPN, menjaga alamat klien tetap terlihat dan merupakan jawaban jangka panjang yang lebih baik ketika router itu milik Anda. Banyak situs menjalankan keduanya untuk sementara, NAT untuk perbaikan segera dan rutenya setelah kebijakan firewall ditulis. Jika server adalah peer site-to-site dan bukan kumpulan, sisi server juga memerlukan iroute untuk subnet jarak jauh, kalau tidak rute peer ada tetapi lalu lintas klien tidak pernah dikaitkan dengannya.

Langkah lima: verifikasi dari klien dan catat apa yang berubah

Tutup lingkarannya dari klien, bukan dari server. Sambungkan ke layanan nyata di host LAN, lalu pastikan penghitung translasi bergerak dengan iptables -t nat -L POSTROUTING -v -n, karena aturan tanpa paket adalah aturan yang tidak pernah cocok. conntrack -L -s 10.8.0.5 menunjukkan aliran dan keadaannya saat Anda butuh bukti bahwa arah balik dilacak.

Tinggalkan catatan di konfigurasi server: subnet mana, antarmuka mana, aturan mana, dan apakah router LAN membawa rute balik. Saat pembaruan klien berikutnya menghapus rute yang didorong, catatan itu mengubah sesi pemadaman menjadi perbaikan satu baris.