การชี้คำถาม DNS ของไคลเอนต์ WireGuard ไปยังรีโซลเวอร์อื่นดูเหมือนกฎเดียว แต่ทำงานเหมือนสามการตัดสินใจ ต้องเขียนปลายทางใหม่ ต้องส่งต่อแพ็กเก็ต และคำตอบต้องหาทางกลับผ่านสถานะการแปลงที่เกตเวย์สร้างขึ้น หากข้ามข้อที่สาม คำถามจะออกไปอย่างเรียบร้อยขณะที่ไคลเอนต์รอตลอดไป

ลองดูตัวอย่างไคลเอนต์ที่ได้รับอนุญาตใน 10.77.0.0/24 ที่เข้ามาทาง wg0 สอบถามที่อยู่ที่ประกาศ 10.77.0.1 และต้องการรีโซลเวอร์ที่ 203.0.113.53 ที่อยู่ต้นน้ำเป็นตัวแทนสำหรับเอกสาร ไม่ใช่บริการที่ใช้งานได้

การเปลี่ยนเส้นทางคำถามเปลี่ยนเฉพาะปลายทาง

กฎ NAT ปลายทางใน PREROUTING เขียนที่อยู่ใหม่ก่อนการตัดสินใจกำหนดเส้นทาง แพ็กเก็ตจึงถูกกำหนดเส้นทางไปยังปลายทางใหม่แทนปลายทางเดิม ที่อยู่ต้นทางของไคลเอนต์ไม่ถูกแตะต้องโดยการกระทำนั้น นี่คือเหตุผลที่กฎที่ดูสมบูรณ์ยังสามารถสร้างความเงียบได้ คำขอเดินทางไปยังรีโซลเวอร์ที่ไม่เคยได้ยินเกี่ยวกับช่วงส่วนตัวของไคลเอนต์ เกตเวย์แปลงฟิลด์หนึ่งและสืบทอดปัญหาที่สอง

การขนส่ง DNS ทั้งสองแบบต้องการกฎที่ตรงกัน เพราะไคลเอนต์จะถอยกลับไปใช้ TCP เมื่อคำตอบถูกตัดทอน

กฎด้านล่างเลือกอินเทอร์เฟซขาเข้าเดียว ช่วงไคลเอนต์เดียว และที่อยู่ปลายทางต้นฉบับเดียว ไม่มีสิ่งอื่นบนเกตเวย์ได้รับผลกระทบ และคำถามจากเกตเวย์เองไม่ตรงเลย

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

เส้นทางตอบกลับเป็นการตัดสินใจแยกต่างหาก

การจัดวางสองแบบทำให้คำตอบกลับมาได้ และการเลือกตั้งแต่เนิ่นๆ ช่วยประหยัดเซสชันดีบักหนึ่งครั้ง ไม่ว่ารีโซลเวอร์ต้นน้ำมีเส้นทางกลับไปยัง 10.77.0.0/24 ผ่านเกตเวย์นี้ หรือเกตเวย์แปลงต้นทางที่ขาออกเพื่อให้คำตอบมาถึงที่อยู่ที่ต้นน้ำรู้จักอยู่แล้ว ทั้งสองวิธีใช้ได้ มีเพียงวิธีเดียวที่ตรงกับการควบคุมที่คุณมีเหนือต้นน้ำ

การกำหนดเส้นทางสมควรได้รับการลองก่อน เพราะรักษาที่อยู่ของไคลเอนต์ให้มองเห็นได้จากรีโซลเวอร์และหลีกเลี่ยงชั้นการแปลงที่สอง เมื่อต้นน้ำอยู่นอกเหนือการควบคุมของคุณ การแปลงต้นทางบนอินเทอร์เฟซขาออกที่เฉพาะเจาะจงคือทางเลือกที่ใช้ได้จริง

จำกัดการแปลงนั้นให้แน่นเท่ากับการเปลี่ยนเส้นทาง มิฉะนั้นกฎจะกลายเป็น NAT เอนกประสงค์สำหรับทุกสิ่งที่บังเอิญตรงกับมัน

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

