OpenVPN và HTTPS trên cổng 443: listener thuộc về ai?
TCP và UDP 443 là hai socket riêng. Chia sẻ một listener TCP cần một chủ sở hữu, và chia sẻ cổng của OpenVPN là một thỏa thuận hẹp, không phải mẹo proxy.
Hai dịch vụ có thể cùng trả lời trên cổng 443 mà không bao giờ cạnh tranh, vì listener được xác định bởi giao vận, địa chỉ và cổng cùng nhau, không chỉ bởi con số. Đặt một máy chủ web và OpenVPN trên cùng một máy, và câu hỏi duy nhất đáng trả lời trước là mỗi tiến trình yêu cầu socket nào từ nhân. Ghi danh sách đó ra trước khi sửa cấu hình, và phần lớn lỗi «địa chỉ đã được sử dụng» tự giải thích. Mọi thứ sau danh sách là lựa chọn giữa listener UDP, socket TCP dùng chung hoặc phần đầu định tuyến theo giao thức.
Bắt đầu từ socket mà mỗi tiến trình yêu cầu
Bind thành công hay thất bại theo bộ ba đó, nên hai daemon chỉ xung đột khi cả ba phần trùng nhau. Đó là lý do một website trên TCP 443 cùng tồn tại vô hạn với một listener OpenVPN trên UDP 443, và cũng là lý do việc chuyển một trong hai sang địa chỉ cục bộ thứ hai trên cùng máy chủ cũng kết thúc cuộc tranh luận. Đọc các listener đang sống, không phải những tệp lẽ ra phải tạo ra chúng, vì một include cũ hoặc một tệp unit bị quên sống lâu hơn chỉnh sửa mà bạn nhớ đã làm.
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
Chạy ss -lntup với quyền root và đọc mọi dòng nhắc đến 443, kể cả các mục IPv6. Thường thì listener v6 đại diện cũng nhận lưu lượng v4, và đó là cách một listener bạn quên vẫn giữ cổng bận sau khi bạn đổi tệp mà bạn tưởng là thủ phạm. Nếu tên tiến trình làm bạn ngạc nhiên, hãy thu hẹp đầu ra bằng ss -lntup 'sport = :443' trước khi chạm vào bất cứ thứ gì.
Chuyển đường hầm sang UDP khi mạng cho phép
Listener UDP tránh hoàn toàn xung đột và thường là cách sửa ngắn nhất, vì không socket nào bị chia sẻ và không sản phẩm phụ nào đi vào đường dẫn. Nhưng nó không miễn phí. Một số mạng khách hàng bỏ UDP 443 mà không gửi reset, nên đường hầm ngừng thiết lập thay vì thất bại ở bind, và người dùng báo VPN chết mà không có lỗi nào để đọc. Listener UDP cũng sống sót qua lần khởi động lại tầng web, điều này đáng kể trên một máy có website được triển khai lại thường xuyên. Hãy thử từ mạng nơi người dùng ngồi, vì một shell trên máy chủ chỉ chứng minh máy chủ tự tới được chính nó.
Đổi giao vận trong cấu hình máy chủ và trong hồ sơ máy khách cùng lúc. Một hồ sơ vẫn yêu cầu TCP sẽ quay vòng trong các chu kỳ kết nối lại với listener chỉ có UDP, và điều đó trông như sự cố mạng cho tới khi bạn so hai tệp.
Để tiến trình VPN sở hữu TCP 443 và chuyển tiếp phần còn lại
Community OpenVPN ở chế độ máy chủ TCP đọc những byte đầu của một kết nối đến và chuyển mọi thứ không phải giao thức của nó tới một backend HTTPS, đó là mục đích của chỉ thị port-share. Backend là một máy chủ web thông thường có TLS bật, được đặt tên bằng máy chủ và cổng trong chỉ thị đó chứ không bằng URL.
port-share 10.0.0.5 8080
Trên một máy mà website có địa chỉ riêng thứ hai, dòng đó gửi lưu lượng không phải VPN tới 10.0.0.5:8080, nên máy chủ ảo HTTPS phải được gắn ở đó và tường lửa phải cho phép bước nhảy cục bộ. Máy chủ web phải tự kết thúc TLS, vì các byte đến là bắt tay gốc của trình duyệt và không gì ở giữa đã giải mã chúng. Hướng chỉ thị tới một listener HTTP thường và trình duyệt nhận lỗi phương thức không hợp lệ, thứ được đọc như một site hỏng chứ không phải backend đặt sai chỗ. Chỉ thị chỉ tồn tại ở chế độ máy chủ TCP, và listener UDP không có luồng nào để kiểm tra.
Vì tiến trình VPN chấp nhận mọi kết nối, ứng dụng web thấy yêu cầu được chuyển tiếp đến từ một trong các địa chỉ của chính máy chủ thay vì từ người truy cập. Mọi thứ cần địa chỉ máy khách thật đều phụ thuộc vào hỗ trợ giao thức PROXY ở backend hoặc vào một phần đầu thêm nó vào. Chuyển backend sang địa chỉ cục bộ khác không mang địa chỉ người truy cập trở lại; nó chỉ đổi việc site ghi lại địa chỉ nào của máy chủ. Ghi hạn chế đó vào ghi chú triển khai trước khi một báo cáo phân tích đặt câu hỏi.
Proxy ngược là công cụ sai; bộ định tuyến lớp bốn thì không
Proxy ngược HTTP kết thúc TLS để đọc yêu cầu, nghĩa là nó không thể cho một luồng OpenVPN đi qua nguyên vẹn. Một bộ định tuyến lớp bốn chuyển tiếp theo SNI hoặc theo việc kiểm tra gói đầu tiên có thể đứng trước cả hai, miễn là nó không kết thúc phiên mà VPN phụ thuộc vào. Hai thiết bị trông giống nhau trên sơ đồ và hành xử hoàn toàn khác nhau ở socket.
Access Server thương mại đi kèm cài đặt chia sẻ cổng riêng, và chúng không ánh xạ một-một sang chỉ thị của cộng đồng. Xác định sản phẩm và phiên bản trước khi chuyển thể hướng dẫn viết cho cái kia. Một cài đặt sao chép bị bỏ qua trong im lặng còn tệ hơn không có cài đặt, vì danh sách listener sau đó vẫn trông hợp lý.
Thử website và đường hầm như hai đường riêng
Tải site và kết nối đường hầm, rồi đọc lại danh sách listener để xem tiến trình nào sở hữu 443 lúc này. Một trang tải được không chứng minh gì về VPN, và một đường hầm kết nối được không chứng minh gì về site, dù cả hai dùng cùng con số. Ba lệnh dưới đây kiểm tra socket dùng chung, đường web và dịch vụ VPN theo đúng thứ tự đó.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
So sánh địa chỉ máy khách trong nhật ký truy cập của backend với địa chỉ trong nhật ký VPN ở cùng thời điểm. Nếu site ghi mọi người truy cập là chính máy chủ, việc chuyển tiếp hoạt động còn việc xử lý địa chỉ thì không. Nếu cả hai nhật ký đều im lặng, phần đầu chưa bao giờ trao kết nối. Dù thế nào, danh sách listener quyết định ai nhận socket, và đó là sự thật cần xác nhận trước khi bạn đổi một tệp khác.
Để bản đồ listener đó bên cạnh cấu hình để người tiếp theo chạm vào 443 biết tiến trình nào nhận và giao thức kia đã đi đâu. Xác nhận quyền sở hữu sau thay đổi thay vì tin vào điều mà chỉnh sửa định làm.