ทำไมเส้นทางอุโมงค์แบบเต็มจึงตัดขาดเซิร์ฟเวอร์ที่บรรทุกมันไว้

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

เส้นทางที่กินการขนส่งของตัวเอง

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

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

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

ติดตั้งข้อยกเว้นก่อนเส้นทางเริ่มต้น

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

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

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

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

ภาพสะท้อนบนเซิร์ฟเวอร์

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

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

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

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

ข้อยกเว้นที่อุโมงค์ขโมยอยู่เรื่อย ๆ

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

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

ข้อยกเว้นที่ไม่มีใครจดไว้คือข้อยกเว้นที่การสร้างใหม่ครั้งถัดไปจะทิ้งไปอย่างเงียบ ๆ

พิสูจน์หลังเชื่อมต่อใหม่ ไม่ใช่ก่อนหน้านั้น

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

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

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