Mengapa LAN anda tidak dapat mencapai perkhidmatan pada klien VPN

Tunnel anda aktif, perkhidmatan mendengar, dan LAN pejabat masih tidak menerima apa-apa balik. Tiada siapa merosakkan VPN. Dari sisi LAN, alamat tunnel komputer riba tidak wujud sehingga sesuatu memberitahu LAN cara mencapainya, dan balasan mesti kembali melalui jalan yang sama dengan permintaan keluar. Saya pernah melihat orang membina semula tunnel yang sempurna sihat tiga kali sebelum ada orang melihat laluan balik.

Bukan tunnel yang rosak

Kedua-dua hujung duduk pada julat peribadi, yang merupakan kes biasa dan bukan salah konfigurasi. Alamat seperti 10.8.0.6 nyata di dalam tunnel dan tidak wujud di tempat lain, jadi LAN tiada sebab menghantar apa-apa ke sana. Sebelum menyentuh penghalaan, pastikan perkhidmatan boleh dicapai di dalam tunnel: pada klien, ss -ltn menunjukkan sama ada pendengar terikat pada 127.0.0.1, antara muka LAN atau alamat tunnel. Daemon yang terikat hanya pada loopback tidak menjawab sesiapa kecuali dirinya sendiri, dan tiada laluan, DNAT atau pemajuan port mengubahnya.

Proksi pada port 80 atau 443 ialah alat lain dengan keterlihatan lain. Ia memindahkan permintaan, bukan paket, jadi ia lapisan yang salah untuk sambungan pangkalan data mentah, dan mencapai ke arahnya ialah cara masalah ini berakhir tiga alat lebih dalam sebelum sesiapa mengukur apa-apa.

Bentuk laluan: beritahu LAN di mana kolam itu

Laluan statik pada gateway LAN ialah jawapan paling bersih apabila LAN dan kolam tunnel tidak bertindih. Halakan kolam ke mesin yang menamatkan 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 membaiki satu arah, sebab itu versi separuh siap perubahan ini kelihatan seperti kemajuan. Sisi tunnel memerlukan separuh yang sepadan, jika tidak balasan meninggalkan klien melalui laluan lalainya sendiri dan mati dalam perjalanan:

push "route 192.168.1.0 255.255.255.0"

Bagi subnet yang berada di belakang satu klien dan bukan di belakang pelayan, pelayan memerlukan laluan sistem dan entri iroute dalam fail klien itu di bawah client-config-dir. Tanpa iroute, OpenVPN tahu awalan itu wujud dan tidak tahu klien mana yang memilikinya: paket tiba dan daemon tiada apa-apa untuk memadankannya.

Inilah mitos yang wajar diberi nama. Laluan menjadikan alamat boleh dicapai; ia tidak menjadikan pihak bertentangan bersedia menjawab. Rakan situs-ke-situs menambah lapisan lain di atasnya, kerana gateway jauh hanya menerima sumber di dalam awalan dalam dasarnya, dan komputer riba yang datang dari kolam rumah tidak berada di dalamnya.

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

Apabila anda tidak boleh menyentuh gateway LAN, atau ingin menerbitkan tepat satu port, penterjemahan pada hos VPN berfungsi tanpa sebarang laluan pada LAN. Terbitkan port, majukannya, dan terjemahkan sumber 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 ialah baris yang hilang. Langkau dan klien melihat alamat LAN asal sebagai sumber, menjawab melalui laluan lalainya sendiri, dan jawapan itu masuk ke tunnel dan bukannya balik ke LAN. Sama ada sambungan bertahan kemudian bergantung pada penghalaan yang anda tidak pernah rancang. Dengan SNAT klien melihat alamat tunnel pelayan, jadi balasan mengikut tunnel balik ke satu-satunya hos yang boleh membatalkan penterjemahan itu.

Firmware pengguna menggunakan nama rantai sendiri dan tidak menjana penterjemahan itu untuk anda. Pada Tomato, peraturan masuk mendarat di WANPREROUTING dan kemudian dalam rantai penapis seperti wanin, dan set peraturan yang kelihatan lengkap masih memerlukan baris POSTROUTING manual. Itu bukan pepijat firmware; itu set peraturan yang ditulis hanya untuk trafik masuk.

Mengapa peraturan yang kelihatan betul masih menggugurkan paket

Kebanyakan kegagalan ini bukan pada peraturan yang anda tenung. Semak empat perkara dalam urutan ini, dan berhenti pada yang pertama yang tidak berlaku:

• Urutan rantai. iptables -I menyisip di atas dan -A menambah di hujung, jadi peraturan yang membenarkan atau menyekat lebih awal yang menentukan dahulu.
• Rantai salah. Trafik yang dialamatkan kepada penghala itu sendiri melalui INPUT, dan trafik yang dimajukan tidak pernah menyentuhnya. Menerbitkan satu perkhidmatan mungkin memerlukan peraturan dalam kedua-duanya.
• Bendera arah. -i tun0 sepadan dengan trafik yang datang dari klien dan -o tun0 trafik yang keluar ke arah mereka. REJECT dengan bendera yang salah menyekat sesuatu yang anda tidak maksudkan.
• Pengehadan sumber. Pemajuan yang menerima satu alamat klien berfungsi dari klien itu dan menggugurkan setiap sumber lain tanpa sepatah kata.

Peraturan dengan pembilang paket sifar langsung tiada dalam laluan, dan membaca pembilang ialah cara terpantas memisahkan masalah rantai salah daripada masalah peraturan salah.

Pemajuan setempat, apabila tiada apa-apa di LAN boleh diubah

Pemajuan setempat SSH mengelak seluruh persoalan. Ia tidak memerlukan laluan di LAN, kerjasama daripada tembok api klien, dan port yang diterbitkan di mana-mana:

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

Perkhidmatan kemudian muncul pada localhost:3000 mesin yang memegang tunnel, dan tidak di tempat lain. Itulah sempadannya: satu stesen kerja, satu port, dan pemajuan mati bersama sesi melainkan sesuatu memulakannya semula. Bagi pentadbir yang memeriksa pangkalan data staging, ia alat yang betul. Bagi kamera atau pengimbas yang perlu dicapai orang lain, ia bukan, kerana setiap pengguna memerlukan pemajuannya sendiri.

Sahkan kedua-dua arah sebelum menambah peraturan lain

Penterjemahan meninggalkan kesan, dan membacanya lebih baik daripada meneka. Pada hos VPN, conntrack -L menunjukkan sama ada penterjemahan berlaku, iptables -t nat -L -n -v menunjukkan sama ada pembilang bergerak, dan tcpdump -ni any port 3000 menunjukkan alamat sumber mana yang benar-benar tiba. Pada klien, ss -ltn mengesahkan pendengar berada pada alamat yang boleh dicapai oleh tunnel.

Kemudian pilih bentuk yang anda kekalkan. Satu port yang diterbitkan, satu laluan untuk seluruh kolam, dan satu pemajuan untuk seorang pentadbir ialah tiga komitmen berbeza, dan mencampurkannya ialah cara satu persediaan yang berfungsi menjadi persediaan yang tiada siapa boleh jelaskan enam bulan kemudian. Tuliskan alamat mana yang boleh dicapai dari mana, dan orang seterusnya yang menyahpepijat ini bermula dari jawapan dan bukan dari tunnel.