Container Windows và VPN: vì sao mạng cục bộ bị đứt

Trên một laptop, với một ứng dụng khách VPN được kết nối, các container Linux vẫn nói chuyện với nhau còn container Windows thì dừng lại. Biến số không phải là image mà là đường đi của các gói tin vào máy chủ. Container Windows trên mạng mặc định vay bảng định tuyến và bản dịch của máy chủ, nên một chính sách thay đổi định tuyến của máy chủ cũng thay đổi chúng. Hãy xác nhận điều đó bằng một lần tra tuyến trước khi cài lại bất cứ thứ gì.

Các gói tin của container Windows đi vào máy chủ ở đâu

Một container trên mạng mặc định nat nhận địa chỉ từ tiền tố của dịch vụ Host Networking Service, thường ở đâu đó trong 172.16.0.0/12, và đến được máy chủ qua một bộ điều hợp ảo. Máy chủ sở hữu tuyến cho tiền tố đó và dịch lưu lượng về phía bộ điều hợp đang hoạt động. Không có máy ảo riêng ở giữa đường đi đó.

Chính thiết kế này khiến sự cố mang tính cơ học. Khi container gửi một gói tin, máy chủ thực hiện tra tuyến cho tiền tố của container. Tuyến nào thắng thì gói tin đi đến đó, và container không có ý kiến gì về việc này.

Ứng dụng khách VPN thay đổi gì trên đường đi đó

Ứng dụng khách doanh nghiệp thường cài một tập tuyến rộng và một bộ lọc từ chối truy cập subnet cục bộ khi đường hầm đang hoạt động. Ý định là phòng vệ: một mạng cục bộ bị xâm phạm không nên chạm tới máy được bảo vệ. Tác dụng phụ là tuyến của máy chủ tới tiền tố container không còn là mạng NAT cục bộ nữa.

Thay vào đó, lần tra tuyến khớp với đường hầm và gói tin được giao cho cổng, nơi chưa từng nghe nói tới địa chỉ container đó. Ping thất bại, ứng dụng hết thời gian chờ và container trông như hỏng trong khi biểu tượng VPN vẫn sáng. Hãy xem bảng của máy chủ khi đang kết nối và tuyến cạnh tranh sẽ hiện ra.

Vì sao container Linux hành xử khác

Bộ máy Linux chạy container bên trong một máy ảo nhẹ, và các kết nối ra ngoài từ máy đó được một proxy phía máy chủ mở thay cho container. Máy chủ khởi tạo socket, nên quy tắc của VPN về tiền tố container không áp dụng cho nó theo cùng cách, và khối lượng công việc vẫn tiếp cận được mạng.

Sự khác biệt đó cũng giải thích vì sao các công thức Linux không chuyển sang được. Container Linux cần đường hầm riêng được cấp một thiết bị TUN cùng khả năng NET_ADMIN. Container Windows không đưa ra giao diện nào như một thiết bị, nên mẫu đó không có tương đương ở phía bên kia.

Chứng minh tuyến, rồi chọn thiết kế

Thu thập bằng chứng từ máy chủ, không phải từ container, vì máy chủ là bên thực hiện tra tuyến:

docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"

Chạy kết quả tuyến một lần trước khi VPN kết nối và một lần sau đó. Nếu ở kết quả thứ hai tiền tố container trỏ tới bộ điều hợp đường hầm, chẩn đoán đã hoàn tất và việc khởi động lại container sẽ không giúp gì.

Lựa chọn đầu tiên là một quyết định chính sách: hỏi chủ sở hữu mạng xem có thể cho phép truy cập LAN cục bộ cho thiết bị này hay không. Một số ứng dụng khách doanh nghiệp cung cấp điều đó như một cài đặt, nhưng nó làm yếu đi một ranh giới có chủ đích. Hãy yêu cầu nó như một ngoại lệ có ghi chép kèm người phụ trách và ngày xem xét. Một nút gạt cho từng thiết bị mà không ai quay lại kiểm tra chính là cách một chính sách phòng vệ lặng lẽ biến mất.

Ở nơi chính sách phải giữ vững, hãy di chuyển khối lượng công việc thay vì đánh nhau với tuyến. Một mạng trong suốt với subnet và cổng rõ ràng đặt container trên liên kết cục bộ, khối lượng công việc Linux chạy sau proxy của máy ảo, và một máy ảo riêng với ứng dụng khách của riêng nó giữ chính sách của chính nó. Hãy chọn một cách có chủ đích và kiểm thử nó từ bên trong container, vì yêu cầu của người dùng phát sinh chính ở đó.