Terbitkan perkhidmatan LAN pada alamat gateway VPN itu sendiri

Mempersembahkan peranti LAN pada salah satu alamat terowong gateway itu sendiri hanya memerlukan satu baris NAT. Sambungan masih gagal, kerana peranti yang menjawab tidak tahu bahawa alamat klien boleh dicapai melalui gateway itu. Jejaki paket daripada klien ke dalam, kemudian jejaki balasan kembali ke luar, dan separuh yang hilang menjadi jelas.

Mulakan daripada pandangan klien

Klien dalam contoh ini berada dalam kolam VPN 10.62.0.0/24 dan bersambung ke 10.62.0.1 pada port 8080. Alamat itu milik gateway itu sendiri, jadi paket tiba di kernel gateway dan bukan di rakan sebaya lain. Di belakang gateway, LAN ialah 172.21.4.0/24. Gateway memegang 172.21.4.10 dan peranti yang benar-benar menyediakan HTTP ialah 172.21.4.40.

Alamat yang dimiliki oleh rakan VPN lain tidak boleh ditukar ganti dengan alamat perkhidmatan gateway. Jika klien bersambung ke alamat rakan, tiada peraturan gateway terlibat sama sekali, dan seluruh penjelajahan ini adalah kes yang salah.

Hadkan terjemahan destinasi dengan sengaja

Versi sempit mempersembahkan satu port dan menulis semula destinasi sahaja. Paket mengekalkan protokol dan sumbernya, dan itulah yang menjadikan baki perjalanan menarik.

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

Peraturan tanpa kriteria protokol dan port ialah versi luas: ia mengekalkan mana-mana port yang dipilih klien dan hanya menukar alamat. Itu sah apabila seluruh hos hendak dipersembahkan, dan salah apabila satu perkhidmatan menjadi niat. Baca semula peraturan itu dan sahkan nama antara muka. Peraturan DNAT pada antara muka yang salah tidak sepadan dengan apa-apa, yang menghasilkan tamat masa yang sama seperti peraturan yang tiada dan membazir satu jam memandang peranti.

Biarkan sempadan pemajuan bersetuju

Terjemahan menukar pengepala, ia tidak memberi kebenaran. Dengan dasar buang lalai, aliran yang dimajukan memerlukan penerimaannya sendiri, dan arah balik memerlukan peraturan sambungan mantap yang dasar anda mungkin sudah ada.

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Penerimaan tanpa syarat untuk setiap aliran DNAT lebih luas daripada reka bentuk ini dan juga akan membenarkan pemetaan yang ditambah kemudian oleh orang lain. Namakan destinasi dan port, dan biarkan selebihnya tertutup. Jika pembilang pada peraturan pemajuan kekal sifar sementara pembilang NAT meningkat, paket dibuang sebelum peraturan anda. Baca susunan rantai dan bukannya menambah salinan kedua.

Peranti mesti menjawab dengan sesuatu cara

Selepas terjemahan peranti melihat sumber dalam 10.62.0.0/24. Balasannya pergi ke gateway lalainya, iaitu penghala LAN, bukan gateway VPN, melainkan ada sesuatu yang memberitahunya sebaliknya. Dua susunan membaikinya dan kedua-duanya tidak setara. Laluan pada peranti atau pada penghala LAN menghantar 10.62.0.0/24 ke 172.21.4.10 sambil mengekalkan sumber klien. Terjemahan sumber terhad pula menyembunyikan klien di belakang alamat LAN gateway.

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

Pilih mengikut apa yang diperlukan oleh perkhidmatan. Dasar setiap klien dan log yang bermakna mahukan bentuk yang dihalakan; peranti yang tidak boleh diberi laluan, atau perkhidmatan yang semestinya perlu melihat alamat LAN, menunjuk ke bentuk yang diterjemah. Jangan mencapai peraturan masquerade global untuk membuat satu balasan berfungsi. Ia menyembunyikan setiap klien daripada setiap destinasi dan memecahkan secara senyap dasar yang bergantung pada alamat sumber.

Jangan uji dari gateway itu sendiri

Permintaan yang dijana pada gateway ke 10.62.0.1 keluar melalui rantai OUTPUT, bukan melalui PREROUTING yang masuk. Kegagalan atau kejayaannya tidak berkata apa-apa tentang peraturan yang menghadap klien, dan begitulah orang membuat kesimpulan bahawa peraturan yang berfungsi sudah rosak.

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

Jalankan permintaan klien sebenar dan baca kedua-duanya. Entri conntrack menunjukkan terjemahan yang digunakan, dan tangkapan menunjukkan sama ada permintaan melintas ke LAN dan sama ada balasan kembali ke arah terowong. Gunakan sambungan baharu selepas menukar peraturan, kerana keadaan sedia ada menyimpan pemetaan sebelumnya dan akan terus gagal dengan cara lama. Kemudian sahkan seluruh perbualan: alamat peranti, kebenaran pemajuan dan laluan balasan semuanya menerangkan aliran yang sama.