WireGuard DNS DNAT: jaga jalur balasan tetap bekerja

DNAT menulis ulang tujuan, bukan sumber. Putuskan bagaimana resolver hulu dapat menjawab sebelum menambahkan aturan, dan jaga setiap kecocokan tetap sempit.

Mengarahkan kueri DNS klien WireGuard ke resolver lain tampak seperti satu aturan dan berperilaku seperti tiga keputusan. Tujuan harus ditulis ulang, paket harus diteruskan, dan jawaban harus menemukan jalannya kembali melalui status terjemahan yang dibuat gateway. Lewatkan yang ketiga dan kueri keluar dengan bersih sementara klien menunggu selamanya.

Ambil contoh klien yang diizinkan di 10.77.0.0/24 yang datang melalui wg0, menanyakan alamat yang diiklankan 10.77.0.1 dan membutuhkan resolver di 203.0.113.53. Alamat hulu adalah placeholder dokumentasi, bukan layanan yang berfungsi.

Mengalihkan kueri hanya mengubah tujuannya

Aturan NAT tujuan di PREROUTING menulis ulang alamat sebelum keputusan perutean dibuat, sehingga paket kemudian dirutekan ke tujuan baru alih-alih yang lama. Alamat sumber klien tidak tersentuh oleh operasi itu. Itu sebabnya aturan yang tampak lengkap masih bisa menghasilkan kesunyian: permintaan kini berjalan ke resolver yang tidak pernah mendengar tentang rentang privat klien. Gateway menerjemahkan satu bidang dan mewarisi masalah kedua.

Kedua transport DNS memerlukan aturan yang cocok, karena klien beralih ke TCP ketika jawaban dipotong.

Aturan di bawah memilih satu antarmuka masuk, satu rentang klien, dan satu alamat tujuan asli. Tidak ada hal lain di gateway yang terpengaruh, dan kueri dari gateway itu sendiri sama sekali tidak cocok.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p udp --dport 53 -j DNAT --to-destination 203.0.113.53:53
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p tcp --dport 53 -j DNAT --to-destination 203.0.113.53:53

Jalur balasan adalah keputusan terpisah

Dua pengaturan memungkinkan jawaban kembali, dan memilih satu lebih awal menghemat satu sesi penelusuran masalah. Entah resolver hulu memiliki rute kembali ke 10.77.0.0/24 melalui gateway ini, atau gateway menerjemahkan sumber saat keluar sehingga jawaban tiba di alamat yang sudah dikenal hulu. Keduanya bekerja; hanya satu yang sesuai dengan kendali yang Anda miliki atas hulu.

Perutean layak dicoba lebih dulu, karena menjaga alamat klien tetap terlihat oleh resolver dan menghindari lapisan terjemahan kedua. Ketika hulu berada di luar kendali Anda, terjemahan sumber pada antarmuka keluar tertentu adalah pilihan praktis.

Batasi terjemahan itu sama ketatnya dengan pengalihan, atau aturan akan menjadi NAT serba guna untuk apa pun yang kebetulan cocok dengannya:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p udp --dport 53 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p tcp --dport 53 -j MASQUERADE

Pelacakan koneksi menjaga pemetaan tetap berpasangan, sehingga jawaban ditulis ulang kembali ke tuple asli klien saat kembali. Tanpa aturan keluar, resolver mengirim jawabannya ke alamat privat yang tidak dapat dijangkau, dan klien melihat batas waktu alih-alih kesalahan.

Tulis aturan lebih sempit daripada tampaknya tugas

Izin penerusan termasuk dalam cakupan yang sama. Izinkan aliran klien ke resolver dan lalu lintas balasan yang sudah dikenali conntrack, alih-alih menerima setiap koneksi DNAT di mesin. Penerimaan menyeluruh juga mengizinkan penerusan port yang tidak ada hubungannya dengan DNS.

Resolver milik gateway sendiri adalah jalur kode yang berbeda. Kueri yang dikeluarkan secara lokal melewati OUTPUT, jadi pengujian dari shell gateway tidak melatih aturan PREROUTING maupun kebijakan penerusan. Itulah sebabnya uji lokal bisa lulus sementara setiap klien gagal, dan sebaliknya sama umumnya.

Tidak ada yang di sini mencakup DNS melalui HTTPS pada port 443 atau DNS melalui TLS pada port 853, dan tidak ada yang mencakup IPv6. Klien dengan resolver IPv6 yang dikonfigurasi akan dengan senang hati mengabaikan seluruh pengaturan.

Apa yang dibuktikan kueri baru

Pelacakan koneksi mengingat pemetaan sebelumnya, sehingga kueri yang dikirim sebelum perubahan aturan dapat dijawab dari status lama dan membuat aturan baru tampak rusak. Mulailah dengan port sumber baru dan, di tempat klien menyimpan jawaban, dengan nama baru.

dig @10.77.0.1 example.com A +short
conntrack -L -p udp --dport 53 | head

Perintah pertama menunjukkan apakah jalur klien terurai sama sekali, dan yang kedua menunjukkan terjemahan yang benar-benar dipasang gateway, termasuk kedua arah tuple. Pemetaan yang menunjuk ke resolver yang benar dengan penghitung balasan macet di nol adalah masalah jalur balasan, bukan masalah penyaringan.

Pastikan resolver mengetahui nama yang Anda harapkan sebelum mengalihkan apa pun. Pengganti yang menjawab nama publik tetapi bukan zona privat Anda mengubah pencarian yang berfungsi menjadi NXDOMAIN yang tampak seperti terowongan rusak. Uji resolver secara langsung, dari gateway, sebelum jalur klien terlibat. Dan referensi ekstensi iptables mendokumentasikan semantik DNAT dan masquerade yang menjadi sandaran aturan ini.

Artikel terkait