OpenVPN TUN กับ TAP: สามเงื่อนไขที่ใช้ตัดสิน

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

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

แต่ละอินเทอร์เฟซขนส่งอะไรจริง ๆ

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

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

เงื่อนไขแรก: มีอะไรที่ต้องการเลเยอร์สองหรือไม่

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

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

เงื่อนไขที่สอง: ไคลเอนต์ทำได้หรือไม่

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

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

เงื่อนไขที่สาม: นี่เป็นคำถามเรื่องอินเทอร์เฟซจริงหรือ

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

ไคลเอนต์ที่เชื่อมต่อได้แล้วแต่เข้าถึงโฮสต์ภายในหนึ่งเครื่องไม่ได้ มักกำลังดูการกำหนดเส้นทาง กฎไฟร์วอลล์ หรือเส้นทางขากลับที่หายไป

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

คำถามไม่ใช่ว่าตัวเลือกใดแข็งแกร่งกว่า แต่คือทราฟฟิกต้องการสิ่งใดจริง ๆ