สองฮอป VPN ติดกัน: ใครเห็นทราฟฟิกของคุณจริง ๆ
ฮอปแบบอนุกรมถอดรหัสแล้วเข้ารหัสใหม่ที่เกตเวย์แรก ฮอปแบบซ้อนถอดเพียงชั้นนอกออก ไล่ดูทั้งสองแบบและดูว่าผู้ให้บริการรายใดอ่านอะไรได้
โปรไฟล์ไคลเอนต์ทุกรายระบุเซิร์ฟเวอร์เพียงตัวเดียว ดังนั้นจากมุมของผู้ใช้จึงมีอุโมงค์เดียวและมีจุดเดียวที่การป้องกันสิ้นสุด สิ่งที่เกิดขึ้นหลังเกตเวย์แรกนั้นเป็นการตัดสินใจออกแบบที่ไคลเอนต์ไม่เคยเห็น และสองแบบที่พบบ่อยก็ทำงานต่างกันมากเมื่อถูกตรวจสอบ ในสายโซ่อนุกรมเกตเวย์แรกถอดรหัสแล้วเข้ารหัสใหม่ ในสายโซ่ซ้อนเกตเวย์แรกถอดชั้นนอกออกแล้วส่งต่ออุโมงค์ชั้นในที่ตัวเองเปิดไม่ได้ จำนวนฮอปเท่ากันทั้งสองแบบ ความต่างจึงต้องวาดออกมาไม่ใช่การนับ
เริ่มจากไคลเอนต์และตั้งชื่อปลายทั้งสอง
เริ่มจากจุดที่ผู้ใช้เริ่ม นั่นคือโปรไฟล์การเชื่อมต่อ ในนั้นมีที่อยู่ระยะไกลหนึ่งรายการ วิธีพิสูจน์ตัวตนหนึ่งวิธี และเมื่อการออกแบบรองรับก็มีรายการเส้นทาง ให้ป้ายชื่ออุโมงค์ชั้นนอกนั้นจากไคลเอนต์ถึงเกตเวย์ A และให้ที่อยู่ตัวอย่าง คือ ที่อยู่อุโมงค์ของไคลเอนต์ 10.77.0.2 ที่อยู่ของ A 10.77.0.1 และจุดปลายสาธารณะของ A 198.51.100.10 ซึ่งนำมาจากช่วงเอกสาร TEST-NET-2 เพื่อให้ไม่มีสิ่งใดในตัวอย่างไปชนกับโฮสต์จริง
ไม่มีสิ่งใดในโปรไฟล์นั้นกล่าวถึงเกตเวย์ B และนั่นไม่ใช่ข้อบกพร่อง ฮอปที่สองเป็นของ A และหน้าที่เดียวของไคลเอนต์คือส่งทราฟฟิกถึง A และรับสิ่งที่ส่งกลับมา การที่ A จะปิดอุโมงค์ ส่งต่อ หรือเปิดใหม่นั้นเป็นคำถามที่ส่วนที่เหลือของการไล่ดูนี้ตอบ และมันเป็นตัวกำหนดว่า A อ่านอะไรได้
แบบอนุกรม: A ถอดรหัสแล้วเข้ารหัสใหม่
ในการออกแบบอนุกรม A ปิดทราฟฟิกสองครั้ง มันถอดการป้องกันออกจากไคลเอนต์ ได้แพ็กเก็ต IP ของแอปพลิเคชัน แล้วส่งแพ็กเก็ตนั้นผ่านอุโมงค์ที่สองซึ่ง A สร้างขึ้นไปทาง B ระหว่างสองการกระทำนั้นแพ็กเก็ตอยู่บนเส้นทางส่งต่อของ A ในฐานะแพ็กเก็ต IP ธรรมดาที่จ่าหน้าถึงปลายทางส่วนตัว
สิ่งนั้นให้ผลสองประการที่ควรพูดตรง ๆ A สามารถใช้ นโยบายกับแพ็กเก็ตชั้นในได้ ในรูปของเส้นทาง กฎตัวกรอง และการบันทึกแหล่งที่มากับปลายทาง และ A ต้องถือชุดข้อมูลรับรองสองชุด คือชุดหนึ่งเป็นเซิร์ฟเวอร์ให้ไคลเอนต์ และอีกชุดเป็นไคลเอนต์ของ B การป้องกันมีอยู่ทุกขณะ แต่สิ่งที่ถูกป้องกันเปลี่ยนอัตลักษณ์ที่ A
จากข้อนั้นไม่ได้แปลว่า A อ่านข้อความธรรมดาของแอปพลิเคชัน เมื่อไคลเอนต์และบริการรัน TLS และตรวจสอบใบรับรองของกันและกัน A จะเห็นกระแสบันทึก TLS ไม่ใช่คำขอที่อ่านได้. การยืนยันว่าการป้องกันนั้นสิ้นสุดที่ใดต้องดูที่ห่วงโซ่ใบรับรองของบริการ ไม่ใช่ที่แผนภาพอุโมงค์
แบบซ้อน: A ถอดเพียงชั้นนอก
ในการออกแบบซ้อน ไคลเอนต์สร้างอุโมงค์ชั้นในไปยัง B ก่อน แล้วจึงห่ออุโมงค์นั้นไว้ในอุโมงค์ชั้นนอกเพื่อไปยัง A A ถอดหัวชั้นนอกออก พบอุโมงค์ชั้นใน และส่งต่อโดยไม่ถือกุญแจของมัน การป้องกันชั้นในจึงยังสิ้นสุดที่ B
ลิงก์ขาขึ้นของไคลเอนต์จึงบรรทุกสองชั้น ขณะที่เส้นทางระหว่าง A กับ B บรรทุกชั้นเดียว A เห็นที่อยู่ชั้นนอกของอุโมงค์ชั้นใน ซึ่งพอจะรู้ว่ามีทราฟฟิกและประมาณว่าไปทางไหน และไม่พอจะอ่านเพย์โหลด นั่นคือความต่างทั้งหมดจากกรณีอนุกรม และไม่มีตัวนับฮอปใดแสดงมัน สิ่งที่ A ยังทำได้คือปฏิเสธที่จะส่งต่อสิ่งที่อ่านไม่ได้ และนั่นเปิดอยู่เสมอสำหรับผู้ให้บริการของเกตเวย์นั้น
การซ้อนมีราคาที่ต้องจ่ายสำหรับคุณสมบัตินั้น แต่ละชั้นเพิ่มภาระหัวแพ็กเก็ต การวางแผน MTU และ MSS จึงกลายเป็นเรื่องบังคับไม่ใช่แค่เรื่องเรียบร้อย และเส้นทางที่ทำงานได้ด้วยชั้นเดียวอาจทิ้งแพ็กเก็ตขนาดใหญ่ไปอย่างเงียบ ๆ เมื่อมีสองชั้น แต่ละชั้นยังต้องมีพฤติกรรมการเชื่อมต่อใหม่และการคงอยู่ของตัวเอง และความล้มเหลวในชั้นหนึ่งจะดูเหมือนการหยุดชะงักบางส่วนผ่านอีกชั้นหนึ่ง
วาดผู้สังเกต ไม่ใช่แค่อุโมงค์
อุโมงค์เป็นส่วนที่ง่ายของภาพ ผู้สังเกตคือสิ่งที่การออกแบบพูดถึง ดังนั้นเขียนหนึ่งแถวต่อหนึ่งจุดชม และเติมว่าผู้สังเกตแต่ละรายอ่านอะไรได้จริง.
| Vantage point | Serial chain | Nested chain |
|---|---|---|
| Client's access network | Outer tunnel only | Outer tunnel only |
| Operator of A | Inner IP packet between A and B | Outer addresses of the inner tunnel, not its payload |
| Path between A and B | Second tunnel | Second tunnel |
| Operator of B | Inner packet re-originated by A | Payload after the inner layer is removed |
| Service edge | Traffic from the exit address | Traffic from the exit address |
สองแถวถูกรวมเข้าด้วยกันตลอดเวลา คือผู้ให้บริการของ A กับผู้ให้บริการอุโมงค์ของไคลเอนต์ ทั้งสองอาจเป็นนิติบุคคลเดียวกัน และชื่อเกตเวย์ที่ต่างกันไม่ได้ทำให้เป็นอิสระจากกัน ความเป็นเจ้าของที่เป็นอิสระต้องมีการควบคุมดูแลแยกกัน ข้อมูลรับรองแยกกัน และการบันทึกแยกกัน
ข้อมูลเมตารอดชีวิตทั้งสองแบบ เวลา ขนาดแพ็กเก็ต และจำนวนการเชื่อมต่อยังสังเกตได้ในทุกฮอป การมีสองฮอปจึงเพิ่มต้นทุนของการหาความสัมพันธ์แทนที่จะลบสัญญาณ การออกแบบที่สัญญาว่าจะมองไม่เห็นควรถูกตรวจกับรายการนั้นก่อนที่ใครจะพึ่งพามัน
ไล่เส้นทางความล้มเหลวก่อนเลือก
ทำให้สิ่งต่าง ๆ พังโดยเจตนาจากฝั่งไคลเอนต์ ตามลำดับที่ผู้ใช้จะพบ เริ่มจากอินเทอร์เฟซและ MTU ของมัน เพราะการซ้อนล้มเหลวที่ขนาดแพ็กเก็ตก่อนจะล้มเหลวที่การพิสูจน์ตัวตนมาก
ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1จากนั้นยืนยันจุดปลายของการป้องกันแทนที่จะสันนิษฐาน ขอใบรับรองจากบริการจากภายในอุโมงค์ใดก็ตามที่เปิดอยู่ และเปรียบเทียบห่วงโซ่ที่ไคลเอนต์เห็นกับห่วงโซ่ที่บริการนำเสนอจริง เกตเวย์ที่ลงนามใหม่หรือดักจับจะเปลี่ยนใบรับรองนั้น และการตรวจสอบจะปรากฏให้เห็นในคำสั่งเดียว
openssl s_client -connect intranet.example.com:443 -brief < /dev/nullจบด้วยเมทริกซ์การเชื่อมต่อใหม่ อุโมงค์ของไคลเอนต์ล่ม อุโมงค์ของ B ล่ม เส้นทางระหว่าง A กับ B เปลี่ยน บันทึกว่าอะไรกลับมาและอะไรไม่กลับ และการเชื่อมต่อชั้นในเคยตกไปยังเส้นทางนอกตัวพาที่ตั้งใจไว้หรือไม่ บันทึกที่อยู่ที่แต่ละการทดสอบใช้ เพราะการทำซ้ำบนเครือข่ายเข้าถึงอื่นย่อมตอบคำถามอื่น ทดสอบ MTU ซ้ำหลังการเชื่อมต่อใหม่ทุกครั้งด้วย เพราะเส้นทางที่เปลี่ยนไปอาจลดขนาดที่ใช้ได้โดยไม่มีบรรทัดการกำหนดค่าแม้แต่บรรทัดเดียวขยับ
เลือกแบบอนุกรมเมื่อ A ต้องใช้นโยบายกับแพ็กเก็ตชั้นใน หรือเมื่อไคลเอนต์ไม่สามารถรันอุโมงค์ซ้อนกันสองชั้นได้ เลือกแบบซ้อนเมื่อเพย์โหลดชั้นในต้องอ่านไม่ได้ที่ A เขียนตัวเลือกพร้อมผู้สังเกตและตัวเลข MTU ของมันไว้ และคนถัดไปจะไม่ต้องวาดภาพทั้งหมดใหม่เพื่อตอบคำถามข้อเดียว