สองฮ็อป VPN บน Pi เครื่องเดียว: เส้นทางใดพาเพียร์ใด
ที่อยู่ทันเนลสองที่อยู่บน Pi เครื่องเดียวไม่ใช่ข้อผิดพลาด ทุกปลายทางต้องการตัวพาของตัวเอง หลักฐานของตัวเอง และแผนสำรองที่ประกาศไว้เมื่อฮ็อปชั้นนอกตาย
ที่อยู่ทันเนลสองที่อยู่บนบอร์ดเล็ก ๆ ดูเหมือนความผิดพลาด และปฏิกิริยาคือลบหนึ่งอัน ปฏิกิริยานั้นทำลายสิ่งที่มันควรจัดระเบียบ โฮสต์ที่พาสองฮ็อปเก็บที่อยู่หนึ่งที่อยู่ต่อการเชื่อมต่อ และแต่ละที่อยู่ถูกเลือกโดยเส้นทางที่ต่างกัน คำถามที่คุ้มค่าจะถามคือเส้นทางใดเลือกตัวพาใดให้ปลายทางใด ไม่ใช่มีที่อยู่กี่ที่อยู่
สามปลายทางที่ต้องการตัวพาต่างกัน
ห่วงโซ่สองฮ็อปคือสามชั้นของปลายทางที่ซ้อนกัน และแต่ละชั้นถูกพาโดยการเชื่อมต่อที่ต่างกัน ต้องเข้าถึงเพียร์ชั้นนอกผ่านลิงก์กายภาพ ต้องเข้าถึงเพียร์ชั้นในผ่านทันเนลชั้นนอก ต้องเข้าถึงปลายทางของแอปพลิเคชันที่ถูกคลุมผ่านทันเนลชั้นใน ซึ่งการขนส่งของมันเองถูกพาโดยชั้นนอก
| Destination class | View that names the carrier | Command that proves it | Symptom when the wrong carrier wins |
|---|---|---|---|
| Outer peer, 198.51.100.10 | the main table, by destination | ip route get 198.51.100.10 | the outer handshake never completes |
| Inner peer, 203.0.113.7 | the main table once the outer tunnel is up | ip route get 203.0.113.7 | the inner handshake leaves over the physical link |
| Application destination, 172.30.9.1 | the table the inner client's traffic is selected into | ip route get 172.30.9.1 from 10.8.0.2 | the exit address looks right and the traffic never crossed the outer hop |
| Parallel tunnels, one per source group | one policy per group, not the main table | ip rule show beside a marked test connection | both tunnels are up and one steals the other's traffic |
เติมแถวด้วยที่อยู่จริงของผู้อ่านก่อนแตะเส้นทาง เพราะตารางมีประโยชน์ก็ต่อเมื่อมันเป็นรูปธรรม ห่วงโซ่ที่ทำงานได้ตอบสนองทั้งสี่แถวพร้อมกัน และห่วงโซ่ที่ทำงานได้ครึ่งหนึ่งมักตอบสนองหนึ่งในนั้นด้วยตัวพาที่ผิด การอ่านแถวผิดว่าเป็นความล้มเหลวนั้นเองที่เปลี่ยนปัญหาการกำหนดเส้นทางให้กลายเป็นงานแก้ไขทั้งบ่าย
ที่อยู่มีบทบาท ไม่ใช่จำนวน
ลินุกซ์อนุญาตหลายที่อยู่บนอินเทอร์เฟซเดียวและหลายทันเนลบนโฮสต์เดียว จำนวนจึงไม่ได้บอกอะไรเกี่ยวกับความถูกต้อง สิ่งที่สำคัญคือที่อยู่ใดเป็นของการเชื่อมต่อใด และเส้นทางสำหรับเพียร์ที่กำหนดเลือกการเชื่อมต่อที่คุณตั้งใจหรือไม่ สามมุมมองตอบเรื่องนี้จากสามทิศทาง และควรอ่านตามลำดับเดิมทุกครั้ง
รายการที่อยู่แสดงว่ามีอะไรและส่วนเชื่อมต่อใดเป็นเจ้าของ ตารางเส้นทางตอบคำถามเรื่องตัวพาสำหรับการรับส่งปกติไปยังปลายทาง มุมมองนโยบายตอบอีกครั้งสำหรับการรับส่งที่เลือกตามต้นทางหรือเครื่องหมาย ซึ่งเป็นการจัดวางปกติเมื่อลูกค้าสองรายแชร์โฮสต์เดียว
ip -4 addr show
ip -4 route show table all
ip rule showการลบที่อยู่เพราะรายการดูยาวอาจเอาเส้นทางบางส่วนออก และการลบเส้นทางเพราะดูซ้ำซ้อนก็ทำเช่นเดียวกันอย่างเงียบกว่า ทั้งสองไม่สร้างข้อผิดพลาด เพียร์เพียงหยุดตอบบนเส้นทางที่คุณตั้งใจในขณะที่ยังเข้าถึงได้ทางอื่น แอปพลิเคชันที่รายงานที่อยู่ทางออกของเพียร์ชั้นในไม่ได้พิสูจน์ว่าการรับส่งข้ามทันเนลชั้นนอก เนื่องจากการเข้าถึงโดยตรงให้การสังเกตเดียวกัน ช่องว่างระหว่างการสังเกตกับหลักฐานนี้เองคือเหตุผลที่ตรวจตัวพาที่ชั้นการกำหนดเส้นทาง
ลำดับการเปิดใช้งานชนะการรอแบบตายตัว
ถ้าลูกค้าชั้นในขึ้นกับที่อยู่หรือเส้นทางที่ลูกค้าชั้นนอกจัดหา การเปิดใช้งานต้องรอทรัพยากรนั้นไม่ใช่รอเวลา การรอแบบตายตัวทำงานจนถึงวันที่ทันเนลชั้นนอกช้า แล้วมันก็ล้มเหลวเป็นระยะในแบบที่ไม่มีใครทำซ้ำได้ ลำดับที่อิงการพึ่งพาจะเอาการเดาออกและไม่เสียอะไรเลยนอกจากการอธิบายการพึ่งพาหนึ่งครั้ง ชื่ออินเทอร์เฟซก็ไม่ใช่กลไกลำดับเช่นกัน
เคอร์เนลให้ชื่อเช่น tun0 และ tun1 ตามลำดับการสร้าง และลำดับนั้นอาจเปลี่ยนระหว่างการรีบูตหรือการเชื่อมต่อใหม่ ผูกการกำหนดค่ากับตัวตนที่เครื่องมือจัดหา หรือกับชื่อที่คุณกำหนดอย่างตั้งใจ ชื่อที่คุณเลือกคือสัญญา ชื่อที่เคอร์เนลเลือกคือความบังเอิญ
เก็บการขนส่งของแต่ละลูกค้าไว้นอกเส้นทางแอปพลิเคชันของอีกราย และแม่นยำเกี่ยวกับสิ่งที่ ตัวเลือกการกำหนดเส้นทางของ OpenVPN 2.6 สัญญาไว้จริง ๆ กลไกการเปลี่ยนเส้นทางเริ่มต้นที่มีเอกสารกำกับทำให้ลูกค้ายังเข้าถึงเพียร์ระยะไกลของตัวเองผ่านเกตเวย์ที่มีอยู่แล้ว ซึ่งตัดวงจรการเรียกซ้ำหนึ่งวง มันไม่ได้เปลี่ยนลูกค้ารายหนึ่งเป็นตัวพาของอีกราย ส่วนที่เหลือของห่วงโซ่จึงยังเป็นการออกแบบของคุณ เมื่อใดที่ห่วงโซ่ต้องการนโยบายแทนเส้นทาง ให้เขียนกฎต้นทางหรือเครื่องหมายที่ชัดเจนและทดสอบกับการรับส่งที่มันควรตรงกัน
เกิดอะไรขึ้นเมื่อฮ็อปชั้นนอกตาย
ก่อนที่ห่วงโซ่จะถูกนับว่าสมบูรณ์ ตัดสินใจว่าเกิดอะไรขึ้นเมื่อฮ็อปชั้นนอกหายไป การขนส่งของลูกค้าชั้นในตายไปด้วย และก้าวต่อไปเป็นคำถามเชิงนโยบายไม่ใช่เชิงเทคนิค ล้มเหลว ลองใหม่ หรือเชื่อมต่อใหม่โดยตรงผ่านลิงก์กายภาพ ผลลัพธ์ที่สามคือสิ่งที่ควรคิด มันเปลี่ยนการออกแบบสองฮ็อปเป็นการออกแบบหนึ่งฮ็อปอย่างเงียบ ๆ ในขณะที่ผู้ใช้เชื่อว่าความคุ้มคอยังสมบูรณ์
ถ้าสองฮ็อปเป็นบังคับ ลูกค้าชั้นในต้องไม่สามารถสร้างเส้นทางตรงได้เมื่อชั้นนอกหายไป และวิธีรู้คือทำให้ฮ็อปชั้นนอกขาดแล้วดูว่าชั้นในทำอะไร แผนสำรองที่อนุมัติแล้วเป็นคำตอบที่ชอบด้วยกฎหมาย แต่ต้องเขียน ทดสอบ และสื่อสาร แผนสำรองที่ไม่มีใครบันทึกไว้แยกจากการรั่วไหลในการทบทวนเหตุการณ์ไม่ได้
DNS และตระกูลที่อยู่อีกตระกูลเป็นส่วนหนึ่งของการตัดสินใจเดียวกัน การค้นหาที่สร้างขึ้นในเครื่องปฏิบัติตามนโยบายของโฮสต์เองไม่ใช่นโยบายของลูกค้าที่ส่งต่อ ตัวแก้ปัญหาที่ทำงานกับการรับส่งที่ส่งต่อจึงอาจไม่ใช่ตัวที่โฮสต์เองใช้
ยอมรับแต่ละชั้นตามลำดับที่คุณสร้างมัน
ทดสอบตามลำดับที่ห่วงโซ่ถูกสร้าง ขั้นแรกทันเนลชั้นนอกลำพัง จากนั้นการขนส่งของลูกค้าชั้นในผ่านทันเนลชั้นนอก จากนั้นแอปพลิเคชันผ่านทันเนลชั้นใน การยอมรับแต่ละครั้งต้องเป็นการเชื่อมต่อใหม่ไม่ใช่หน้าที่เปิดอยู่แล้ว จากนั้นทำให้แต่ละชั้นขาดและกู้คืนแยกกันและสังเกตว่าชั้นถัดไปทำอะไร
ผลของแผนสำรองคือการสังเกตที่มีค่าที่สุดในที่นี้ และเป็นสิ่งที่หน้า IP สาธารณะไม่เคยแสดง บันทึกเส้นทางของเพียร์ ที่อยู่ที่พวกมันใช้ และผลลัพธ์นั้นไว้ข้างการกำหนดค่า เพราะเส้นทางที่มีความสุขไม่ใช่ส่วนที่ถูกตั้งคำถามในภายหลัง