HTTPS ในคอนเทนเนอร์ค้างบน VPN องค์กร? ทดสอบขา DTLS

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

สองเส้นทาง หนึ่งอาการที่สับสน

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

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

ตัดสินด้วยการทดลอง ไม่ใช่ด้วยสัญชาตญาณ

การทดลองที่ถูกที่สุดคือปิดช่องข้อมูล UDP แล้วทำคำขอซ้ำ ใช้ไคลเอนต์บรรทัดคำสั่งแทนตัวห่อเดสก์ท็อป เพื่อให้แฟล็กถูกใช้จริง: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls หากคำขอที่ค้างอยู่เสร็จสิ้นตอนนี้ ขา DTLS คือปัญหาและส่วนที่เหลือเป็นเพียงเสียงรบกวน

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

หากแฟล็กแก้ได้ ให้ตัดสินว่าเพราะอะไร

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

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

ตรวจขนาดแพ็กเก็ตก่อนจะเก็บวิธีเลี่ยงไว้

หากขนาดเป็นสาเหตุ อินเทอร์เฟซอุโมงค์รับแพ็กเก็ตที่เส้นทางแบกไม่ได้ และปัญหาจะกลับมาบนเส้นทางใดก็ตามทันทีที่เพย์โหลดโตขึ้น เปรียบเทียบอินเทอร์เฟซ: ip link show tun0 บนโฮสต์ แล้ว docker network inspect bridge เพื่ออ่าน MTU ที่บันทึกไว้ในตัวเลือกเครือข่าย บริดจ์คอนเทนเนอร์ที่ยังอยู่ที่ 1500 ไบต์ใต้อุโมงค์ที่แบกได้น้อยกว่าคือสิ่งที่พบเป็นปกติ

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

ตัดสินว่าคุณยอมแลกอะไร

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

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