แล็บที่บ้านกับอุโมงค์แบบแยกส่วน: กำหนดเส้นทางเฉพาะสิ่งที่ต้องใช้ ไม่ใช่ทุกอย่าง

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

ความเชื่อที่ว่าการแยกอุโมงค์คือการประนีประนอม

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

มันยังซ่อนสมมติฐานที่สองไว้ คือการกำหนดที่อยู่ของแล็บไม่มีความเกี่ยวข้องกับเครือข่ายที่คุณเชื่อมต่อ

ทำบัญชีทรัพยากรก่อนกำหนดเส้นทาง

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

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

ห้าแถวกับคอลัมน์การตัดสินใจชนะตารางเส้นทางที่ไม่มีใครอ่านได้

เกตเวย์ต้องมีเส้นทางขากลับ

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

กลุ่มไคลเอนต์ที่ทับซ้อนกับการกำหนดที่อยู่ของแล็บเองคืออีกครึ่งหนึ่งของปัญหานี้ และมันล้มเหลวแบบเดียวกันทุกประการ

แก้แผน ไม่ใช่แก้เฉพาะอาการ เมื่อช่วงทั้งสองชนกัน

บทบาทการบริหารกับอินเทอร์เน็ตแยกจากกัน

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

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

การแยกทั้งสองออกจากกันคือสิ่งที่ทำให้รูปแบบความล้มเหลวแยกแยะได้ในภายหลัง

ทดสอบจากภายนอก ไม่ใช่จาก LAN

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

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

เส้นทางที่ไม่ได้รับการอธิบายซึ่งทับซ้อนกับเครือข่ายบ้านที่มีอยู่คือผลลัพธ์เริ่มต้นของการข้ามขั้นตอนนั้น

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