SoftEther แคสเคด: เชื่อมสองฮับเสมือนอย่างตั้งใจ
แคสเคดเชื่อมฮับภายในกับฮับระยะไกลภายใต้ตัวตนที่กำหนดค่าไว้ ไม่ใช่โหนดทางออก และบรรทุกทุกสิ่งที่ฮับเหล่านั้นบริดจ์อยู่แล้ว
ฮับ SoftEther สองตัวที่เชื่อมกันด้วยแคสเคดใช้โดเมนการออกอากาศร่วมกัน ดังนั้นลูปหรือเซิร์ฟเวอร์ DHCP ตัวที่สองจึงไม่ใช่ความผิดพลาดภายในอีกต่อไป แต่กลายเป็นความผิดพลาดร่วมกัน นั่นคือแบบจำลองความเสี่ยงทั้งหมด ตัวแคสเคดเองคือความสัมพันธ์ไคลเอนต์ที่กำหนดค่าไว้: ฮับเสมือนภายในเชื่อมต่อออกไปยังฮับของเซิร์ฟเวอร์ระยะไกลภายใต้ตัวตนที่เซิร์ฟเวอร์นั้นอนุญาต มันเป็นชิ้นส่วนสำหรับเครือข่ายเสมือนที่ใหญ่กว่า ไม่เคยเป็นทางออกสู่อินเทอร์เน็ต
1. ตัดสินใจว่าลิงก์ต้องบรรทุกอะไร
เริ่มจากความต้องการ ไม่ใช่คุณสมบัติ แคสเคดย้ายเฟรมชั้นที่สองระหว่างฮับ ซึ่งเป็นสิ่งที่ต้องการเมื่อสองไซต์ต้องดูเหมือนอีเทอร์เน็ตเซกเมนต์เดียว หากความต้องการเป็นเพียงการเข้าถึงแบบกำหนดเส้นทางไปยังซับเน็ตไม่กี่แห่ง เส้นทางแบบกำหนดเส้นทางนั้นง่ายกว่าและล้มเหลวในแบบที่เห็นได้ง่ายกว่า การเลือกแคสเคดผูกคุณไว้กับการออกอากาศร่วม การค้นพบร่วม และโทโพโลยีลูปเดียว
เขียนความต้องการเป็นบรรทัดเดียวก่อนแตะเซิร์ฟเวอร์: ระบบใดต้องดูเหมือนอยู่บนสายเดียวกัน และระบบใดต้องการเพียงเส้นทาง ทุกสิ่งที่ไม่ตอบว่า «เส้นทาง» อยู่นอกแคสเคด ประโยคเดียวนี้ป้องกันการออกแบบส่วนใหญ่ที่ลงเอยด้วยบริการที่อยู่ซ้ำกัน
2. กำหนดขอบเขตตัวตนที่อนุญาต
ข้อมูลรับรองที่ใช้ดูแลเซิร์ฟเวอร์กับตัวตนที่แคสเคดใช้เชื่อมต่อเป็นความลับที่ต่างกัน และการผสมปนเปกันเป็นทางลัดทั่วไปที่มีหางยาว ฮับระยะไกลต้องการรายการผู้ใช้หรือนโยบายที่อนุญาตให้แคสเคดนี้เชื่อมต่อ รายการนั้นคือการอนุญาต การเข้าสู่ระบบสำเร็จไม่ได้บอกอะไรเกี่ยวกับสิ่งที่อยู่หลังฮับระยะไกล
บันทึกว่าฮับใดเริ่ม ฮับระยะไกลใดที่มันเข้าร่วม และตัวตนระยะไกลเข้าถึงอะไรได้ เปรียบเทียบสถาปัตยกรรมทั้งสองก่อนผูกมัด:
| Requirement | Routed path | Cascaded segment |
|---|---|---|
| Broadcast domain | Separate on each side | Shared across the link |
| Address service | One DHCP server per side | Must not run two on one domain |
| Loop risk | Route loops only | Layer-two loops if segments overlap |
รักษาข้อมูลรับรองและคำแนะนำการกู้คืนของทั้งสองด้านให้เป็นปัจจุบัน การเปลี่ยนรหัสผ่านหรือแก้ไขนโยบายบนฮับระยะไกลทำให้แคสเคดขาดโดยไม่แตะผู้ใช้ภายในของคุณ และความล้มเหลวมักปรากฏเป็นลิงก์ที่ขึ้นอยู่แต่ว่างเปล่า
3. ตรวจสอบว่าฮับบรรทุกอะไรอยู่แล้ว
ฮับไม่ค่อยแยกตัวอยู่ลำพัง มันอาจ บริดจ์อะแดปเตอร์ทางกายภาพอยู่แล้ว กำหนดเส้นทางผ่านเราเตอร์เสมือน หรือแคสเคดไปที่อื่น และทุกการเชื่อมต่อเหล่านั้นถูกพาเข้าสู่ความสัมพันธ์ใหม่ นั่นคือเหตุผลที่ «เราเชื่อมเพียงสองฮับ» มักกลายเป็น «ทำไมสองไซต์นี้จึงเป็นเซกเมนต์เดียวตอนนี้»
ฮับสองตัวที่บริดจ์เข้าสู่เซกเมนต์ทางกายภาพเดียวกันแล้วแคสเคดถึงกันจะสร้างลูป เพิ่ม spanning tree หรืออย่าสร้างมัน การทดสอบเดียวกันใช้กับฮับที่ไปถึงเป้าหมายผ่านแคสเคดอื่นอยู่แล้ว: ลิงก์ที่สองไม่ได้เพิ่มความจุ มันเพิ่มเส้นทาง
อย่าเพิ่มลิงก์เพราะขาดเส้นทางเดียว แก้เส้นทางนั้น วาดโทโพโลยีบนกระดาษก่อน รวมทุกบริดจ์และแคสเคด เพราะแผนภาพใช้เวลาสองนาทีและจับลูปส่วนใหญ่ได้ก่อนที่มันจะมีอยู่
4. จัดการที่อยู่ก่อนเชื่อมต่อ
เซกเมนต์ที่รวมกันนำซับเน็ตซ้ำมา และเซิร์ฟเวอร์ DHCP ซ้ำคืออาการคลาสสิก: ไคลเอนต์เช่าจากเซิร์ฟเวอร์ใดก็ตามที่ตอบก่อน พฤติกรรมจึงดูสุ่มและย้ายระหว่างการรีบูต ตัดสินใจล่วงหน้าว่าฝ่ายใดเป็นเจ้าของการกำหนดที่อยู่ และให้เซกเมนต์ไกลมีช่วงที่ไม่ทับซ้อนกับสิ่งใดภายใน ปิดใช้งานบริการ DHCP อีกตัวก่อนที่แคสเคดจะออนไลน์ ไม่ใช่หลังการร้องเรียนครั้งแรก
DNS เป็นคำถามแยกต่างหาก แคสเคดบรรทุกเฟรม ไม่ได้กำหนดค่ารีโซลเวอร์ และชื่อที่แก้ได้ฝั่งภายในอาจแก้ไม่ได้ข้ามลิงก์ ทดสอบการค้นหาแยกจากเส้นทาง IP เพราะ ping ที่ทำงานได้พิสูจน์เพียงหนึ่งในสองอย่าง
5. พิสูจน์ด้วยทรัพยากรจริง
เลือกบริการที่อนุญาตบนเซกเมนต์ระยะไกลที่ตั้งใจ และยืนยันว่าคำตอบกลับมาผ่านแคสเคด จากนั้นทำซ้ำสำหรับการแก้ชื่อ หากเป้าหมายต้องพึ่งการค้นพบด้วยการออกอากาศ ให้คาดหวังพฤติกรรมที่ต่างไปบนลิงก์ที่บริดจ์มากกว่าบนสายเดียว และวางแผนสำหรับสิ่งนั้นแทนที่จะบันทึกเป็นข้อบกพร่อง
สุดท้าย เขียนโทโพโลยี: ฮับใดแคสเคดไปที่ไหน ตัวตนใดอนุญาต เซกเมนต์ใดถูกบริดจ์ และใครเป็นเจ้าของการกำหนดที่อยู่ในแต่ละเซกเมนต์ บันทึกนั้นคือสิ่งที่ทำให้คนถัดไปเปลี่ยนนโยบายได้โดยไม่ต้องรื้อเซกเมนต์ที่เขาไม่รู้ว่ามีอยู่