เพื่อให้ DNAT ทำงาน (ในแง่ที่ว่า เพื่อให้โปรแกรมสามารถจดจำการตอบกลับได้) ให้ "reverse NAT" ที่เปลี่ยนพอร์ตต้นทางของการตอบกลับทราฟฟิกจาก 192.168.30.1
(ถึง 192.168.30.3:2001
) จาก 2003
ถึง 2002
จะต้องดำเนินการ
อย่างไรก็ตามเมื่อมีการจราจรมาจาก 192.168.30.1:2003
ถึง 192.168.30.3:2001
จากมุมมองของ conntrack ไม่ได้เป็นผลมาจาก DNAT (เนื่องจากตามรายการ conntrack ที่สร้างขึ้น โฮสต์ไม่ใช่โฮสต์ที่เริ่มต้นการเชื่อมต่อ) NAT แบบย้อนกลับจะไม่เหมาะสม
ดังนั้น netfilter จึง "ถูกบังคับ" ให้ดำเนินการ SNAT สำหรับการรับส่งข้อมูลที่ตรงกับกฎ DNAT เพื่อให้สามารถแยกความแตกต่างของการรับส่งข้อมูลตอบกลับ (ซึ่งมาจาก 192.168.30.1:2003
) โดยปลายทาง 192.168.30.3:$สุ่ม
.
ฉันถือว่า netfilter จะทำการย้อนกลับ NAT สำหรับ DNAT (ซึ่งเป็น SNAT) ก่อนที่จะย้อนกลับ NAT สำหรับ SNAT (ซึ่งเป็น DNAT) หรือจัดการเพื่อใช้ปลายทางก่อน NAT ย้อนกลับสำหรับ SNAT (เช่น 192.168.30.3:$สุ่ม
) เป็นการจับคู่ NAT แบบย้อนกลับสำหรับ DNAT มิฉะนั้น SNAT ที่บังคับจะไม่มีประโยชน์(อย่างไรก็ตาม ในกรณีที่ไม่ใช่การกลับรายการ AFAIK ทั้งสองกรณีจะไม่เป็นจริง: DNAT จะถูกดำเนินการใน PREROUTING ก่อน SNAT ใน INPUT และการจับคู่ปลายทางในกฎ SNAT หากมี จะใช้ค่าที่เป็นผลลัพธ์ใน DNAT)
ประเด็นคือ เรื่องราวข้างต้น / "ปัญหา" ในคำถามของคุณแทบจะไม่สมเหตุสมผลเลยในความเป็นจริง ใช้ wireguard VPN สองโฮสต์เป็นตัวอย่าง: สมมติว่าคุณต้องการมี จุดสิ้นสุด=
ตั้งค่าบนโฮสต์ทั้งสอง (เพื่อให้โฮสต์ใดโฮสต์หนึ่งสามารถเริ่มต้นการสื่อสารได้) และไม่ต้องการให้ค่าถูก "อัปเดต" โดยไม่คาดคิดเนื่องจากการบังคับ SNAT (สมมติว่าสามารถเรียกใช้งานได้จริง) สิ่งที่คุณควรทำคือ "เสมอ -บน" SNAT ที่ "เสริม" DNAT / เทียบเท่ากับ NAT สำรอง:
iptables -t nat -A INPUT -s 192.168.30.1 -d 192.168.30.3 -p udp --sport 2003 --dport 2001 -j SNAT --to-source :2002
ซึ่งปกติแล้วไม่จำเป็นในโมเดลไคลเอนต์-เซิร์ฟเวอร์ เนื่องจาก NAT ย้อนกลับอัตโนมัติสำหรับ DNAT
ป.ล. คุณยังไปไม่ถึง 192.168.30.1:2003
โดย 192.168.30.1:2003
แม้ว่ามิฉะนั้น NAT แหล่งที่มาที่ถูกบังคับจะเกิดขึ้นหากคุณเข้าถึงอีกครั้งโดย 192.168.30.1:2002
ก่อนที่รายการ conntrack ของอดีตจะหลุดออกไป กฎ SNAT เพิ่มเติมใน INPUT ไม่ควรสร้างปัญหาเพิ่มเติมให้กับคุณเช่นกัน