การติดตามการเชื่อมต่อรักษาการแมปให้เป็นคู่ คำตอบจึงถูกเขียนกลับเป็นทูเพิลดั้งเดิมของไคลเอนต์ขากลับ หากไม่มีกฎขาออก รีโซลเวอร์จะส่งคำตอบไปยังที่อยู่ส่วนตัวที่ไม่สามารถเข้าถึงได้ และไคลเอนต์เห็นการหมดเวลาแทนข้อผิดพลาด

เขียนกฎให้แคบกว่าที่งานดูเหมือน

สิทธิ์ในการส่งต่ออยู่ในขอบเขตเดียวกัน อนุญาตการไหลจากไคลเอนต์ไปยังรีโซลเวอร์และทราฟฟิกขากลับที่ conntrack รู้จักอยู่แล้ว แทนที่จะยอมรับทุกการเชื่อมต่อ DNAT บนเครื่อง การยอมรับแบบครอบคลุมยังอนุญาตการส่งต่อพอร์ตที่ไม่เกี่ยวข้องกับ DNS

รีโซลเวอร์ของเกตเวย์เองเป็นเส้นทางโค้ดอื่น คำถามที่ออกในเครื่องจะผ่าน OUTPUT ดังนั้นการทดสอบจากเชลล์ของเกตเวย์จึงไม่ได้ฝึกกฎ PREROUTING หรือนโยบายการส่งต่อ นี่คือเหตุผลที่การทดสอบในเครื่องอาจผ่านขณะที่ไคลเอนต์ทุกตัวล้มเหลว และกลับกันก็พบได้บ่อยพอกัน

ไม่มีอะไรตรงนี้ครอบคลุม DNS บน HTTPS ที่พอร์ต 443 หรือ DNS บน TLS ที่พอร์ต 853 และไม่มีอะไรครอบคลุม IPv6 ไคลเอนต์ที่ตั้งค่ารีโซลเวอร์ IPv6 ไว้จะเพิกเฉยต่อการจัดวางทั้งหมดอย่างมีความสุข

คำถามใหม่พิสูจน์อะไร

การติดตามการเชื่อมต่อจดจำการแมปก่อนหน้า คำถามที่ส่งก่อนการเปลี่ยนกฎจึงอาจได้คำตอบจากสถานะเก่าและทำให้กฎใหม่ดูเหมือนพัง เริ่มด้วยพอร์ตต้นทางใหม่ และที่ที่ไคลเอนต์แคชคำตอบ ให้ใช้ชื่อใหม่

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

คำสั่งแรกแสดงว่าเส้นทางไคลเอนต์แก้ไขได้หรือไม่ และคำสั่งที่สองแสดงการแปลงที่เกตเวย์ติดตั้งจริง รวมทั้งสองทิศทางของทูเพิล การแมปที่ชี้ไปยังรีโซลเวอร์ที่ถูกต้องแต่ตัวนับคำตอบค้างที่ศูนย์เป็นปัญหาของเส้นทางตอบกลับ ไม่ใช่ปัญหาของการกรอง

ยืนยันว่ารีโซลเวอร์รู้จักชื่อที่คุณคาดหวังก่อนจะเปลี่ยนเส้นทางสิ่งใด ทางเลือกที่ตอบชื่อสาธารณะแต่ไม่ตอบโซนส่วนตัวของคุณ เปลี่ยนการค้นหาที่ใช้งานได้ให้เป็น NXDOMAIN ที่ดูเหมือนอุโมงค์ที่พัง ทดสอบรีโซลเวอร์โดยตรงจากเกตเวย์ก่อนที่เส้นทางไคลเอนต์จะเข้ามาเกี่ยวข้อง และ เอกสารอ้างอิงส่วนขยายของ iptables จัดทำเอกสารความหมายของ DNAT และ masquerade ที่กฎเหล่านี้พึ่งพา

บทความที่เกี่ยวข้อง