Máy chủ đến được peer IPsec, container Docker thì không

Bạn ping máy chủ từ xa từ máy Linux và nó trả lời, vậy đường hầm hoạt động. Container bên cạnh vẫn hết thời gian chờ, và bước tiếp theo tự nhiên là khởi động lại Docker. Container trên mạng cầu thường bắt đầu bằng một địa chỉ nguồn khác và đi vào máy chủ qua chuyển tiếp chứ không qua đường ra riêng của ứng dụng trên máy chủ, nên bài kiểm tra thành công đã đo một gói tin khác. Với đường hầm strongSwan dựa trên chính sách, một tuyến thông thường tới subnet từ xa là không đủ khi gói tin được chuyển tiếp không khớp với chính sách IPsec đã cài.

Hướng dẫn dưới đây theo một đích qua hai nguồn, đọc trạng thái trước khi thay đổi bất cứ điều gì.

Bắt đầu với một đích và hai nguồn

Trước hết chọn một dịch vụ đã biết theo IP, để không gỡ lỗi DNS cùng lúc. Ghi lại ba dữ kiện: tiền tố cầu của container, địa chỉ nguồn của yêu cầu từ máy chủ đã thành công, và các selector lưu lượng cục bộ và từ xa đã thương lượng cho đường hầm. Ba con số đó giải thích gần như mọi trường hợp của triệu chứng này.

Sau đó lặp lại yêu cầu thất bại từ bên trong container và bắt lấy nguồn mà nó thực sự dùng. Nếu địa chỉ đó không được selector cục bộ bao phủ, bạn đã biết kết quả, và không việc tạo lại container nào thay đổi được.

Đọc chính sách trước khi chạm vào Docker

Các kiểm tra máy chủ chỉ đọc bao gồm các quyết định định tuyến, cơ sở dữ liệu chính sách và các quy tắc chọn giữa chúng:

ip rule show
ip route show table all
ip xfrm policy

Danh sách chính sách hiển thị selector và hướng mà không cần bản kết xuất trạng thái IPsec đầy vật liệu khóa, vì thế dán nó vào ticket là an toàn. Tìm selector cục bộ bao phủ địa chỉ máy chủ nhưng không bao phủ tiền tố cầu. Cũng kiểm tra chồng lấn: một tuyến container coi đích từ xa là cục bộ sẽ không bao giờ tạo ra gói tin chuyển tiếp mà bạn mong đợi, và đường hầm bị đổ lỗi. Lưu danh sách đó bên cạnh địa chỉ nguồn của container, vì hai thứ đó cùng nhau là toàn bộ phép so sánh.

Nếu thiếu tiền tố container, hãy dừng lại và quyết định kiến trúc trước khi sửa bất cứ điều gì khác. Phần còn lại của hướng dẫn giả định bạn đã thống nhất địa chỉ nguồn nào sẽ xuất hiện trên mạng.

Kiểm tra lọc và dịch theo thứ tự

Tường lửa cầu Linux của Docker có thể chặn chuyển tiếp độc lập với IPsec. Với backend iptables, hãy xem đường FORWARD và các quyết định DOCKER-USER, nhớ rằng một quy tắc được thêm sau phán quyết trước đó có thể không bao giờ chạy. Backend nftables tích hợp khác đi, nên đừng tạo chuỗi DOCKER-USER chỉ vì một ví dụ iptables đặt tên như vậy; hãy kiểm tra daemon của bạn thực sự dùng backend nào.

Sau đó kiểm tra dịch nguồn. Một quy tắc MASQUERADE rộng có thể biến một gói tin trước đây khớp selector IPsec thành gói không còn khớp, và sự cố trông giống hệt một vấn đề định tuyến. hướng dẫn chuyển tiếp của strongSwan ghi lại ngoại lệ NAT cần thiết trước kiểu dịch đó cho lưu lượng đã khớp chính sách.

Ngoại lệ đó không phải cách thêm một nguồn container chưa được bao phủ vào đường hầm. Nó chỉ bảo vệ lưu lượng đã phù hợp với thiết kế, nên hãy giải quyết trước các câu hỏi về selector và đường trở về, rồi làm NAT và lọc khớp với câu trả lời. Nếu bạn thấy mình mở rộng ngoại lệ, thứ cần đổi là selector chứ không phải quy tắc NAT.

Sau đó quyết định định tuyến hay dịch

Một subnet container được định tuyến đòi hỏi cả hai peer chấp nhận subnet đó và có đường trở về từ xa tới nó, thường có nghĩa là thay đổi selector ở cả hai đầu và trao đổi với chủ sở hữu phía xa. Một thiết kế cố ý dịch thì phải trình bày một địa chỉ được chính sách bao phủ ở giai đoạn tra cứu liên quan, thường có nghĩa là một quy tắc hẹp và được ghi lại thay vì MASQUERADE mặc định.

Không bố trí nào trong hai cách tự động suy ra từ đường hầm đang chạy của máy chủ, và chọn giữa chúng là một quyết định thiết kế có người sở hữu. Hãy ghi lại bạn đã chọn cách nào, nếu không kỹ sư tiếp theo sẽ suy ra lại từ các bộ đếm tường lửa.

Cũng chú ý lỗi lai: một nửa bộ quy tắc được dịch và một nửa không, tạo ra thành công chập chờn phụ thuộc vào cổng đích chứ không phụ thuộc vào điều gì trên mạng.

Xác minh bằng một kết nối mới, không phải khởi động lại

Dùng một kết nối ứng dụng mới trong khi quan sát các bộ đếm tường lửa hẹp và bộ nhận từ xa, để mỗi quan sát có một nguồn. Khởi động lại Docker có thể thay đổi trạng thái quy tắc và cũng sẽ làm gián đoạn khối lượng công việc, khiến bạn mất tín hiệu sạch mà bạn muốn có.

Kết quả bền vững là bốn phát biểu bạn có thể trình bày: nguồn của container, đường được bảo vệ khớp, chuyển tiếp được phép, và một phản hồi quay về. Khi cả bốn đúng, container đến được peer vì lý do giống như máy chủ.