eth0:0 เป็นเพียงเลเบล ไม่ใช่อุปกรณ์: แก้การจับคู่ SNAT

กฎ NAT ที่ควรให้พูลไคลเอนต์ VPN หนึ่งพูลมีที่อยู่สาธารณะของตัวเองกลับหยุดที่ศูนย์แพ็กเก็ต ขณะที่พูลเดิมยังคงออกไปด้วยต้นทางที่ผิด ปกติกฎไม่ได้ผิดที่ที่อยู่ แต่ผิดที่อินเทอร์เฟซ -o eth0:0 ชี้ไปยังอุปกรณ์ที่ไม่มีอยู่ เพราะ eth0:0 เป็นเลเบลที่ผูกกับที่อยู่บน eth0 การดูตัวนับเป็นวิธีที่เร็วที่สุดในการยืนยัน และการแก้ไขเล็กกว่าที่การสอบสวนบอก

ตรวจสอบว่าเคอร์เนลเรียกอุปกรณ์นั้นว่าอะไร

อ่านสองมุมมองแยกกันก่อนจะเปลี่ยนอะไร:

ip link show
ip address show dev eth0
ip route get 203.0.113.20

รายการลิงก์แสดงอินเทอร์เฟซ รายการที่อยู่อาจแสดงที่อยู่ IPv4 ที่สองซึ่งมีเลเบล eth0:0 และอุปกรณ์ของที่อยู่นั้นยังคงเป็น eth0 คู่มือที่อยู่ของ iproute2 ถือว่าเลเบลเป็นชื่อของที่อยู่ ไม่ใช่ลิงก์ที่สอง และนี่คือความแตกต่างที่ปัญหาทั้งหมดขึ้นอยู่กับ

ประวัติอธิบายความสับสน ไวยากรณ์แบบเก่า ifconfig eth0:0 ดูเหมือนอินเทอร์เฟซใหม่จริง ๆ และสคริปต์จากยุคนั้นยังอ้างถึงอยู่ ในระบบปัจจุบัน นามแฝง คือเลเบลบนที่อยู่ และไม่มีอะไรในเส้นทางเราเตอร์หรือ netfilter ที่ถือว่าเป็นจุดออกแยกต่างหาก

ตรวจสอบว่ากฎจับคู่กับอะไรจริง ๆ

อ่านตัวนับพร้อมรายการกฎ ไม่ใช่จากความจำ:

iptables -t nat -L POSTROUTING -v -n --line-numbers

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

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

ตรวจสอบเส้นทางที่เลือกอุปกรณ์

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

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

เลือกต้นทางที่แปลอย่างตั้งใจ

เมื่ออุปกรณ์ถูกต้อง ที่อยู่ต้นทางเป็นการตัดสินใจแยกต่างหาก นี่เป็นเพียงพูล IPv4 ตัวอย่างและที่อยู่ตัวอย่าง:

iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o eth0 \
  -j SNAT --to-source 203.0.113.20

การเขียนที่อยู่ลงใน --to-source ไม่ได้ทำให้ใครเราเตอร์กลับมาหาคุณ ผู้ให้บริการต้นน้ำหรือเจ้าของที่อยู่ต้องส่งคำตอบสำหรับที่อยู่นั้นมาที่โฮสต์นี้ และที่อยู่ต้องเป็นที่อยู่ที่คุณได้รับอนุญาตให้ใช้ ถ้าไม่ใช่ กฎจะจับคู่และแปล และคำตอบก็ยังคงไปที่อื่น

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

ตรวจสอบด้วยการเชื่อมต่อที่เพิ่งเปิด

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

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