Teruskan port ke peer WireGuard di balik NAT: DNAT plus SNAT

Sebuah peramban meminta https://203.0.113.10:8443, proxy menerima koneksi, dan layanan di peer WireGuard tidak pernah menjawab. Aturan DNAT menjalankan tugasnya; balasan adalah bagian yang gagal. Ikuti paket melalui kedua terjemahan dan aturan yang hilang menjadi jelas. Perbaikannya adalah satu pernyataan NAT lagi di hook yang tepat, bukan tunnel baru.

Ikuti satu permintaan dari awal sampai akhir

Permintaan tiba di antarmuka publik proxy dengan alamat publik klien sebagai sumber dan alamat proxy sebagai tujuan. Di nat PREROUTING aturan DNAT menulis ulang tujuan ke alamat tunnel peer, 10.90.0.2. Keputusan perutean lalu mengirim paket keluar melalui wg0, dan jalur penerusan selesai.

Di peer, paket sekarang membawa alamat sumber publik asli, karena tidak ada yang menulis ulangnya. Layanan menerima koneksi dan mengirim balasannya ke gateway default-nya sendiri, yaitu router rumah di depan peer. Router itu tidak memiliki status untuk aliran yang tidak pernah dilihatnya dan entah membuang paket atau menerjemahkannya ke alamat publiknya sendiri, yang tidak akan diterima klien.

Asimetri adalah seluruh masalahnya: permintaan melewati proxy, dan balasan mencoba pergi langsung. Pelacakan koneksi proxy hanya membantu jika balasan kembali melalui proxy, dan balasan tidak dapat kembali ke sana selama alamat sumber masih menunjuk ke klien asli.

Tambahkan terjemahan balik

Tulis ulang sumber aliran yang diteruskan ke alamat tunnel proxy sebelum pergi ke peer. Layanan lalu membalas ke 10.90.0.1, proxy menerimanya, dan pelacakan koneksi membalik kedua terjemahan sebelum paket kembali ke klien.

iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

Aturan POSTROUTING sengaja sempit: aturan ini cocok dengan tujuan yang diterjemahkan dan antarmuka tunnel, sehingga tidak menulis ulang lalu lintas tak terkait yang kebetulan keluar melalui wg0. Aturan masquerade yang luas juga akan menyembunyikan alamat klien, tetapi akan melakukannya untuk setiap aliran dan membuat tabel NAT lebih sulit diaudit.

Letakkan aturan di tempat tunnel berada

Aturan yang merujuk alamat atau antarmuka tunnel harus berjalan setelah wg-quick mengonfigurasinya. Antarmuka dibuat sebelum PreUp, tetapi alamat, MTU, DNS, dan rute diterapkan sesudahnya, dan PostUp berjalan setelah semua itu ada. Letakkan penambahan di PostUp dan penghapusan di PreDown.

PostUp = iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PostUp = iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1
PreDown = iptables -t nat -D PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PreDown = iptables -t nat -D POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

Penghapusan harus cocok dengan penambahan token per token, termasuk kecocokan multiport dan antarmuka. Penghapusan yang berbeda satu kecocokan tidak menghapus apa pun, dan penyambungan berikutnya menambahkan salinan kedua aturan itu. Setelah beberapa penyambungan, tabel berisi duplikat yang sulit dikaitkan dengan baris konfigurasi.

Periksa hasilnya dengan iptables -t nat -S setelah penyambungan ulang. Jika aturan yang sama muncul dua kali, baris PreDown tidak cocok dan pembersihan gagal secara diam-diam.

Penerusan, penyaringan, dan NAT lainnya

Aktifkan penerusan IPv4 secara permanen, lalu izinkan aliran yang diteruskan di tabel filter. DNAT terjadi sebelum rantai FORWARD, jadi aturan filter cocok dengan tujuan yang diterjemahkan, bukan alamat publik. Jika UFW mengelola firewall, nyatakan izin sebagai aturan rute; aturan host biasa tidak mencakup lalu lintas yang diteruskan.

Dua lapisan NAT lain masih dapat memutus jalur bahkan ketika aturan proxy benar. Pada koneksi rumah, alamat publik milik router, dan membuka port di firewall-nya tidak sama dengan membuat entri penerusan port yang mengirim port itu ke proxy. Port yang tampak terbuka dari luar sementara tidak ada yang menjawab sering kali justru tidak memiliki pemetaan itu.

Pada VPS NAT, penyedia memetakan port publik ke alamat privat. Pemetaan harus sesuai dengan port yang Anda iklankan, dan ketidakcocokan terlihat sama seperti tunnel yang rusak. Konfirmasikan pemetaan penyedia sebelum mengubah konfigurasi WireGuard.

Verifikasi jalur balik dan terima biayanya

Sambungkan dari jaringan yang bukan LAN proxy, lalu periksa pasangan terjemahan selama koneksi terbuka:

conntrack -L -p tcp --dport 8080
tcpdump -ni any tcp port 8080

Entri conntrack seharusnya menunjukkan tuple asli, tuple yang diterjemahkan, dan arah balasan. Jika balasan tidak ada, peer tidak mengirim melalui tunnel, yang biasanya berarti aturan SNAT tidak diterapkan atau firewall peer sendiri membuang aliran itu.

Mulai ulang sekali untuk membuktikan PostUp menerapkan ulang aturan, lalu hentikan tunnel dan pastikan PreDown menghapusnya. Aturan mati yang bertahan setelah pemutusan koneksi adalah alasan perubahan berikutnya berperilaku tak terduga.

Akhirnya, terimalah biaya SNAT. Layanan melihat setiap permintaan datang dari proxy, sehingga log akses, batas laju per klien, dan daftar alamat yang diizinkan tidak lagi membedakan pengguna. Kasus hairpin membutuhkan terjemahan sumber sendiri bagi klien di LAN proxy. Jika peer membutuhkan alamat klien yang sebenarnya, alternatifnya adalah rute balik ke jaringan klien, yang lebih banyak pekerjaan tetapi mempertahankan informasi.