ฮับ-แอนด์-สโปก กับฟูลเมช: โทโพโลยี VPN แบบใดเหมาะกับไซต์ของคุณ
อุโมงค์สองเส้นที่ใช้งานได้ยังไม่ใช่โทโพโลยี เปรียบเทียบเส้นทางส่งผ่าน พฤติกรรมเมื่อล้มเหลว และต้นทุนการเปลี่ยนแปลง ก่อนเลือกฮับ เมช หรือฮับที่มีลิงก์ตรงไม่กี่เส้น
สำนักงานสาขาสองแห่งคุยกันทั้งวัน และอุโมงค์ระหว่างกันต้องอ้อมผ่านดาต้าเซ็นเตอร์ในอีกภูมิภาค ทุกคำขอจ่ายค่าอ้อมนั้นสองครั้ง และไม่มีใครสังเกตจนกว่าการซิงก์ไฟล์จะเริ่มรู้สึกผิดปกติ คำถามเรื่องโทโพโลยีเริ่มต้นตรงนี้จริง ๆ ไม่ใช่ที่ว่าแผนภาพไหนดูทนทานกว่า แต่ที่ว่าเราจ่ายเงินให้กับรูปแบบทราฟฟิกแบบไหน ทั้งสองแบบใช้งานได้ และล้มเหลวต่างวิธีกันด้วยต้นทุนที่ต่างกัน
นับความสัมพันธ์แบบเพียร์ก่อนสิ่งอื่นใด
ถ้ามี N ไซต์ ฟูลเมชต้องใช้ N คูณ N ลบหนึ่ง หารสอง อุโมงค์ ส่วนฮับใช้ N ที่ห้าไซต์นั่นคือสิบเทียบกับห้า ซึ่งยังฟังดูพอจัดการได้ ที่สิบห้าไซต์มันคือ 105 เทียบกับสิบห้า และความต่างไม่ใช่เลขคณิตอีกต่อไปแต่คือกำลังคน
ความสัมพันธ์แต่ละเส้นพาสถานะที่คุณต้องดูแลติดมาด้วย ใน IPsec นั่นหมายถึง security association หนึ่งรายการ อัตลักษณ์หนึ่งรายการ คีย์หรือใบรับรองหนึ่งรายการ การตรวจจับเพียร์ที่ตาย และเส้นทางอย่างน้อยหนึ่งเส้นต่อพรีฟิกซ์ปลายทาง ใน WireGuard นั่นหมายถึงคีย์สาธารณะหนึ่งคีย์และบล็อก AllowedIPs ต่อเพียร์ ซึ่งถูกกว่าต่อเพียร์แต่มาพร้อมกับการค้นพบที่เป็นศูนย์เลย ทั้งสองทาง ไซต์ใหม่คือการแก้คอนฟิกบนทุกไซต์ที่มีอยู่
ให้ส่วนผสมของทราฟฟิกเป็นตัวตัดสิน ไม่ใช่ภาพวาด
ถ้าทราฟฟิกสาขาส่วนใหญ่เป็นการเรียกใช้ ERP ส่วนกลางหรือคลัสเตอร์ไฟล์ ฮับไม่ใช่การประนีประนอม แต่คือรูปทรงที่ถูกต้อง ทราฟฟิกอยากไปที่นั่นอยู่แล้ว และจุดนโยบายจุดเดียวนั้นตรวจสอบได้ง่ายกว่าเมชของกฎแบบรายคู่ เมชได้ความซับซ้อนของมันมาคุ้มเมื่อสาขาแลกเปลี่ยนข้อมูลกันเอง การทำรีพลิเคชันระหว่างสองออฟฟิศ เสียงระหว่างไซต์ แชร์ CAD ที่วิศวกรกว่าสิบคนเปิดทั้งวัน
กรณีที่อึดอัดอยู่ตรงกลาง และมันคือเสียงส่วนใหญ่ วัดก่อนจะเถียง ดีกว่าเดาจากผังองค์กร
| Signal | Points to a hub | Points to a mesh |
|---|---|---|
| Branch-to-branch traffic | Occasional, small | Dominant, all day |
| Site count | Growing, past ten | Small and stable |
| Change rate | Frequent adds and moves | Rare |
| Failure tolerance | A second hub is affordable | Every site must survive alone |
อ่านตารางเป็นตัวตัดสินเสมอกัน ไม่ใช่กฎ ถ้าสามในสี่แถวชี้ทางเดียวกัน ปกติก็จบการออกแบบ ถ้าแบ่งครึ่งก็คือไฮบริด ซึ่งเป็นสิ่งที่เครือข่ายที่โตเต็มที่ส่วนใหญ่ลงเอยด้วยการใช้งานอยู่แล้ว
ฮับต้องถูกสั่งให้ส่งต่อ
อุโมงค์สโปกถึงฮับสองเส้นที่ใช้งานได้ไม่ได้สร้างการเข้าถึงระหว่างสโปก ฮับต้องเปิด IP forwarding มีเส้นทางไปยังเครือข่ายสโปกแต่ละแห่ง มีกฎไฟร์วอลล์ที่อนุญาตการส่งผ่าน และมีเส้นทางขากลับที่คิดไว้แล้ว สโปกแต่ละแห่งต้องมีเส้นทางสำหรับพรีฟิกซ์ของอีกไซต์ บนฮับลินุกซ์นั่นคือ net.ipv4.ip_forward=1 บวกกับเชน FORWARD ที่ไม่ทิ้งคู่นั้นไปอย่างเงียบ ๆ และบน IPsec แบบอิงนโยบายนั่นคือ traffic selector ที่ระบุซับเน็ตสโปกปลายทางทั้งสองด้าน บันทึกเรื่อง forwarding ของ strongSwan ครอบคลุมด้านเคอร์เนลและไฟร์วอลล์ เมื่อนั่นคือชั้นที่คุณขาดอยู่ การทดสอบราคาถูกคือส่งทราฟฟิกจากสโปกหนึ่งไปยังบริการบนอีกสโปกหนึ่งพร้อมดูเคาน์เตอร์ของฮับ กฎที่ไม่เคยเพิ่มขึ้นหมายถึงลำดับผิด ไม่ใช่เส้นทางผิด
นโยบายส่วนกลางก็เป็นส่วนที่มีประโยชน์ สาขาสามารถได้รับอนุญาตให้เข้าถึงบริการที่ใช้ร่วมกันโดยไม่ต้องเข้าถึงกันเอง และเมทริกซ์การเข้าถึงนั้นควรค่าแก่การเขียนไว้อย่างชัดเจน เส้นทางที่ขาดหายเป็นตัวแทนที่แย่สำหรับกฎที่ใครสักคนอ่านออก
ระวังเวอร์ชันที่ทำครึ่งเดียว สโปก A หาเส้นทางไปสโปก B ผ่านฮับ ฮับหาเส้นทางทั้งสองทาง และไฟร์วอลล์ของฮับอนุญาตการเชื่อมต่อใหม่จาก A แต่ไม่จาก B ทิศแรกทดสอบแล้วเรียบร้อย ทิศที่สองค้าง ซึ่งดูเหมือนความผิดพลาดของเส้นทางแต่ไม่ใช่
ออกแบบความล้มเหลวก่อน แล้วจึงออกแบบเส้นทางปกติ
ฮับเดียวคือการพึ่งพาร่วมและคอขวดของการส่งผ่าน และความซ้ำซ้อนคือจุดที่การออกแบบฮับมักผิดพลาด ฮับสองตัวหมายถึงทุกสโปกถืออุโมงค์สองเส้น และเส้นทางขากลับต้องสอดคล้องกับขาไป เมื่อไม่สอดคล้อง ไฟร์วอลล์แบบเก็บสถานะจะทิ้งคำตอบ และอาการคือการเชื่อมต่อที่เปิดขึ้นแล้วตายไป การติดตั้งขนาดใหญ่แก้ปัญหานี้ด้วยโปรโตคอลเราเตอร์บนอุโมงค์แทนพรีฟิกซ์แบบคงที่ ซึ่งเป็นเครื่องจักรที่มากกว่าแต่ตัดการเดาออกไป ไม่ว่าคุณจะเลือกอะไร จงเขียนเส้นทางขากลับไว้ข้างเส้นทางขาไป เพราะครึ่งขากลับคือครึ่งที่ไม่มีใครทดสอบ
เมชกระจายความเสี่ยงนั้น ความลิงก์ของไซต์หนึ่งล่มไม่ได้ตัดขาดไซต์อื่น มันยังเพิ่มจำนวนจุดที่การเลือกเส้นทางทำให้คุณประหลาดใจ และเซสชันแอปพลิเคชันก็ยังไม่รอดจากการเปลี่ยนเส้นทางได้ด้วยตัวเอง
ไม่ว่าการออกแบบแบบไหนก็ไม่รักษาเซสชัน TCP ให้มีชีวิตข้ามการสลับเส้นทางได้เอง ถ้าแอปพลิเคชันเชื่อมต่อใหม่ไม่ได้ โทโพโลยีก็ไม่ใช่ปัญหาของคุณ
เลือกด้วยต้นทุนการเปลี่ยนแปลง แล้วตรวจสอบเส้นทาง
เริ่มจากฮับ เพราะเป็นสิ่งที่ผิดพลาดแล้วเสียหายถูกกว่า แล้วเพิ่มอุโมงค์ตรงสำหรับคู่ที่ทราฟฟิกคุ้มค่าที่จะทำ ไฮบริดนั้นไม่ใช่ความล้มเหลวในการตัดสินใจ แต่เป็นดีไซน์ที่องค์กรส่วนใหญ่ลู่เข้าหาภายในหนึ่งปี สิ่งที่สำคัญคือลิงก์ตรงแต่ละเส้นมีเหตุผลที่ระบุไว้และมีเจ้าของ
จากนั้นตรวจสอบแผนภาพทั้งสอง ไม่ใช่ภาพเดียว สำหรับเส้นทางปกติ ให้รัน traceroute จากแต่ละไซต์ไปยังพรีฟิกซ์บริการแต่ละรายการและยืนยันว่าฮอปตรงกับแผนภาพ สำหรับเส้นทางล้มเหลว ให้ปิดอุโมงค์หนึ่งเส้นแล้วทำซ้ำ เพราะเส้นทางที่ใช้ได้เฉพาะตอนที่ทุกอย่างยังทำงานอยู่ยังไม่ได้ถูกออกแบบ แค่ถูกตั้งค่า
เก็บแผนภาพทั้งสองไว้กับเมทริกซ์การเข้าถึง และกลับมาดูเมื่อมีไซต์เพิ่ม ต้นทุนที่คุณจัดการอยู่คือต้นทุนของการเปลี่ยนแปลงครั้งถัดไป ไม่ใช่ความสวยงามของภาพปัจจุบัน