OpenVPN: local so với địa chỉ đường hầm, hai socket khác nhau
Địa chỉ liên hệ với máy chủ không phải là địa chỉ bên trong đường hầm. Đọc local, remote và nobind như các vai trò riêng biệt giải thích phần lớn lỗi bind.
Máy khách từ chối khởi động và phàn nàn rằng nó không thể bind một địa chỉ cục bộ, và cách sửa hiển nhiên có vẻ là trỏ nó vào địa chỉ đường hầm mà nó mong nhận được. Điều đó không thể hoạt động, và lý do đáng để hiểu: trước khi đường hầm tồn tại thì không có địa chỉ bên trong, và socket liên hệ với máy chủ phải tồn tại trước. Có hai địa chỉ khác nhau liên quan, và chỉ một trong số chúng có thể được chọn cục bộ.
Lỗi bind nêu tên một địa chỉ cục bộ
Khi OpenVPN báo rằng nó không thể bind một địa chỉ cục bộ, nó đang nói về socket vận chuyển: điểm cuối UDP hoặc TCP mang kết nối được mã hóa tới peer.
Một chỉ thị local rõ ràng yêu cầu daemon bind socket đó vào một địa chỉ cục bộ cụ thể. Địa chỉ phải tồn tại trong không gian tên mạng nơi tiến trình chạy, và phải có thể gán được vào thời điểm máy khách khởi động.
Một địa chỉ công cộng được dịch ở router hoặc ở rìa đám mây không phải là địa chỉ cục bộ mà daemon có thể bind, dù đó là địa chỉ mà máy chủ nhìn thấy. Sự khác biệt này giải thích vì sao một hồ sơ hoạt động ở nhà và thất bại trên một phiên bản đám mây. Nó cũng giải thích vì sao thêm địa chỉ công cộng vào giao diện loopback không giúp ích, vì khi đó vận chuyển sẽ lấy nguồn từ một địa chỉ mà mạng không thể định tuyến trả lại. Hãy đọc danh sách giao diện trước khi sửa hồ sơ.
local và remote thực sự chọn gì
remote nêu tên peer cần liên hệ. local bind đầu gần của cùng socket đó. nobind để hệ điều hành chọn cả địa chỉ cục bộ và cổng, đó là lý do các máy khách sau router gia đình thường hoạt động mà không cần chỉ thị nào trong hai chỉ thị này.
Không chỉ thị nào trong hai chỉ thị này liên quan đến địa chỉ bên trong đường hầm.
Trong container hoặc không gian tên mạng, cùng quy tắc áp dụng với ranh giới hẹp hơn: địa chỉ của máy chủ không hiện diện bên trong, nên một dòng local sao chép từ cấu hình máy chủ thất bại vì lý do hoàn toàn khác với một địa chỉ sai.
ip -brief address show
ip route get 203.0.113.10Địa chỉ bên trong đến từ máy chủ
Địa chỉ bên trong đường hầm được thương lượng hoặc gán sau khi kênh điều khiển được thiết lập. Với một pool động, máy chủ quyết định nó tại thời điểm kết nối, và với cấu hình riêng cho từng máy khách, nó có thể cố định theo từng danh tính.
Viết local với một địa chỉ bên trong không yêu cầu máy chủ cấp địa chỉ đó. Trong trường hợp tốt nhất bind thất bại; trong trường hợp xấu nhất máy khách tìm thấy một địa chỉ máy chủ không liên quan có cùng giá trị và bắt đầu dùng nó cho vận chuyển.
Các giao diện cần đọc cũng khác. Tham số ifconfig và cấu hình pool mô tả bên trong, trong khi remote, local, proto và nobind mô tả bên ngoài. Giữ hai danh sách này tách biệt giải thích gần như mọi ví dụ gây nhầm lẫn bạn tìm thấy trên diễn đàn. Đó là lý do hướng dẫn OpenVPN 2.6 ghi chúng trong các phần riêng.
Cái bẫy: một đường hầm đầy đủ bắt lấy chính vận chuyển của nó
Khi đường hầm đã lên và mang tuyến mặc định, các gói duy trì nó không được định tuyến vào trong nó. Đây là vấn đề định tuyến chứ không phải đánh địa chỉ, và daemon xử lý bằng cách cài một tuyến cụ thể hơn tới địa chỉ của chính máy chủ qua gateway ban đầu.
Nếu bạn ghim vận chuyển vào một địa chỉ cục bộ cụ thể và sau đó thay đổi đường đi mà địa chỉ đó dùng, kết nối bên ngoài có thể lạc đường trong khi bên trong vẫn được cấu hình. Đường hầm tiếp tục báo đã kết nối vì bên trong vẫn ổn. Chỉ vận chuyển bị hỏng, đó là lý do nhật ký đọc như mâu thuẫn.
Triệu chứng khi đó giống một đường hầm kết nối rồi đóng băng, hoặc một đường hầm kết nối lại trong vòng lặp mà không có lỗi hữu ích. Kiểm tra tuyến tới địa chỉ của peer trước khi kiểm tra bất cứ thứ gì bên trong đường hầm, và xác nhận rằng địa chỉ cục bộ bạn đã bind vẫn thuộc giao diện mà bạn mong đợi.
Một thói quen ngăn sự nhầm lẫn
Đọc mọi địa chỉ trong một hồ sơ và quyết định nó thuộc lớp nào trước khi sửa nó.
Nếu nó nêu tên đầu xa của vận chuyển hoặc bind đầu gần của nó, thì đó là địa chỉ bên ngoài và phải tồn tại trước khi khởi động. Nếu nó mô tả những gì xảy ra bên trong đường hầm, nó đến từ máy chủ hoặc từ cấu trúc liên kết, và không chỉ thị cục bộ nào có thể thay thế nó.
Viết hai danh sách vào ghi chú triển khai bên cạnh hồ sơ. Phiên khắc phục sự cố tiếp theo sẽ bắt đầu từ lớp chứ không phải từ phỏng đoán.