Tại sao ánh xạ cổng VPN Docker của bạn không bao giờ đến được OpenVPN

Container của bạn có thể lắng nghe trên UDP 1195 trong khi máy chủ công bố 1194, và điều đó đúng miễn là ánh xạ nói như vậy. Các con số tạo thành một bảng dịch: máy khách gọi cổng máy chủ, Docker ghi lại đích đến cổng container, và OpenVPN trả lời trên cổng mà cấu hình của nó chỉ định. Một sự không khớp ở bất kỳ mắt xích nào tạo ra lỗi âm thầm trông giống tường lửa. Chứng chỉ và mật mã nằm ở phía sau và không thể sửa được điều đó.

Theo dõi một gói tin từ máy khách đến tiến trình trước khi thay đổi bất cứ điều gì về xác thực.

Ba con số, một kết nối

Ba con số là đích từ xa mà máy khách sử dụng, ánh xạ được công bố trên máy chủ và trình lắng nghe bên trong container. Chúng không cần bằng nhau, nhưng phải tạo thành một chuỗi. Con số bằng nhau là trường hợp đặc biệt tình cờ phổ biến nhất, vì vậy sự không khớp dễ viết một lần và khó thấy về sau.

Viết chuỗi thành một dòng trước khi gỡ lỗi: địa chỉ và cổng của máy khách, ánh xạ máy chủ, trình lắng nghe container, phương thức vận chuyển. Khiếm khuyết trong chuỗi hiện ra như một con số xuất hiện hai lần với giá trị khác nhau.

Cú pháp ngắn thực sự nói gì

Trong dạng ngắn, bên trái là cổng máy chủ và bên phải là cổng container, và hậu tố gạch chéo chọn phương thức vận chuyển. Nếu bỏ hậu tố, Docker coi ánh xạ là TCP, nên một trình lắng nghe UDP sau ánh xạ không có giao thức là trình lắng nghe không ai chạm tới. Giá trị mặc định đó đã được ghi lại và vẫn khiến những người đã khớp các con số và cho là xong phải ngạc nhiên.

Dạng dài chỉ định rõ địa chỉ liên kết và giao thức, điều đáng giá thêm vài dòng cho mọi thứ hướng ra mạng. Đọc lại ánh xạ đã công bố thay vì tin vào tệp đã tạo ra nó.

ports:
  - 1194:1195/udp

Gói tin có thể dừng ở đâu

Một yêu cầu có thể bị bỏ trước Docker, trong Docker hoặc tại trình lắng nghe. Phía trước Docker có thể có tường lửa đám mây hoặc bộ định tuyến tự chuyển tiếp, và thiết bị đó cần cổng hướng về máy chủ và phương thức vận chuyển đúng. Bên trong Docker, ánh xạ tới cổng container sai sẽ chuyển tới một socket đã đóng.

Tiếp theo là trình lắng nghe: cấu hình OpenVPN chỉ định một cổng và giao thức, và máy khách đến cổng khác bên trong container không chạm tới gì cả. Kiểm thử dịch vụ UDP bằng TCP không chứng minh được gì ở bất kỳ giai đoạn nào, vì vậy hãy dùng phương thức vận chuyển mà máy khách sẽ dùng.

Địa chỉ liên kết quyết định khả năng tiếp cận

Ánh xạ đã công bố gắn với loopback chỉ tiếp cận được từ máy chủ, trong khi ánh xạ gắn với mọi giao diện tiếp cận được ở bất cứ đâu tường lửa cho phép. Hai cái trông giống hệt nhau trong tệp Compose bỏ qua địa chỉ, và giá trị mặc định của Docker là cái rộng.

Quyết định việc triển khai muốn phơi bày kiểu nào, rồi viết rõ ra. Một bài kiểm thử nội bộ kết nối qua loopback và một máy khách từ xa không thể kết nối đều có thể là mô tả chính xác của cùng một container.

Đọc trạng thái đang chạy

Kiểm tra ánh xạ thực tế của container đang chạy và trình lắng nghe trong không gian tên mạng của nó. Tệp Compose có thể đã bị sửa sau khi container khởi động, siêu dữ liệu image có thể khai báo một cổng mà không công bố, và container thứ hai có thể đã giữ cổng máy chủ. Khai báo một cổng trong image không phải là công bố nó, và không cái nào trong hai điều đó giống với việc lắng nghe.

Ba trạng thái khác nhau, ba lệnh khác nhau, và chỉ lệnh cuối liên quan đến OpenVPN.

Khi ánh xạ đã đúng

Khi gói tin đến OpenVPN, nhật ký của nó là nơi đọc về TLS và xác thực. Tạo lại chứng chỉ để sửa một gói tin chưa bao giờ đến là công việc lãng phí và thêm một biến thứ hai. Giữ ghi chú ánh xạ bên cạnh hồ sơ máy khách để người tiếp theo đọc một dòng thay vì khám phá lại cả ba con số. Một lần bắt gói tin ở phía máy chủ quyết định mắt xích nào trong ba mắt xích là sai, và tốn ít hơn một lần tạo lại chứng chỉ.

Trường hợp được mô tả ở đây là công bố qua cầu. Mạng máy chủ và địa chỉ container được định tuyến bỏ qua bước dịch, nên những con số giống nhau mang nghĩa khác trong các thiết kế đó.