호스트는 IPsec 피어에 닿지만 Docker 컨테이너는 닿지 않는다

Linux 머신에서 원격 호스트로 ping을 보내면 응답이 오니 터널은 동작한다. 옆의 컨테이너는 여전히 시간 초과가 나고, 다음에 할 자연스러운 일은 Docker 재시작이다. 브리지 네트워크의 컨테이너는 보통 다른 출발지 주소로 시작하고, 호스트 애플리케이션 자신의 출구 경로가 아니라 포워딩으로 호스트에 들어오기 때문에 성공한 시험이 측정한 것은 다른 패킷이다. 정책 기반 strongSwan 터널에서는 포워딩된 패킷이 설치된 IPsec 정책과 맞지 않을 때 원격 서브넷으로 가는 평범한 경로로는 충분하지 않다.

아래 절차는 목적지 하나와 출발지 둘을 따라가며, 먼저 상태를 읽고 그다음에 손을 댄다.

목적지 하나와 출발지 둘에서 시작한다

먼저 IP로 알 수 있는 서비스를 고른다. DNS 문제를 동시에 다루지 않기 위해서다. 세 가지 사실, 곧 컨테이너의 브리지 프리픽스, 성공한 호스트 요청의 출발지 주소, 터널에서 협상된 로컬 및 원격 트래픽 셀렉터를 적는다.

다음으로 실패한 요청을 컨테이너 안에서 다시 보내고, 실제로 쓰이는 출발지를 잡는다. 그 주소가 로컬 셀렉터에 포함되지 않는다면 결과는 이미 정해져 있고, 컨테이너를 다시 만들어도 달라지지 않는다.

Docker를 건드리기 전에 정책을 읽는다

읽기 전용 호스트 점검은 라우팅 결정, 정책 데이터베이스, 그리고 둘 사이에서 선택하는 규칙을 다룬다.

ip rule show
ip route show table all
ip xfrm policy

정책 목록은 셀렉터와 방향을 보여 주며, 키 자료로 가득한 IPsec 상태 덤프가 필요 없으므로 티켓에 붙여도 안전하다. 호스트 주소는 덮지만 브리지 프리픽스는 덮지 않는 로컬 셀렉터를 찾고, 겹침도 확인한다. 원격 목적지를 로컬로 취급하는 컨테이너 경로는 기대하는 포워딩 패킷을 결코 만들지 못하고, 터널이 누명을 쓴다. 이 목록을 컨테이너의 출발지 주소 옆에 남겨 두어야 둘이 함께 온전한 비교가 된다.

컨테이너 프리픽스가 없다면 다른 것을 고치기 전에 멈추고 아키텍처를 정한다. 나머지 절차는 어느 출발지 주소가 회선에 나타나야 하는지 합의했다고 가정한다.

필터링과 변환을 차례로 확인한다

Docker의 Linux 브리지 방화벽은 IPsec과 무관하게 포워딩을 막을 수 있다. iptables 백엔드라면 FORWARD 체인과 DOCKER-USER 판정을 보되, 앞선 결론이 있으면 뒤에 추가한 규칙이 아예 실행되지 않을 수 있음을 기억한다. nftables 백엔드는 통합 방식이 다르므로 iptables 예제가 그렇게 이름 붙였다는 이유만으로 DOCKER-USER 체인을 만들지 말고, 데몬이 실제로 어느 백엔드를 쓰는지 확인한다.

다음으로 출발지 변환을 확인한다. 넓은 MASQUERADE 규칙은 이전에 IPsec 셀렉터와 맞던 패킷을 더 이상 맞지 않는 패킷으로 바꿀 수 있고, 장애는 라우팅 문제와 똑같이 보인다. strongSwan 포워딩 안내서 는 이미 정책에 맞는 트래픽에 대해 그런 변환 전에 필요한 NAT 예외를 문서화한다.

그 예외는 덮이지 않은 컨테이너 출발지를 터널에 더하는 수단이 아니다. 설계에 이미 들어맞는 트래픽만 보호하므로, 셀렉터와 되돌아오는 경로의 문제를 먼저 정리하고 그다음 NAT와 필터링을 답에 맞춘다. 예외를 넓히기 시작했다면 바꿔야 할 것은 셀렉터이지 NAT 규칙이 아니다.

그다음 경로로 보낼지 변환할지 정한다

경로로 보내는 컨테이너 서브넷은 양쪽 피어가 그 서브넷을 받아들이고 원격 쪽에 그것으로 돌아오는 경로가 있어야 하므로, 보통 양 끝의 셀렉터 변경과 먼 쪽 소유자와의 대화를 뜻한다. 의도적으로 변환하는 설계라면 대신 관련 조회 단계에서 정책이 덮는 주소를 제시해야 하며, 보통 기본 MASQUERADE가 아니라 좁고 문서화된 규칙을 뜻한다.

두 배치 모두 호스트의 동작하는 터널에서 자동으로 나오지 않으므로, 둘 중 무엇을 고를지는 소유자가 있는 설계 결정이다. 고른 쪽을 적어 두지 않으면 다음 엔지니어가 방화벽 카운터에서 다시 도출한다.

규칙 집합의 절반만 변환된 혼합 장애에서는 성공이 목적지 포트에 좌우되고 네트워크의 어떤 성질과도 무관하게 간헐적으로 나타나므로 그것도 살핀다.

새 연결로 검증하고 재시작으로 검증하지 않는다

새 애플리케이션 연결을 쓰면서 범위가 좁은 방화벽 카운터와 원격 수신 측을 함께 보면 관찰마다 출처가 생긴다. Docker 재시작은 규칙 상태를 바꿀 수 있고 워크로드도 흔들어서, 얻으려던 깨끗한 신호를 스스로 버리는 셈이 된다.

오래 남는 결과는 보여 줄 수 있는 네 문장이다. 컨테이너 출발지, 일치하는 보호 경로, 허용된 포워딩, 그리고 돌아오는 응답이 모두 성립하면 컨테이너는 호스트와 같은 이유로 피어에 닿는다.