Mengapa LAN Anda tidak bisa menjangkau layanan di klien VPN

Tunnel Anda aktif, layanan mendengarkan, dan LAN kantor tetap tidak menerima apa pun kembali. Tidak ada yang merusak VPN. Dari sisi LAN, alamat tunnel laptop tidak ada sampai sesuatu memberi tahu LAN cara menjangkaunya, dan balasannya harus kembali melalui jalur yang sama dengan permintaan keluar. Saya pernah melihat orang membangun ulang tunnel yang sebenarnya sehat tiga kali sebelum ada yang melihat jalur balik.

Bukan tunnel yang rusak

Kedua ujung duduk di rentang privat, yang merupakan kasus normal dan bukan kesalahan konfigurasi. Alamat seperti 10.8.0.6 nyata di dalam tunnel dan tidak ada di tempat lain, jadi LAN tidak punya alasan mengirim apa pun ke sana. Sebelum menyentuh perutean, pastikan layanan benar-benar bisa dijangkau di dalam tunnel: di klien, ss -ltn menunjukkan apakah listener mengikat ke 127.0.0.1, ke antarmuka LAN, atau ke alamat tunnel. Daemon yang hanya terikat ke loopback tidak menjawab siapa pun kecuali dirinya sendiri, dan tidak ada rute, DNAT, atau penerusan port yang mengubah itu.

Proksi pada port 80 atau 443 adalah alat lain dengan visibilitas lain. Ia memindahkan permintaan, bukan paket, jadi itu lapisan yang salah untuk koneksi basis data mentah, dan menjangkaunya adalah cara masalah ini berakhir tiga alat lebih dalam sebelum ada yang mengukur apa pun.

Bentuk rute: beri tahu LAN di mana kumpulannya

Rute statis di gateway LAN adalah jawaban paling bersih ketika LAN dan kumpulan tunnel tidak tumpang tindih. Arahkan kumpulan ke mesin yang mengakhiri tunnel:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

Itu hanya memperbaiki satu arah, karena itu versi setengah jadi dari perubahan ini terlihat seperti kemajuan. Sisi tunnel membutuhkan separuh yang cocok, atau balasannya meninggalkan klien lewat rute default-nya sendiri dan mati di jalan:

push "route 192.168.1.0 255.255.255.0"

Untuk subnet yang berada di belakang satu klien dan bukan di belakang server, server membutuhkan rute sistem dan entri iroute di berkas klien itu di bawah client-config-dir. Tanpa iroute, OpenVPN tahu prefiks itu ada dan tidak tahu klien mana yang memilikinya: paket datang dan daemon tidak punya apa pun untuk mencocokkannya.

Inilah mitos yang layak diberi nama. Rute membuat alamat bisa dijangkau; rute tidak membuat sisi seberang bersedia menjawab. Rekan situs-ke-situs menambahkan lapisan lain di atasnya, karena gateway jauh hanya menerima sumber di dalam prefiks yang tercantum dalam kebijakannya, dan laptop yang datang dari kumpulan rumah tidak berada di dalamnya.

Bentuk NAT: DNAT masuk, dan baris SNAT yang semua orang lewati

Ketika Anda tidak bisa menyentuh gateway LAN, atau ingin menerbitkan tepat satu port, penerjemahan di host VPN bekerja tanpa rute apa pun di LAN. Terbitkan port, teruskan, dan terjemahkan sumbernya dalam perjalanan masuk ke tunnel:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

Baris ketiga adalah baris yang hilang. Lewati dan klien melihat alamat LAN asli sebagai sumber, menjawab lewat rute default-nya sendiri, dan jawaban itu masuk ke tunnel alih-alih kembali ke LAN. Apakah koneksi bertahan lalu bergantung pada perutean yang tidak pernah Anda rencanakan. Dengan SNAT klien melihat alamat tunnel server, sehingga balasan mengikuti tunnel kembali ke satu-satunya host yang bisa membatalkan penerjemahan.

Firmware konsumen memakai nama rantai sendiri dan tidak menghasilkan penerjemahan itu untuk Anda. Di Tomato, aturan masuk mendarat di WANPREROUTING lalu di rantai penyaring seperti wanin, dan kumpulan aturan yang tampak lengkap masih butuh baris POSTROUTING manual. Itu bukan bug firmware; itu kumpulan aturan yang ditulis hanya untuk lalu lintas masuk.

Mengapa aturan yang tampak benar tetap menjatuhkan paket

Sebagian besar kegagalan ini bukan pada aturan yang Anda tatap. Periksa empat hal dalam urutan ini, dan berhenti pada yang pertama yang tidak berlaku:

• Urutan rantai. iptables -I menyisipkan di atas dan -A menambahkan di akhir, jadi aturan yang mengizinkan atau memblokir lebih awal yang menentukan lebih dulu.
• Rantai salah. Lalu lintas yang dialamatkan ke router itu sendiri melewati INPUT, dan lalu lintas yang diteruskan tidak pernah menyentuhnya. Menerbitkan satu layanan bisa membutuhkan aturan di keduanya.
• Flag arah. -i tun0 cocok untuk lalu lintas yang datang dari klien dan -o tun0 untuk lalu lintas yang pergi ke mereka. REJECT dengan flag yang salah memblokir sesuatu yang tidak Anda maksud.
• Pembatasan sumber. Penerusan yang menerima satu alamat klien bekerja dari klien itu dan menjatuhkan setiap sumber lain tanpa sepatah kata.

Aturan dengan penghitung paket nol sama sekali tidak berada di jalur, dan membaca penghitung adalah cara tercepat memisahkan masalah rantai salah dari masalah aturan salah.

Penerusan lokal, ketika tidak ada yang bisa diubah di LAN

Penerusan lokal SSH menghindari seluruh pertanyaan. Ia tidak butuh rute di LAN, tidak butuh kerja sama dari firewall klien, dan tidak butuh port yang diterbitkan di mana pun:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

Layanan lalu muncul di localhost:3000 mesin yang menjalankan tunnel, dan tidak di tempat lain. Itulah batasnya: satu stasiun kerja, satu port, dan penerusan mati bersama sesi kecuali ada yang memulainya kembali. Bagi admin yang memeriksa basis data staging itu alat yang tepat. Bagi kamera atau pemindai yang harus dijangkau orang lain, bukan, karena setiap pengguna akan butuh penerusannya sendiri.

Verifikasi kedua arah sebelum menambah aturan lain

Penerjemahan meninggalkan jejak, dan membacanya lebih baik daripada menebak. Di host VPN, conntrack -L menunjukkan apakah penerjemahan terjadi, iptables -t nat -L -n -v menunjukkan apakah penghitung bergerak, dan tcpdump -ni any port 3000 menunjukkan alamat sumber mana yang benar-benar tiba. Di klien, ss -ltn memastikan listener berada di alamat yang bisa dijangkau tunnel.

Lalu pilih bentuk yang Anda pertahankan. Satu port yang diterbitkan, satu rute untuk seluruh kumpulan, dan satu penerusan untuk satu admin adalah tiga komitmen berbeda, dan mencampurnya adalah cara sebuah penyiapan yang bekerja menjadi penyiapan yang tidak bisa dijelaskan siapa pun enam bulan kemudian. Tuliskan alamat mana yang bisa dijangkau dari mana, dan orang berikutnya yang men-debug ini mulai dari jawabannya, bukan dari tunnelnya.