SeolOps

인프라를 운영하다 보면 예상하지 못한 곳에서 문제가 발생하는 경우가 있습니다.

최근 한 Linux 서버에서 단순한 서버 재부팅 이후 예상치 못한 네트워크 문제가 발생했습니다. 처음에는 단순한 접속 문제처럼 보였지만, 실제 원인은 Docker 네트워크와 사내 네트워크의 서브넷 충돌이었습니다.

이 글에서는 해당 문제를 해결하기까지의 트러블슈팅 과정을 단계별로 정리해보겠습니다.

문제 상황

Docker 컨테이너가 여러 개 실행되고 있는 Linux 서버가 있었습니다. 서버 재부팅 이후 다음과 같은 문제가 발생했습니다.

일부 내부 서버에서는 정상 접속 가능
특정 네트워크 구간에서는 SSH 접속 실패
Ping 요청 타임아웃 발생
기존에 접근 가능하던 서비스들이 일부 네트워크에서 접근 불가

특이한 점은 모든 환경에서 문제가 발생한 것이 아니라 특정 네트워크 구간에서만 문제가 발생했다는 점이었습니다.

1차 확인

네트워크 문제를 확인할 때는 기본적인 부분부터 점검합니다.

서버 IP 확인

ip addr

서버의 내부 IP는 정상적으로 설정되어 있었습니다.

SSH 서비스 확인

ss -ntlp | grep 22

SSH 서비스도 정상적으로 실행 중이었고 22번 포트를 리슨하고 있었습니다.

Docker 컨테이너 확인

docker ps

실행 중인 컨테이너들도 모두 정상 상태였습니다.

이 시점까지는 특별한 문제가 보이지 않았습니다.

라우팅 테이블 확인

다음으로 확인한 것은 서버의 라우팅 테이블이었습니다.

ip route

여기서 하나의 의심스러운 항목이 눈에 띄었습니다.

192.168.x.x/20 dev br-xxxxxxxx proto kernel scope link src 192.168.x.x

이 라우트는 Docker bridge 네트워크에서 생성된 것이었습니다.

Docker는 컨테이너 네트워크를 위해 자동으로 bridge 네트워크를 생성하며, 각각 고유한 서브넷과 게이트웨이를 가집니다. 일반적으로는 문제가 없지만 사내 네트워크와 서브넷이 겹칠 경우 문제가 발생할 수 있습니다.

traceroute로 경로 확인

패킷이 실제로 어디로 전달되는지 확인하기 위해 다음 명령어를 실행했습니다.

traceroute <internal-gateway>

예상했던 정상 결과는 다음과 같아야 합니다.

1  <corporate-gateway>

하지만 실제 결과는 다음과 같았습니다.

1  192.168.x.x

이 IP는 Docker bridge gateway였습니다.

즉, 서버가 목적지 네트워크를 사내 네트워크가 아니라 Docker 네트워크로 인식하고 있었던 것입니다.

문제의 원인

문제의 원인은 Docker 네트워크와 사내 네트워크의 서브넷 충돌이었습니다.

Docker가 자동 생성한 bridge 네트워크가 다음과 같은 서브넷을 사용하고 있었습니다.

192.168.x.x/20

문제는 이 범위가 사내 네트워크 대역과 겹쳐 있었던 것입니다.

Linux의 라우팅 테이블에서는 목적지와 일치하는 서브넷이 있을 경우 해당 경로를 우선 사용합니다. 그 결과:

사내 네트워크로 가야 할 패킷이
Docker bridge 네트워크로 전달되고
결국 목적지에 도달하지 못하는 상황이 발생했습니다.

왜 재부팅 이후 문제가 발생했을까

재부팅 이전에는 우연히 정상적으로 동작하고 있었습니다. 하지만 서버 재부팅 이후:

Docker 네트워크가 다시 생성되고
라우팅 테이블이 재구성되면서
충돌하는 서브넷 경로가 다시 등록되었습니다.

그 결과 잘못된 라우팅이 발생하게 되었습니다.

해결 방법

이 문제를 해결하는 방법은 크게 두 가지가 있습니다.

방법 1 — 충돌하는 Docker 네트워크 삭제

만약 해당 네트워크가 중요하지 않다면 다음 명령어로 삭제할 수 있습니다.

docker network rm <network-name>

이렇게 하면 라우팅 테이블에서도 해당 경로가 제거됩니다.

방법 2 — Docker 네트워크 서브넷 변경 (권장)

더 좋은 방법은 Docker 네트워크를 사내 네트워크와 겹치지 않는 서브넷으로 설정하는 것입니다.

networks:
  app-network:
    driver: bridge
    ipam:
      config:
        - subnet: 172.30.0.0/16

Docker 네트워크에는 일반적으로 다음 대역을 사용하는 것이 안전합니다.

172.16.0.0 – 172.31.255.255

이 범위는 사내 네트워크와 충돌할 가능성이 낮습니다.

해결 확인

문제 해결 이후 다시 라우팅 테이블을 확인했습니다.

ip route

충돌하던 Docker 네트워크 경로가 사라졌습니다. 다시 traceroute를 실행하면 정상 경로가 확인됩니다.

traceroute <internal-gateway>

1  <corporate-gateway-ip>

이후 SSH 접속도 정상적으로 동작했습니다.

정리

이번 문제를 통해 중요한 점을 다시 한번 확인할 수 있었습니다.

Docker 네트워크는 기존 인프라 네트워크와 충돌할 수 있습니다. Docker 환경에서 네트워크 문제가 발생한다면 다음을 반드시 확인해야 합니다.

Docker bridge 네트워크
Linux 라우팅 테이블
서브넷 충돌 여부

특히 다음 명령어는 매우 유용합니다.

ip route

마무리

이번 트러블슈팅을 통해 다시 한번 느낀 점은 다음과 같습니다.

많은 네트워크 문제는 방화벽이나 서비스 문제가 아니라 라우팅 문제에서 시작된다.

컨테이너 환경은 강력하지만, 동시에 호스트 네트워크와 상호작용하는 또 하나의 네트워크 레이어를 추가합니다. Docker를 운영 환경에서 사용할 경우, 자동 생성 네트워크에만 의존하기보다는 명확하게 서브넷을 지정하는 것이 안정적인 운영에 도움이 됩니다.

Docker 네트워크가 사내 네트워크를 망가뜨렸던 날: 트러블슈팅 여정