VPN ซ้อนชั้น: อุโมงค์ใดพาการเชื่อมต่อชั้นนอก?

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

สามเงื่อนไขตัดสินการซ้อนชั้น

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

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

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

เงื่อนไขที่หนึ่ง: ปลายทางใดต้องใช้เส้นทางใด

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

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

เงื่อนไขที่สอง: ตรวจสอบเส้นทางในแต่ละชั้น

การเลือกเส้นทางบนไคลเอนต์สมัยใหม่เป็นมากกว่าตารางหลัก กฎนโยบายสามารถส่งแพ็กเก็ตที่ทำเครื่องหมายไปยังตารางอื่น ไคลเอนต์สามารถผูกซ็อกเก็ตของตนกับอินเทอร์เฟซ และคอนเทนเนอร์หรือเนมสเปซมีตารางของตัวเอง ip rule และ ip route show table all คือวิธีค้นหาว่ากลไกใดในเหล่านี้กำลังทำงาน

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

เงื่อนไขที่สาม: เกิดอะไรขึ้นเมื่ออุโมงค์ชั้นนอกร่วง

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

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

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

สิ่งที่ห่วงโซ่ไม่ได้ให้คุณ

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

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