Menerbitkan layanan LAN pada alamat gateway VPN itu sendiri
Telusuri port yang diteruskan dari klien ke perangkat dan kembali: batasi penerjemahan tujuan, lalu putuskan apakah balasan dirutekan atau diterjemahkan.
Menyajikan perangkat LAN pada salah satu alamat terowongan milik gateway hanya perlu satu baris NAT. Koneksi tetap gagal, karena perangkat yang menjawab tidak tahu bahwa alamat klien dapat dijangkau melalui gateway itu. Telusuri paket dari klien ke dalam, lalu telusuri balasan kembali ke luar, dan separuh yang hilang menjadi jelas.
Mulailah dari sudut pandang klien
Klien dalam contoh ini berada di kumpulan VPN 10.62.0.0/24 dan terhubung ke 10.62.0.1 pada port 8080. Alamat itu milik gateway itu sendiri, jadi paket tiba di kernel gateway, bukan di peer lain. Di belakang gateway, LAN adalah 172.21.4.0/24. Gateway memegang 172.21.4.10 dan perangkat yang benar-benar melayani HTTP adalah 172.21.4.40.
Alamat milik peer VPN lain tidak dapat dipertukarkan dengan alamat layanan gateway. Jika klien terhubung ke alamat peer, tidak ada aturan gateway yang terlibat sama sekali, dan seluruh penelusuran ini adalah kasus yang salah.
Batasi penerjemahan tujuan secara sengaja
Versi sempit menyajikan satu port dan hanya menulis ulang tujuan. Paket mempertahankan protokol dan sumbernya, dan itulah yang membuat sisa penelusuran 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
Aturan tanpa kriteria protokol dan port adalah versi luas: aturan ini mempertahankan port apa pun yang dipilih klien dan hanya mengubah alamat. Itu sah ketika seluruh host ingin disajikan, dan salah ketika satu layanan adalah maksudnya. Baca kembali aturan itu dan pastikan nama antarmuka. Aturan DNAT pada antarmuka yang salah tidak cocok dengan apa pun, yang menghasilkan batas waktu sama seperti aturan yang hilang dan membuang satu jam untuk melihat perangkat.
Biarkan batas penerusan setuju
Penerjemahan mengubah tajuk, bukan memberi izin. Dengan kebijakan buang bawaan, aliran yang diteruskan membutuhkan penerimaan sendiri, dan arah balik membutuhkan aturan koneksi mapan yang kebijakan Anda mungkin sudah punya.
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 rancangan ini dan juga akan mengizinkan pemetaan yang ditambahkan nanti oleh orang lain. Sebutkan tujuan dan port, dan biarkan sisanya tetap tertutup. Jika penghitung pada aturan penerusan tetap nol sementara penghitung NAT naik, paket dibuang sebelum aturan Anda. Baca urutan rantai alih-alih menambahkan salinan kedua.
Perangkat harus menjawab dengan cara tertentu
Setelah penerjemahan, perangkat melihat sumber di 10.62.0.0/24. Balasannya menuju gateway bawaan, yaitu router LAN, bukan gateway VPN, kecuali ada sesuatu yang memberi tahu sebaliknya. Dua penataan memperbaikinya, dan keduanya tidak setara. Rute pada perangkat atau pada router LAN mengirim 10.62.0.0/24 ke 172.21.4.10 dengan mempertahankan sumber klien. Penerjemahan sumber yang terbatas menyembunyikan klien di balik 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 menurut kebutuhan layanan. Kebijakan per klien dan log yang bermakna menginginkan bentuk yang dirutekan; perangkat yang tidak dapat diberi rute, atau layanan yang memang harus melihat alamat LAN, menunjuk ke bentuk yang diterjemahkan. Jangan menjangkau aturan masquerade global agar satu balasan berfungsi. Aturan itu menyembunyikan setiap klien dari setiap tujuan dan diam-diam merusak kebijakan yang bergantung pada alamat sumber.
Jangan menguji dari gateway itu sendiri
Permintaan yang dibuat di gateway ke 10.62.0.1 keluar melalui rantai OUTPUT, bukan melalui PREROUTING yang masuk. Kegagalan atau keberhasilannya tidak mengatakan apa pun tentang aturan yang menghadap klien, dan begitulah orang menyimpulkan aturan yang berfungsi rusak.
conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'
Jalankan permintaan klien sungguhan dan baca keduanya. Entri conntrack menunjukkan penerjemahan yang diterapkan, dan tangkapan menunjukkan apakah permintaan menyeberang ke LAN dan apakah balasan kembali ke arah terowongan. Gunakan koneksi baru setelah mengubah aturan, karena status yang ada menyimpan pemetaan sebelumnya dan akan terus gagal dengan cara lama. Lalu pastikan seluruh percakapan: alamat perangkat, izin penerusan, dan rute balasan semuanya menjelaskan aliran yang sama.