Nginx stream relay สำหรับ UDP ของ OpenVPN: อะไรเปลี่ยนไป

ไคลเอนต์ของคุณตั้งเป็น UDP เซิร์ฟเวอร์ Nginx มีบล็อก location ที่ชี้ไปยังพอร์ต VPN และไม่มีอะไรมาถึง นี่คือสิ่งที่คาดไว้: location ของ HTTP ไม่สามารถขนส่งดาต้าแกรม UDP ได้ ไม่ว่าจะเรียกส่วนหน้าว่าอะไร Nginx ต้องมีตัวรับฟัง stream สำหรับเรื่องนี้ และเมื่อย้ายการตั้งค่าไปที่นั่นแล้ว รายละเอียดชุดที่สองจะเป็นตัวตัดสินว่าเซสชันจะอยู่รอดหรือไม่

ชั้นพร็อกซีมาก่อนที่อยู่

โมดูล stream ของ Nginx พร็อกซี TCP และ UDP โดยไม่แยกวิเคราะห์ HTTP โมดูล HTTP ของมันคาดหวังบรรทัดคำขอ ส่วนหัว และการตอบกลับ ซึ่งไม่มีอยู่ใน OpenVPN ดาต้าแกรมแบบเนทีฟ การเลือกชั้นจึงเป็นการตัดสินใจแรก และไม่ขึ้นกับว่าตัวรับฟังเป็น IPv4 หรือ IPv6

การตั้งค่าที่ดูเหมือนทำงานกับ OpenVPN บน TCP ไม่ได้บอกอะไรเกี่ยวกับกรณี UDP การรับส่งเป็นส่วนหนึ่งของโปรโตคอลในที่นี้ ไม่ใช่รายละเอียดของการติดตั้ง

ตัวรับฟังและแบ็กเอนด์

nginx -V 2>&1 | tr ' ' '\n' | grep stream

stream {
    server {
        listen [::]:1194 udp reuseport;
        proxy_pass [2001:db8::20]:1194;
    }
}

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

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

เวลาหมดอายุของเซสชันไม่ใช่เวลาหมดอายุของคำขอ

พร็อกซี stream เก็บสถานะของเซสชัน UDP และทิ้งตามเวลาหมดอายุและการตั้งค่าการตอบกลับ เวลาหมดอายุสั้น ๆ ที่คัดลอกมาจากรีเลย์ DNS ไม่เหมาะกับ VPN ที่คาดว่าจะแลกเปลี่ยนดาต้าแกรมเป็นชั่วโมง ๆ และความล้มเหลวจะปรากฏเป็นการเชื่อมต่อที่ตายอย่างเงียบ ๆ ไม่ใช่การเชื่อมต่อที่ปฏิเสธจะเริ่ม

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

รีเลย์เปลี่ยนอะไร และไม่เปลี่ยนอะไร

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

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

ตรวจสอบจากไคลเอนต์ ไม่ใช่จากพอร์ต

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

เมื่อมีคนรายงานว่า Nginx ทำ UDP ไม่ได้เพราะเครื่องมือรีเลย์ง่าย ๆ ทำงานแทนได้ ข้อเท็จจริงสองข้อนั้นไม่เกี่ยวข้องกัน เครื่องมือนั้นพิสูจน์ว่าแบ็กเอนด์ตอบสนอง แต่ไม่ได้พูดอะไรเกี่ยวกับสิ่งที่ส่วนหน้าสนับสนุน ทั้งสองอย่างเป็นจริงได้ และมีเพียงอย่างเดียวเท่านั้นที่เป็นการตั้งค่าสำหรับการติดตั้งนี้