เส้นทางแบบสแตติกหรือโปรโตคอลเราเตอร์บน VPN แบบไซต์ถึงไซต์

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

สามเงื่อนไขเป็นตัวตัดสิน

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

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

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

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

สแตติกเราเตอร์มีต้นทุนจริงเท่าไร

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

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

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

ไดนามิกเราเตอร์มีต้นทุนจริงเท่าไร

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

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

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

ควบคุมว่าเซสชันเราเตอร์พูดอะไรได้

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

เขียนไซต์เจ้าของไว้ข้าง ๆ ทุกเครือข่ายก่อนที่เซสชันแรกจะขึ้น เพราะการแมปนั้นคือแหล่งที่มาของรายการตัวกรอง ไม่ใช่ของประดับเอกสาร หากไม่มี คนที่แก้ไขตัวกรองต้องเดาว่าไซต์ใดควรประกาศพรีฟิกซ์

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

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

ทดสอบเส้นทางที่ล้มเหลว ไม่ใช่เส้นทางที่ราบรื่น

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

จากนั้นยืนยันเส้นทางขากลับแยกต่างหาก เพราะเราเตอร์แบบอสมมาตรบน VPN เป็นเรื่องปกติและมองไม่เห็นจนกว่าอุปกรณ์ที่มีสถานะจะทิ้งคำตอบ การไหลที่ทำงานได้ทางเดียวพิสูจน์ได้เพียงครึ่งของเส้นทาง

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