TAP โดยไม่มีบริดจ์: เซกเมนต์เสมือนที่มีอัปลิงก์แบบกำหนดเส้นทาง

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

สร้างเซกเมนต์ที่แยกเดี่ยว

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

ip tuntap add dev tap0 mode tap
ip link set tap0 up
ip addr add 10.77.0.1/24 dev tap0

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

กำหนดเส้นทางข้ามพรมแดน

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

เขียนเส้นทางและกฎไฟร์วอลล์เป็นการเปลี่ยนแปลงเดียว เพราะแต่ละอย่างเดี่ยว ๆ สร้างสภาพที่ดูเหมือนความล้มเหลวในการกำหนดเส้นทางจากฝั่งไคลเอนต์

ตัดสินใจเส้นทางกลับ

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

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

รักษาขอบเขตการออกอากาศอย่างตั้งใจ

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

นี่คือเหตุผลที่ซื่อสัตย์ในการเลือก TAP ตั้งแต่แรก: บางสิ่งบนเซกเมนต์เสมือนต้องการพฤติกรรมภายในลิงก์ หากไม่มีอะไรต้องการ อุปกรณ์ TUN ที่มีคำนำหน้าแบบกำหนดเส้นทางจะเล็กกว่า และมีอะไรให้อธิบายน้อยกว่าเมื่อมันเสีย

ตรวจสอบ แล้วเขียนการย้อนกลับ

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

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