หลังเปลี่ยน IP ของเซิร์ฟเวอร์ กฎ SNAT ยังระบุที่อยู่เดิม

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

การเชื่อมต่อและการส่งต่อล้มเหลวคนละจุด

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

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

อ่านกฎและตัวนับของกฎก่อนแก้ไข

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

sudo iptables -t nat -L POSTROUTING -n -v --line-numbers
ip -4 addr show

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

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

แทนที่ต้นทาง หรือเลิกระบุต้นทาง

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

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 10.151.0.40

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

sudo iptables -t nat -R POSTROUTING 1 -s 10.8.0.0/24 ! -d 10.8.0.0/24 -o eth0 -j MASQUERADE

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

สองวิธีที่ทำให้การแทนที่ผิดพลาด

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

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

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

บริการขาเข้าต้องการการแปลงตรงกันข้าม

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

sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 10.9.8.2:8080

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