การต่อ VPN สองชั้นด้วยกัน: มันซ่อนอะไรและต้องแลกกับอะไร

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

1. ตัดสินใจว่าฮอปที่สองมีไว้เพื่ออะไร

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

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

2. ทำให้ปลายทางชั้นในเข้าถึงได้ผ่านอุโมงค์ชั้นนอก

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

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

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

3. ให้ DNS อยู่บนเส้นทางเดียวกัน

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

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

4. ตั้งค่า MTU ก่อนที่ผู้ใช้จะค้นพบแทนคุณ

MTU เป็นเหยื่อรายถัดไปที่คาดเดาได้ การห่อหุ้มสองชั้นหักหัวเรื่องสองหัว และอุโมงค์ชั้นนอกที่ลด MTU ของเส้นทางไว้แล้วเหลือที่ว่างข้างในน้อยลง อาการเป็นที่คุ้นเคย คำขอเล็กสำเร็จ การถ่ายโอนขนาดใหญ่และแฮนด์เชก TLS หยุดชะงัก

ip link set dev wg1 mtu 1280 เป็นวิธีแก้แบบหยาบ และการหนีบ MSS บนฟอร์เวิร์ดเดอร์เป็นวิธีที่เรียบร้อยกว่า การลองเชื่อมต่อใหม่ไม่ใช่วิธีแก้เลย

5. ทดสอบความล้มเหลวที่คุณจะเจอจริง

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

ความหน่วงและจุดล้มเหลวที่สองคือต้นทุนถาวร สองฮอปยังหมายถึงคิวสนับสนุนสองคิวเมื่อมีบางอย่างพังในเวลาที่ไม่สะดวก