SNAT, DNAT และ Masquerade: แต่ละกฎ NAT ของ VPN ทำอะไร

วางการดักจับทั้งสองข้างของเกตเวย์ VPN แล้วทราฟฟิกเดียวอาจแสดงสี่ที่อยู่ต่างกัน NAT ต้นทางเขียนใหม่ว่าทราฟฟิกอ้างว่ามาจากที่ใด NAT ปลายทางเขียนใหม่ว่าจะไปที่ใด Masquerade ไม่ใช่ทิศทางที่สาม แต่เป็นกฎ NAT ต้นทางที่ใช้ที่อยู่จากอินเทอร์เฟซขาออกแทนค่าคงที่ ระบุว่าคุณต้องการข้อใดในสามข้อนี้จริง ๆ แล้วตั๋ว “VPN เสีย” ส่วนใหญ่จะกลายเป็นคำถามเรื่องเส้นทางขากลับ

แต่ละกฎเขียนใหม่อะไร

NAT ต้นทาง ซึ่งมักเขียนว่า SNAT เปลี่ยนที่อยู่ต้นทางของทราฟฟิกเมื่อออกจากเราเตอร์หรือเกตเวย์ บริการปลายทางตอบกลับไปยังที่อยู่ที่แปลแล้ว และกล่องที่แปลจะย้อนการเปลี่ยนแปลงด้วยสถานะที่เก็บไว้สำหรับการเชื่อมต่อนั้น บน Linux สถานะนั้นอยู่ใน conntrack จึงเป็นเหตุให้ conntrack -L พิมพ์ทูเพิลต้นฉบับและทูเพิลตอบกลับวางข้างกัน

NAT ปลายทาง คือ DNAT เปลี่ยนปลายทางแทน แพ็กเก็ตที่ส่งไปยังที่อยู่สาธารณะบน UDP 51820 สามารถเขียนใหม่ไปยังเซิร์ฟเวอร์ WireGuard ภายในที่ 10.8.0.2:51820 ได้ เราเตอร์บ้านหรือโหลดบาลานเซอร์บนคลาวด์เผยแพร่ตัวรับฟัง VPN ด้วยวิธีนี้ และไม่ได้บอกอะไรเกี่ยวกับสิ่งที่ทันเนลจะพาไปหลังจากนั้น

Masquerade อยู่ในตระกูล SNAT กฎไม่ได้ระบุที่อยู่ใด ๆ แต่ใช้ที่อยู่ที่อินเทอร์เฟซขาออกมีอยู่ในขณะที่แพ็กเก็ตออก Linux ให้เป้าหมายของตัวเอง และเป็นตัวเลือกปกติบนอินเทอร์เฟซ WAN ที่ได้ที่อยู่จาก DHCP หรือ PPPoE

ที่อยู่ของการแมปตัดสินความล้มเหลว

บันทึกทูเพิลทุกขอบเขต ก่อนทันเนล ภายในทันเนล และบนอินเทอร์เฟซสาธารณะ การดักจับภายในทันเนลย่อมต่างจากภายนอกอย่างชอบธรรม และใครที่เปรียบเทียบทั้งสองโดยไม่รู้ว่าการแปลเกิดที่ใดจะไล่ตามโฮสต์ผิดตัว

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

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

Masquerade หรือ SNAT แบบระบุชัด

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

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

IPsec แบบอิงนโยบายคือที่ที่เรื่องนี้กัดเจ็บที่สุด คู่มือการส่งต่อของ strongSwan อธิบายการเปิดใช้การส่งต่อ IP และการเพิ่มกฎ SNAT ต้นทางสำหรับไคลเอนต์ และเอกสารเดียวกันยังครอบคลุมการยกเว้นทราฟฟิกที่ต้องคงที่อยู่เดิมไว้ แปลต้นทางก่อนที่นโยบายความปลอดภัยจะจับคู่ แล้วทันเนลอาจขึ้นได้แต่ทราฟฟิกยังตก เพราะแพ็กเก็ตไม่เหมือนตัวเลือกที่เจรจาไว้แล้ว

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

การอ่านกฎบนเกตเวย์ Linux

เกตเวย์สำหรับการเข้าถึงระยะไกลที่มีไคลเอนต์บน 10.8.0.0/24 และอินเทอร์เฟซ WAN ชื่อ eth0 ต้องเปิดการส่งต่อและมีนโยบายกรองที่อนุญาตทราฟฟิกก่อนที่กฎ NAT ใดจะช่วยได้ เวอร์ชัน iptables เก็บทั้งสองทิศทางไว้ในตาราง nat

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

รูปแบบ nftables ใช้ฮุกสองตัวเดียวกันกับอินเทอร์เฟซที่ตั้งชื่อและเชนที่ระบุชัด

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

ทั้งสองตัวอย่างถือว่าฟิลเตอร์เชนยอมรับทราฟฟิกที่ส่งต่อแล้ว NAT ไม่ใช่กฎอนุญาต และแพ็กเก็ตที่แปลถูกต้องก็ยังถูกทิ้งได้ในอีกตารางถัดไป ยืนยันการแมปที่มีชีวิตด้วย conntrack -L ยืนยันสิ่งที่โหลดอยู่ด้วย nft list ruleset หรือ iptables-save -t nat แล้วดักจับบนอินเทอร์เฟซทั้งสองเพื่อดูว่าที่อยู่เปลี่ยนจริง

โหมดความล้มเหลวที่ดูเหมือนกฎแย่ ๆ

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

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

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

รายการตรวจสอบก่อนบันทึกกฎ

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

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