Chia sẻ mạng của một container VPN: điều gì xảy ra với DNS

Chia sẻ không gian tên mạng của một container VPN cung cấp cho ứng dụng của bạn các giao diện và tuyến đường của đường hầm. Nó không cung cấp cho ứng dụng trình phân giải của đường hầm, cũng không cung cấp bản sao hợp nhất của bất cứ thứ gì khác trên máy chủ. Khoảng trống đó tạo ra một sự cố rất cụ thể: tên công khai phân giải được, tên nội bộ thì không, và ứng dụng thất bại trông như đang dùng sai máy chủ DNS, vì đúng là như vậy. Việc sửa thường nhỏ hơn chẩn đoán gợi ý.

Bước 1: Kiểm tra từ ứng dụng, không phải từ máy chủ

Chạy tra cứu bên trong container gặp sự cố, không phải trên máy chủ và không phải trong trình duyệt. docker exec app-container getent hosts db.internal trả lời câu hỏi duy nhất quan trọng: trình phân giải của tiến trình này trả về gì.

Nếu máy chủ phân giải được tên mà container không, bạn đã tìm ra lỗi. Mọi thứ sau đó là chọn một cách được hỗ trợ để sửa nó.

Bước 2: Đọc mô hình được runtime hỗ trợ

Tài liệu mạng của Docker ghi lại các hạn chế đối với cờ DNS cho container dùng chung chế độ mạng của container khác. Trong Compose network_mode: service:vpn gắn ứng dụng với không gian tên của container VPN, và với mỗi dịch vụ dns các cài đặt không hoạt động như với một dịch vụ thông thường. Phân giải bạn nhận được là phân giải mà không gian tên dùng chung có.

Các mạng cầu do người dùng định nghĩa cũng dùng DNS nhúng của Docker khác với cầu mặc định. Đó là lý do một dns điều khoản sao chép từ ví dụ cầu đang hoạt động có thể không làm gì cả trong một chồng dùng chung. Kiểm tra cách bố trí trước khi sao chép điều khoản.

Địa chỉ loopback luôn tham chiếu đến ngữ cảnh mạng liên quan. Bên trong không gian tên dùng chung, 127.0.0.1 không phải là trình phân giải của máy chủ.

Bước 3: Theo dõi truy vấn đến người nhận

Đọc cấu hình trình phân giải của ứng dụng, sau đó là bất kỳ DNS mã hóa riêng cho ứng dụng mà nó mang theo, vì ứng dụng chạy trình phân giải riêng sẽ bỏ qua tệp bạn đã sửa. Sau đó kiểm tra xem trình phân giải được chọn có thể truy cập dưới các tuyến và chính sách tường lửa của VPN hay không. Địa chỉ trình phân giải ở phía bên kia đường hầm là vô dụng nếu không gian tên không có tuyến đến đó. Xác nhận người nhận trước khi sửa bất kỳ tệp nào.

Trang kiểm tra IP trong trình duyệt không thể cho bạn biết các truy vấn tên đã đi đâu. Nó cho biết một kết nối HTTP đã đi đâu.

Bước 4: Sửa hai lớp sự cố theo cách khác nhau

Nếu tên dịch vụ thất bại trong khi tên công khai hoạt động, vấn đề là phát hiện dịch vụ bên trong mạng container, không phải danh sách trình phân giải công khai. Việc thay đổi mọi địa chỉ DNS công khai sẽ không tạo ra các bản ghi mà cơ chế phát hiện của mạng chưa bao giờ được yêu cầu tạo.

Nếu cả hai lớp đều thất bại, hãy bắt đầu với khả năng tiếp cận trình phân giải. Nếu chỉ một lớp thất bại, hãy bắt đầu với cơ chế phát hiện. Hai bên có chủ sở hữu khác nhau, vì vậy một lần sửa không bao giờ bao trùm cả hai.

Bước 5: Kiểm tra lại sau khi tạo lại

Thay đổi cấu hình thông qua cơ chế được runtime hỗ trợ, sau đó tạo lại các container thay vì sửa tệp bên trong một container đang chạy. Kiểm tra một tên riêng mới, một tên công khai mới và yêu cầu ứng dụng theo sau tra cứu. Một chỉnh sửa trong /etc/resolv.conf bên trong container biến mất khi tạo lại và sẽ khiến bạn tin rằng việc sửa đã hoạt động khi nó không hoạt động.

Ghi lại chủ sở hữu trình phân giải và không gian tên dự kiến bên cạnh định nghĩa mạng dùng chung. Người tiếp theo sẽ cần cả hai.