คำตอบออกทาง LAN ไม่ใช่ทางอุโมงค์: ทำไมและอย่างไร

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

อะไรเป็นตัวกำหนดแพ็กเก็ตขาออกจริง ๆ

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

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

ทำไมซับเน็ตภายในจึงชนะ

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

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

การครอบคลุมของเพียร์ไม่เหมือนกับเส้นทางที่ติดตั้งไว้

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

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

เลือกตารางตามที่อยู่ต้นทาง

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

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

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

ยืนยันเส้นทาง แล้วจึงยืนยันบริการ

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

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

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

สิ่งนี้ไม่ได้แก้ไขอะไร

ปล่อยการส่งต่อ กฎไฟร์วอลล์ และพฤติกรรม ICMPv6 บนเกตเวย์ไว้เหมือนเดิม เพราะเส้นทางตามแหล่งที่มาไม่ได้แทนที่สิ่งใดในนั้น ข้อความ Packet Too Big ที่หายไปยังคงทำให้คำตอบขนาดใหญ่พัง ไม่ว่าตารางใดจะชนะการค้นหา แก้ไขสิ่งนั้นก่อนเพิ่มกฎกำหนดเส้นทาง ไม่อย่างนั้นอาการจะอยู่ต่อหลังการเปลี่ยนแปลง

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

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