Phục vụ OpenVPN qua TCP và UDP từ một máy chủ
Một tiến trình chỉ gắn một giao vận trước 2.7. Hãy so sánh một cặp TAP có cầu nối, hai mạng con TUN và một bể địa chỉ dùng chung, rồi khớp từng hồ sơ với bộ lắng nghe của nó.
Các mạng chỉ cho phép TCP 443 tồn tại song song với những mạng cho UDP đi qua thoải mái, và một máy chủ phải phục vụ cả hai. Một hồ sơ có proto udp trả lời nhóm thứ hai và thất bại ở nhóm thứ nhất, và việc sửa cùng cấu hình đó thành proto tcp không tạo ra bộ lắng nghe thứ hai. Chỉ thị chọn một giao vận cho một tiến trình. Mọi thứ còn lại đều suy ra từ ràng buộc đó.
Hoặc bạn chạy nhiều hơn một tiến trình, hoặc bạn chạy một phiên bản có thể gắn nhiều socket cùng lúc.
Một tiến trình chỉ gắn một giao vận trước 2.7
OpenVPN của cộng đồng gắn socket mà proto mô tả, và chỉ thị đó chọn một giao vận duy nhất cho thực thể. TCP và UDP là hai ngăn xếp riêng, nên cùng một số cổng có thể bị cả hai chiếm cùng lúc, nhưng không thể do một tiến trình. Vì vậy dòng 2.6 cho bạn một giao vận cho mỗi daemon. OpenVPN 2.7 đã bỏ ràng buộc đó với máy chủ, vốn có thể gắn nhiều socket qua nhiều câu --local trong một tiến trình.
Hãy kiểm tra phiên bản trước khi thiết kế quanh bất kỳ câu trả lời nào, vì cách bố trí 2.7 là một mô hình vận hành khác với cú pháp cấu hình riêng. Một hướng dẫn viết cho 2.6 mô tả hai tiến trình ngay cả khi không nói ra.
Ba cách chạy hai thực thể
Với giao diện TAP, chạy một thực thể cho mỗi giao vận và bắc cầu hai thiết bị tap trên máy chủ. Cả hai nhóm máy khách nằm trong cùng miền quảng bá, nhờ đó một bể địa chỉ có thể bao phủ chúng và các giao thức phụ thuộc quảng bá vẫn hoạt động. Với TUN không thể bắc cầu, nên cách chia đơn giản nhất cấp cho mỗi thực thể một mạng con riêng và để định tuyến tách hai nhóm máy khách. Lựa chọn thứ ba giữ một bể bằng cách để mỗi thực thể gọi một script learn-address cài tuyến /32 cho máy khách qua thiết bị của thực thể đó.
Cách bố trí thứ ba đó là thứ người ta yêu cầu và là thứ cần cẩn thận nhất, vì script trở thành một phần của đường dữ liệu và phải xử lý đúng các sự kiện thêm, cập nhật và xóa.
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
Giữ hai thực thể tách biệt
Mỗi thực thể cũng cần một cổng hoặc địa chỉ riêng, một tệp trạng thái riêng và một đích ghi log riêng. Hai daemon cùng ghi vào một tệp trạng thái tạo ra đầu ra không thể đọc được khi có sự cố, mà đó chính là lúc bạn cần nó. Nếu thực thể thứ hai gắn một địa chỉ cụ thể, địa chỉ đó phải tồn tại trên máy chủ khi tiến trình khởi động; nếu không nó thoát với lỗi gắn kết trước khi nói bất cứ điều gì về khóa.
Đặt tên cho unit và hồ sơ để có thể thấy giao vận ngay từ tên tệp. Người vận hành tiếp theo không nên phải mở cấu hình để biết cái nào là TCP.
Khớp hồ sơ với bộ lắng nghe
Máy chủ chạy proto tcp mong đợi hồ sơ máy khách có proto tcp-client, và hồ sơ vẫn mang proto udp khi gặp bộ lắng nghe đó sẽ hết thời gian mà không có lỗi nào để người dùng xử lý. Giữ hai hồ sơ nếu bản triển khai cung cấp cả hai giao vận, và dán nhãn để bộ phận hỗ trợ biết cái nào đã được thử. Chỉ số cổng không mô tả giao vận.
Các quy tắc tường lửa cũng theo cách chia đó: một quy tắc cho UDP 1194 không nói gì về TCP 1194, và một quy tắc cho một địa chỉ không bao phủ bộ lắng nghe còn lại.
Đọc góc nhìn của máy chủ trước
Bắt đầu bằng ss -lntup trên máy chủ và xác nhận rằng cả bộ lắng nghe TCP và UDP đều xuất hiện. Sau đó kết nối mỗi loại một máy khách và kiểm tra đầu ra trạng thái xem có hai mục với địa chỉ khác nhau. Nếu socket tồn tại mà không có máy khách nào đến, đường đi hoặc tường lửa đang từ chối gói trước khi daemon nhìn thấy chúng.
Một socket không bao giờ xuất hiện là vấn đề cấu hình hoặc gắn kết, còn một socket xuất hiện nhưng không bao giờ ghi nhận kết nối là vấn đề lọc. Từ phía máy khách hai thứ đó trông giống hệt nhau, vì vậy góc nhìn của chính máy chủ được xét trước. Hãy nhớ rằng TCP mang theo chặn đầu hàng, nên cung cấp nó là một biện pháp về khả năng tiếp cận chứ không phải nâng cấp cho máy khách có đường UDP sạch.