ทำไมพร็อกซีของ Cloudflare จึงพา OpenVPN ไปบนชื่อเดียวไม่ได้

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

สองชื่อ สองเส้นทางขนส่ง

ให้เว็บไซต์มีระเบียนที่ผ่านพร็อกซีเพื่อให้ทราฟฟิก HTTP และ HTTPS ของมันผ่าน Cloudflare ให้ VPN มีระเบียนแบบ DNS เท่านั้นที่แปลงตรงไปยังทางเข้า VPN สาธารณะ และให้ไคลเอนต์ใช้พอร์ต UDP หรือ TCP ที่มันถูกกำหนดค่าไว้

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

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

พอร์ตไม่ใช่โปรโตคอล

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

หากข้อกำหนดคือการวางผลิตภัณฑ์ของ Cloudflare ลงในเส้นทางข้อมูลของ VPN จริง ๆ ให้ประเมินผลิตภัณฑ์ที่เอกสารระบุว่าสนับสนุนโปรโตคอลที่คุณต้องการ อย่าสันนิษฐานว่าเมฆสีส้มเป็นอุโมงค์ TCP หรือ UDP ทั่วไป เพราะมันคือพร็อกซีย้อนกลับสำหรับทราฟฟิกเว็บที่มีหน้าที่เฉพาะ

ระเบียนแบบ DNS เท่านั้นคือคำตอบน่าเบื่อที่ได้ผล และเป็นสิ่งที่ควรเอื้อมไปหก่อน

เครื่องเดียวยังต้องมีผู้ฟังสองตัว

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

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

ใบรับรองเป็นไปตามการเชื่อมต่อที่มันปกป้อง

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

ใบรับรองต้นทางนั้นได้รับความไว้วางใจจาก Cloudflare ในโหมด Full (strict) และไม่ใช่ใบรับรองเบราว์เซอร์ที่ได้รับความไว้วางใจทั่วไป หากมีคนเข้าชื่อโฮสต์แบบ DNS เท่านั้นโดยตรงและได้รับคำเตือน นั่นคือผลลัพธ์ที่คาดไว้ของเส้นทางความไว้วางใจที่เปลี่ยนไป ไม่ใช่หลักฐานว่าการเข้ารหัสหยุดลง

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

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

การเปิดเผยเป็นไปตามชื่อ

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

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

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

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