WireGuard DNS DNAT: kekalkan laluan balasan berfungsi

Menghalakan pertanyaan DNS klien WireGuard ke resolver lain kelihatan seperti satu peraturan dan berkelakuan seperti tiga keputusan. Destinasi mesti ditulis semula, paket mesti dimajukan, dan jawapan mesti mencari jalan pulang melalui keadaan terjemahan yang dicipta oleh gateway. Langkau yang ketiga dan pertanyaan keluar dengan bersih sementara klien menunggu selamanya.

Ambil contoh klien dibenarkan dalam 10.77.0.0/24 yang tiba melalui wg0, menanyakan alamat yang diiklankan 10.77.0.1 dan memerlukan resolver di 203.0.113.53. Alamat huluan ialah pemegang tempat dokumentasi, bukan perkhidmatan yang berfungsi.

Mengubah hala pertanyaan hanya menukar destinasinya

Peraturan NAT destinasi dalam PREROUTING menulis semula alamat sebelum keputusan penghalaan dibuat, jadi paket kemudian dihalakan ke destinasi baharu dan bukan yang lama. Alamat sumber klien tidak disentuh oleh operasi itu. Itulah sebabnya peraturan yang kelihatan lengkap masih boleh menghasilkan kesenyapan: permintaan kini bergerak ke resolver yang tidak pernah mendengar tentang julat peribadi klien. Gateway menterjemah satu medan dan mewarisi masalah kedua.

Kedua-dua pengangkutan DNS memerlukan peraturan yang sepadan, kerana klien kembali ke TCP apabila jawapan dipotong.

Peraturan di bawah memilih satu antara muka masuk, satu julat klien dan satu alamat destinasi asal. Tiada apa-apa lagi pada gateway terjejas, dan pertanyaan daripada gateway itu sendiri tidak sepadan sama sekali.

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

Laluan balasan ialah keputusan berasingan

Dua susunan membolehkan jawapan kembali, dan memilih satu lebih awal menjimatkan satu sesi nyahpepijat. Sama ada resolver huluan mempunyai laluan balik ke 10.77.0.0/24 melalui gateway ini, atau gateway menterjemah sumber semasa keluar supaya jawapan tiba di alamat yang sudah diketahui huluan. Kedua-duanya berfungsi; hanya satu sepadan dengan kawalan yang anda ada ke atas huluan.

Penghalaan patut dicuba dahulu, kerana ia mengekalkan alamat klien kelihatan kepada resolver dan mengelakkan lapisan terjemahan kedua. Apabila huluan di luar kawalan anda, terjemahan sumber pada antara muka keluar tertentu ialah pilihan praktikal.

Hadkan terjemahan itu seketat pengubahan hala, jika tidak peraturan menjadi NAT tujuan umum untuk apa sahaja yang kebetulan sepadan 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

Penjejakan sambungan mengekalkan pemetaan berpasangan, jadi jawapan ditulis semula ke tupel asal klien semasa kembali. Tanpa peraturan keluar, resolver menghantar jawapannya ke alamat peribadi yang tidak dapat dicapainya, dan klien melihat tamat masa dan bukan ralat.

Tulis peraturan lebih sempit daripada rupa tugasan

Kebenaran pemajuan tergolong dalam skop yang sama. Benarkan aliran klien ke resolver dan trafik balasan yang sudah dikenali conntrack, dan bukan menerima setiap sambungan DNAT pada mesin. Penerimaan menyeluruh juga membenarkan pemajuan port yang tiada kaitan dengan DNS.

Resolver gateway sendiri ialah laluan kod yang berbeza. Pertanyaan yang dikeluarkan secara tempatan melalui OUTPUT, jadi menguji dari shell gateway tidak melatih peraturan PREROUTING mahupun dasar pemajuan. Itulah sebabnya ujian tempatan boleh lulus sementara setiap klien gagal, dan sebaliknya sama biasa.

Tiada apa-apa di sini merangkumi DNS melalui HTTPS pada port 443 atau DNS melalui TLS pada port 853, dan tiada apa-apa merangkumi IPv6. Klien dengan resolver IPv6 yang dikonfigurasikan akan mengabaikan seluruh susunan dengan gembira.

Apa yang dibuktikan oleh pertanyaan baharu

Penjejakan sambungan mengingati pemetaan terdahulu, jadi pertanyaan yang dihantar sebelum perubahan peraturan boleh dijawab daripada keadaan lama dan membuat peraturan baharu kelihatan rosak. Mulakan dengan port sumber baharu dan, di tempat klien menyimpan jawapan, dengan nama baharu.

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

Perintah pertama menunjukkan sama ada laluan klien diselesaikan, dan yang kedua menunjukkan terjemahan yang sebenarnya dipasang gateway, termasuk kedua-dua arah tupel. Pemetaan yang menunjuk ke resolver yang betul dengan pembilang jawapan tersekat pada sifar ialah masalah laluan balasan, bukan masalah penapisan.

Sahkan resolver mengetahui nama yang anda jangkakan sebelum mengubah hala apa-apa. Pengganti yang menjawab nama awam tetapi bukan zon peribadi anda menukar carian yang berfungsi menjadi NXDOMAIN yang kelihatan seperti terowong rosak. Uji resolver secara langsung, dari gateway, sebelum laluan klien terlibat. Dan rujukan sambungan iptables mendokumenkan semantik DNAT dan masquerade yang bergantung kepada peraturan ini.