Relay stream của Nginx cho UDP của OpenVPN: điều gì thay đổi

Máy khách của bạn được đặt thành UDP, máy chủ Nginx có một khối location trỏ tới cổng VPN, và không có gì đến. Điều đó là dự kiến: một location HTTP không thể mang một datagram UDP, bất kể phần giao diện được gọi là gì. Nginx cần một trình lắng nghe stream cho việc này, và một khi bạn chuyển cấu hình tới đó, một nhóm chi tiết thứ hai sẽ quyết định liệu phiên có sống sót.

Lớp proxy đến trước địa chỉ

Mô-đun stream của Nginx proxy TCP và UDP mà không phân tích HTTP. Mô-đun HTTP của nó mong đợi một dòng yêu cầu, các tiêu đề và một phản hồi, và không có thứ nào trong số đó trong một OpenVPN datagram gốc. Vì vậy việc chọn lớp là quyết định đầu tiên, và nó độc lập với việc trình lắng nghe là IPv4 hay IPv6.

Một cấu hình có vẻ hoạt động với OpenVPN trên TCP không nói gì về trường hợp UDP. Ở đây truyền tải là một phần của giao thức, không phải chi tiết của việc triển khai.

Trình lắng nghe và backend

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

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

Xác nhận rằng bản dựng bao gồm mô-đun stream trước khi sửa bất cứ điều gì; một gói phân phối có thể tách nó thành mô-đun riêng, và mô-đun thiếu sẽ tạo ra lỗi cấu hình thay vì một đường hầm. Đặt khối trong ngữ cảnh cấu hình chính, không phải bên trong http, và thay địa chỉ tài liệu bằng backend thật.

Cả hai tuyến và cả hai tường lửa phải cho phép các datagram: đường tới trình lắng nghe và đường từ proxy tới backend. Một trình lắng nghe IPv6 cũng không tạo ra đường IPv4, nên nếu một số máy khách vẫn dùng IPv4 thì trình lắng nghe đó là một mục riêng với bài kiểm tra riêng. Hãy kiểm tra tường lửa của chính backend từ địa chỉ của proxy, không phải từ máy tính xách tay của bạn.

Thời gian chờ phiên không phải thời gian chờ yêu cầu

Proxy stream giữ trạng thái cho một phiên UDP và loại bỏ nó theo thời gian chờ và cài đặt phản hồi của nó. Một thời gian chờ ngắn sao chép từ relay DNS không phù hợp với một VPN kỳ vọng trao đổi datagram hàng giờ, và sự cố xuất hiện như một kết nối chết lặng lẽ thay vì một kết nối từ chối khởi động.

Đọc proxy_timeout hiệu lực của việc triển khai và mọi cài đặt đếm phản hồi, rồi so sánh chúng với hành vi keepalive mà VPN thực sự dùng. Hai con số do những người khác nhau viết trong các tệp khác nhau là trạng thái bình thường của một hệ thống đang hoạt động. Hai con số chưa từng được so sánh là trạng thái bình thường của một hệ thống chập chờn. Hãy ghi cả hai vào hồ sơ dịch vụ để việc so sánh diễn ra một lần, dưới ánh sáng ban ngày.

Relay thay đổi điều gì và không thay đổi điều gì

Proxy stream không kết thúc kênh điều khiển TLS của OpenVPN và không chuyển nó thành HTTPS. Backend vẫn là dịch vụ VPN, và mối quan hệ chứng chỉ vẫn ở giữa máy khách và dịch vụ đó. Việc giữ nguyên danh tính backend dự định vẫn là công việc của máy khách và máy chủ.

Proxy thông thường cũng thay đổi địa chỉ nguồn mà backend nhìn thấy. Nhật ký sẽ hiển thị proxy, và bất kỳ quy tắc truy cập dựa trên IP nào trên máy chủ VPN sẽ đánh giá địa chỉ đó thay vì địa chỉ của máy khách. Việc giữ nguồn trong suốt là một thiết kế định tuyến và đặc quyền riêng, không phải điều gì đó xuất phát từ việc thêm udp vào một trình lắng nghe. Hãy lập kế hoạch cho nó trước khi một chính sách phụ thuộc vào địa chỉ máy khách được viết ra.

Xác minh từ máy khách, không phải từ cổng

Một kiểm tra cục bộ rằng cổng UDP đang mở chứng minh trình lắng nghe tồn tại. Nó không chứng minh rằng một máy khách có thể xác thực qua đó hoặc tiếp tục trao đổi lưu lượng. Hãy hoàn thành một kết nối thật từ một máy khách đã được phê duyệt, rồi xác nhận phiên duy trì đủ lâu để có ý nghĩa.

Khi ai đó báo cáo rằng Nginx không làm được UDP vì một công cụ relay đơn giản đã hoạt động thay thế, hai sự kiện đó không liên quan. Công cụ đã chứng minh rằng backend phản hồi; nó không nói gì về những gì giao diện hỗ trợ. Cả hai đều có thể đúng, và chỉ một trong số đó là cấu hình cho việc triển khai này.