OpenVPN trên cổng 53: ba cuộc trò chuyện thường bị nhầm lẫn
Việc phân giải tên điểm cuối, truyền tải mã hóa và DNS sau đường hầm là ba cuộc trò chuyện. Hãy xác định giai đoạn nào thất bại trước khi đổi cổng hoặc trình phân giải.
Các báo cáo nói rằng VPN bị chặn trên cổng 53 trộn lẫn ba quan sát thất bại vì những lý do khác nhau. Việc phân giải tên điểm cuối diễn ra trước khi có bất kỳ đường hầm nào, truyền tải mã hóa là một cuộc trò chuyện riêng, và các truy vấn DNS thực hiện sau đó là cuộc thứ ba. Mỗi cuộc có dấu hiệu thất bại riêng, và chỉ một trong số đó thực sự liên quan đến DNS.
Trước khi thay đổi bất cứ điều gì, hãy phân loại gói tin theo mục đích, vì cách khắc phục đi theo từng giai đoạn.
Ba cuộc trò chuyện, một số cổng
Cuộc trò chuyện đầu tiên là việc tra tên cho điểm cuối: máy của bạn hỏi trình phân giải đã cấu hình xem vpn.example.com nằm ở đâu, và câu trả lời đó đến qua DNS thông thường trước khi ứng dụng khách gửi dù chỉ một gói đường hầm. Cuộc thứ hai là chính phần truyền tải OpenVPN, kết nối tới địa chỉ mà việc tra cứu tạo ra, theo giao thức và cổng mà tệp cấu hình chỉ định. Cuộc thứ ba diễn ra sau khi đường hầm hoạt động, khi ứng dụng yêu cầu tên và các thiết lập trình phân giải được đẩy xuống quyết định ai sẽ trả lời.
Ba cuộc này có thể thành công hoặc thất bại độc lập. Ứng dụng khách có thể phân giải điểm cuối hoàn hảo mà vẫn không tới được bên lắng nghe, và có thể thiết lập đường hầm trong khi mọi lần tra tên nội bộ đều thất bại vì thiết lập DNS không bao giờ đến.
| Conversation | When it happens | What has to be true |
|---|---|---|
| Endpoint lookup | Before the client contacts a hostname | An underlying resolver path can answer for the endpoint name |
| OpenVPN transport | During tunnel establishment | The gateway listens on its configured transport, address and port, and nothing filters it |
| Application DNS | During or after the protected session | A resolver the client can reach, plus routing that carries its queries |
Hãy đọc bảng như một danh sách kiểm tra chứ không phải bản mô tả. Nếu tên điểm cuối không phân giải được, mọi thứ sau đó đều không thể hoạt động, và đường hầm không bao giờ bắt đầu.
Số cổng không đặt tên cho ứng dụng
Cổng 53 mang DNS theo quy ước, và nhà vận hành OpenVPN cũng có thể công bố một bên lắng nghe ở đó, chính vì thế con số này là một định danh kém. Phiên OpenVPN trên UDP 53 vẫn là phiên OpenVPN, và một truy vấn DNS tới máy chủ trên cổng 53 không nói gì về việc đường hầm có được phép hay không. Các dòng proto và remote của tệp cấu hình xác định điểm cuối bên ngoài; bản thân số cổng không xác định gì cả.
Khi chẩn đoán, điều này cắt cả hai chiều: một phép thử UDP chung tới cổng 53 chứng minh rằng có một cổng trả lời, chứ không phải dịch vụ VPN trả lời. Hãy kiểm tra bằng ứng dụng khách thật và tệp cấu hình thật, vì chỉ cách đó mới diễn tập được thao tác bắt tay mà dịch vụ mong đợi.
Hãy chứng minh bên lắng nghe trước khi đổ lỗi cho mạng
Trên máy chủ, xác nhận thứ gì đang được gắn bằng ss -lunp | grep 53 và so sánh với giao thức cùng cổng của tệp cấu hình. Từ mạng của ứng dụng khách, chạy ứng dụng khách với mức chi tiết cao hơn để nhật ký cho thấy nó đã thử địa chỉ và cách truyền nào. Nếu máy chủ đang lắng nghe mà gói tin của ứng dụng khách không đến, thì đường đi hoặc chính sách đang từ chối chúng, và đó là cuộc trò chuyện với chủ sở hữu mạng chứ không phải lý do để đổi cổng.
Một cổng khác chỉ giúp ích khi dịch vụ thực sự lắng nghe ở đó và việc triển khai cho phép. Việc di chuyển bên lắng nghe để né bộ lọc của một mạng được quản lý là quyết định về chính sách, không phải bước xử lý sự cố. Hãy hỏi chủ sở hữu mạng xem điều gì được phép trước khi đổi dịch vụ, vì giải pháp vòng tránh vi phạm chính sách rồi cũng sẽ bị đóng sau này. Ghi lại câu trả lời đó bên cạnh tệp cấu hình để người tiếp theo không lặp lại yêu cầu.
Kiểm tra DNS sau đường hầm, một cách riêng biệt
Khi đường hầm đã hoạt động, hãy xem trạng thái trình phân giải trên giao diện VPN và truy vấn một tên nội bộ cùng một tên công khai. Nếu các tên nội bộ thất bại trong khi đường hầm đang mang lưu lượng, thì thiết lập DNS được đẩy xuống đã không được áp dụng, đó là vấn đề tích hợp ứng dụng khách chứ không phải truyền tải. Nếu các tên công khai thất bại mà tên nội bộ vẫn hoạt động, thì chính sách đường hầm chia tách đang làm đúng như đã cấu hình.
Hãy để các thay đổi DNS cho chủ sở hữu trình phân giải. Ghi đè cấu hình trình phân giải được quản lý để một lần kiểm tra đạt có thể làm hỏng các tên riêng cho mọi thứ khác trên máy. Nếu đường hầm đẩy một trình phân giải và ứng dụng khách bỏ qua nó, hãy sửa phần tích hợp ứng dụng khách thay vì thêm một mục tĩnh ở nơi khác. Các mục tĩnh che giấu sự cố cho đến khi ai đó đổi mạng. Hãy ghi rõ trình phân giải nào được cho là trả lời từng vùng tên.