-
1. 문제 상황: Docker 실행 후 네트워크 연결이 끊김
-
2. 원인 분석: Docker 네트워크(docker0)와 기존 네트워크 충돌
-
3. 라우팅 테이블을 통한 패킷 흐름 분석 (서버 1 → 서버 2)
-
1️⃣ 서버 1 (172.17.1.10)에서 서버 2 (172.16.1.10)로 패킷을 보내는 과정
-
2️⃣ 서버 2 (172.16.1.10)에서 패킷을 받고 서버1로 응답을 보낼 때
-
4. 해결 방법: Docker의 기본 네트워크(docker0)를 변경하기
-
방법 1 - /etc/docker/daemon.json 수정하여 기본 네트워크 변경
-
방법 2 - 컨테이너 실행 시 별도 네트워크 지정
-
5. 핵심 정리
Docker를 사용하던 중, 서버의 호스트 네트워크와 Docker의 기본 브릿지 네트워크(docker0)가 충돌하면서 컨테이너의 네트워크 연결이 끊기는 문제가 발생했다. 일반적으로 Docker는 자동으로 네트워크를 설정하지만, 특정 환경에서는 기존 네트워크와 겹쳐서 예상치 못한 네트워크 장애가 발생할 수 있다.
오류가 발생한김에 Docker 네트워크 충돌 문제의 원인과 해결 방법을 네트워크 개념과 함께 쉽게 정리해보겠다.
1. 문제 상황: Docker 실행 후 네트워크 연결이 끊김
💻 현재 환경
- 서버 1 (172.17.1.10)
- 서버 2 (172.16.1.10)
- 서버 2에서 Docker 실행중
🚨 현상
1️⃣ Docker 실행 전에는 서버1 (172.17.1.10) →서버2 (172.16.1.10)로 정상적으로 PING이 전송됨
2️⃣ 하지만 도커 컨테이너를 실행한 후, 서버1 (172.17.1.10) →서버2 (172.16.1.10)로 PING이 가지 않음 (네트워크 단절)
3️⃣ docker ps 확인 결과 컨테이너는 정상적으로 실행 중
📌 즉, Docker 컨테이너 실행 후 서버2(172.16.1.10)에 접근할 수 없는 문제 발생!
2. 원인 분석: Docker 네트워크(docker0)와 기존 네트워크 충돌
Docker는 기본적으로 Bridge 네트워크(docker0)를 생성하여 컨테이너를 실행한다.
이때, docker0 네트워크의 서브넷이 기존 네트워크와 충돌하면, 라우팅이 꼬이면서 네트워크 연결이 끊긴다.
📌 Docker가 자동으로 설정한 네트워크 확인
docker network inspect bridge
출력 예시:
{
"Name": "bridge",
"Driver": "bridge",
"IPAM": {
"Config": [
{
"Subnet": "172.17.0.0/16",
"Gateway": "172.17.0.1"
}
]
}
}
🚨 문제 발생!
- Docker가 기본적으로 172.17.0.0/16 대역을 docker0 네트워크로 설정함
- 그런데 서버1(172.17.1.10)이 이미 172.17.1.0/24를 사용 중
- 이 때문에 Docker가 만든 docker0 네트워크가 기존 네트워크와 충돌하여 경로가 꼬임 🚨
📌 서버 2의 라우팅 테이블 변경 확인 (ip route)
default via 192.168.1.1 dev ens192
172.16.1.0/24 dev ens192 proto kernel scope link src 172.16.1.10
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 ❌ (충돌 발생!)
🚨 기존 네트워크(172.17.1.0/24)와 docker0(172.17.0.0/16)가 중복되면서, 운영체제가 라우팅을 잘못 설정하는 문제 발생!
✅ 결과적으로, 패킷이 잘못된 네트워크(docker0)로 전송되면서 서버2에 도달하지 못하는 현상이 발생한다.
👇🏻 이해가 안간다면 아래 글 보고오기
네트워크 기초 완벽 정리: 패킷, 라우팅, 게이트웨이, 네트워크 인터페이스
네트워크를 다루다 보면 패킷, 라우팅, 게이트웨이, 네트워크 인터페이스 같은 개념이 자주 등장한다.이번 글에서는 네트워크가 어떻게 작동하는지 기초부터 쉽게 설명해보겠다. 1. 네트워크
haesummy.tistory.com
서브넷 마스크와 네트워크 대역 쉽게 이해하기
이번달에는 블로그 글 20개를 써서 수익창출이 되는 블로그를 만들것이다.그래서 오늘의 주제는 잘못알면 헷갈리는 서브넷 마스크와 네트워크 대역 이다. 1. 서브넷 마스크란?IP 주소는 보통 A.B
haesummy.tistory.com
3. 라우팅 테이블을 통한 패킷 흐름 분석 (서버 1 → 서버 2)
좀 더 자세히 서버 1 (172.17.1.10) 서버 2 (172.16.1.10, Docker 실행 중) 으로 패킷이 어떻게 전달되는지 라우팅 테이블을 단계별로 확인하면서 문제를 분석해보자.
1️⃣ 서버 1 (172.17.1.10)에서 서버 2 (172.16.1.10)로 패킷을 보내는 과정
🚀 서버 1에서 서버 2로 ping을 보낼 때
📌 서버 1의 라우팅 테이블 확인
default via 192.168.1.1 dev ens192
172.16.1.0/24 via 192.168.1.1 dev ens192 ✅ (서버 2로 가는 경로)
172.17.1.0/24 dev ens192 proto kernel scope link src 172.17.1.10
📌 패킷 흐름
- 서버1 (172.17.1.10)에서 172.16.1.10으로 패킷을 전송
- 라우팅 테이블에 172.16.1.0/24로 가는 경로가 있음 → 게이트웨이(192.168.1.1)를 통해 서버 2로 전달
- 서버2 (172.16.1.10)가 서버1의 패킷을 받음
✅ 서버 1에서는 문제가 없음! 서버2가 서버1의 패킷을 받는것도 문제가 없음!
2️⃣ 서버 2 (172.16.1.10)에서 패킷을 받고 서버1로 응답을 보낼 때
🚀 서버 2에서 라우팅 테이블 확인
default via 192.168.1.1 dev ens192
172.16.1.0/24 dev ens192 proto kernel scope link src 172.16.1.10
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 ❌ (문제 발생!)
📌 패킷 흐름 분석
- 서버 1에서 ping 172.16.1.10을 전송
- 서버 2가 패킷을 받지만, 받은 후 서버1에 응답하려고 라우팅 테이블에서 172.16.x.x을 찾아보니 172.17.0.0/16이 docker0로 설정됨
- 운영체제가 "172.17.x.x로 향하는 패킷은 docker0로 보내야 한다!"라고 판단
- 결과적으로 패킷이 docker0 네트워크 내부로 들어가 버리고, 서버 2에서 정상적으로 응답하지 못함
🚨 즉, 172.17.1.10을 찾지 못하고 패킷이 잘못된 경로로 가서 통신이 차단됨!
✅ 서버 2에서 Docker가 기본적으로 172.17.0.0/16을 사용하면서, 172.17.1.10이 올바르게 인식되지 않는 것이 문제! 🚨
4. 해결 방법: Docker의 기본 네트워크(docker0)를 변경하기
해결 방법은 Docker가 자동으로 생성한 docker0 네트워크의 서브넷을 기존 네트워크와 겹치지 않는 범위로 변경하는 것!
방법 1 - /etc/docker/daemon.json 수정하여 기본 네트워크 변경
1️⃣ Docker의 기본 네트워크를 변경 (없으면 새로 생성)
cat <<EOF > /etc/docker/daemon.json
{
"bip": "192.168.100.1/24"
}
EOF
✅ bip 설정을 통해 기본 브릿지 네트워크(docker0)의 서브넷을 기존 네트워크와 겹치지 않도록 변경
🚨 변경할 서브넷 추천
- 192.168.100.0/24
- 10.10.10.0/24
- 📌 이런식으로 기존 네트워크와 겹치지 않는 범위를 선택해야 한다.
2️⃣ Docker 서비스 재시작
systemctl restart docker
Docker를 재시작하면 새로운 docker0 네트워크가 적용됨
3️⃣ 변경된 네트워크 확인
docker network inspect bridge
Subnet: 192.168.100.0/24가 설정되었는지 확인!
4️⃣ 기존 컨테이너 재시작
docker ps -q | xargs docker restart
모든 컨테이너를 재시작하여 새 네트워크를 적용!
방법 2 - 컨테이너 실행 시 별도 네트워크 지정
1️⃣ 새로운 Docker 네트워크 생성
docker network create --subnet=192.168.100.0/24 my_custom_network
192.168.100.0/24 범위의 사용자 정의 네트워크 생성
2️⃣ 컨테이너 실행 시 네트워크 지정
docker run --net=my_custom_network --ip=192.168.100.100 -d 이미지
컨테이너가 192.168.100.100 IP를 사용하도록 설정
3️⃣ 네트워크 확인
docker network inspect my_custom_network
192.168.100.0/24 서브넷이 설정되었는지 확인!
5. 핵심 정리
- Docker 기본 네트워크(docker0)가 자동으로 172.17.0.0/16을 사용하면서 기존 네트워크와 충돌하는 문제 발생! 🚨
- Docker 실행 후 네트워크 경로가 꼬여, 기존 네트워크(172.17.1.0/24)와의 통신이 차단됨.
- 해결 방법
- /etc/docker/daemon.json에서 bip 설정을 변경하여 기본 네트워크를 다른 서브넷(192.168.100.0/24)으로 변경
- 새로운 Docker 네트워크를 생성(docker network create)하고 컨테이너 실행 시 네트워크를 지정
✅ 이제 Docker 실행 후에도 기존 네트워크 연결이 유지되면서, 서버2에 정상적으로 접근할 수 있다.
'🌀Full-Stack&Beyond' 카테고리의 다른 글
쿠버네티스 아키텍처 완벽 가이드: 컨테이너 오케스트레이션부터 배포 흐름까지 (0) | 2025.03.19 |
---|---|
도커 Nginx 환경에서 logrotate를 활용한 자동 로그 관리 방법 (0) | 2025.02.27 |
네트워크 기초 완벽 정리: 패킷, 라우팅, 게이트웨이, 네트워크 인터페이스 (0) | 2025.02.26 |
서브넷 마스크와 네트워크 대역 쉽게 이해하기 (0) | 2025.02.26 |
인터넷에 www.naver.com을 입력하면 무슨 일이 일어날까? 🌍 (0) | 2025.02.23 |
Docker를 사용하던 중, 서버의 호스트 네트워크와 Docker의 기본 브릿지 네트워크(docker0)가 충돌하면서 컨테이너의 네트워크 연결이 끊기는 문제가 발생했다. 일반적으로 Docker는 자동으로 네트워크를 설정하지만, 특정 환경에서는 기존 네트워크와 겹쳐서 예상치 못한 네트워크 장애가 발생할 수 있다.
오류가 발생한김에 Docker 네트워크 충돌 문제의 원인과 해결 방법을 네트워크 개념과 함께 쉽게 정리해보겠다.
1. 문제 상황: Docker 실행 후 네트워크 연결이 끊김
💻 현재 환경
- 서버 1 (172.17.1.10)
- 서버 2 (172.16.1.10)
- 서버 2에서 Docker 실행중
🚨 현상
1️⃣ Docker 실행 전에는 서버1 (172.17.1.10) →서버2 (172.16.1.10)로 정상적으로 PING이 전송됨
2️⃣ 하지만 도커 컨테이너를 실행한 후, 서버1 (172.17.1.10) →서버2 (172.16.1.10)로 PING이 가지 않음 (네트워크 단절)
3️⃣ docker ps 확인 결과 컨테이너는 정상적으로 실행 중
📌 즉, Docker 컨테이너 실행 후 서버2(172.16.1.10)에 접근할 수 없는 문제 발생!
2. 원인 분석: Docker 네트워크(docker0)와 기존 네트워크 충돌
Docker는 기본적으로 Bridge 네트워크(docker0)를 생성하여 컨테이너를 실행한다.
이때, docker0 네트워크의 서브넷이 기존 네트워크와 충돌하면, 라우팅이 꼬이면서 네트워크 연결이 끊긴다.
📌 Docker가 자동으로 설정한 네트워크 확인
docker network inspect bridge
출력 예시:
{
"Name": "bridge",
"Driver": "bridge",
"IPAM": {
"Config": [
{
"Subnet": "172.17.0.0/16",
"Gateway": "172.17.0.1"
}
]
}
}
🚨 문제 발생!
- Docker가 기본적으로 172.17.0.0/16 대역을 docker0 네트워크로 설정함
- 그런데 서버1(172.17.1.10)이 이미 172.17.1.0/24를 사용 중
- 이 때문에 Docker가 만든 docker0 네트워크가 기존 네트워크와 충돌하여 경로가 꼬임 🚨
📌 서버 2의 라우팅 테이블 변경 확인 (ip route)
default via 192.168.1.1 dev ens192
172.16.1.0/24 dev ens192 proto kernel scope link src 172.16.1.10
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 ❌ (충돌 발생!)
🚨 기존 네트워크(172.17.1.0/24)와 docker0(172.17.0.0/16)가 중복되면서, 운영체제가 라우팅을 잘못 설정하는 문제 발생!
✅ 결과적으로, 패킷이 잘못된 네트워크(docker0)로 전송되면서 서버2에 도달하지 못하는 현상이 발생한다.
👇🏻 이해가 안간다면 아래 글 보고오기
네트워크 기초 완벽 정리: 패킷, 라우팅, 게이트웨이, 네트워크 인터페이스
네트워크를 다루다 보면 패킷, 라우팅, 게이트웨이, 네트워크 인터페이스 같은 개념이 자주 등장한다.이번 글에서는 네트워크가 어떻게 작동하는지 기초부터 쉽게 설명해보겠다. 1. 네트워크
haesummy.tistory.com
서브넷 마스크와 네트워크 대역 쉽게 이해하기
이번달에는 블로그 글 20개를 써서 수익창출이 되는 블로그를 만들것이다.그래서 오늘의 주제는 잘못알면 헷갈리는 서브넷 마스크와 네트워크 대역 이다. 1. 서브넷 마스크란?IP 주소는 보통 A.B
haesummy.tistory.com
3. 라우팅 테이블을 통한 패킷 흐름 분석 (서버 1 → 서버 2)
좀 더 자세히 서버 1 (172.17.1.10) 서버 2 (172.16.1.10, Docker 실행 중) 으로 패킷이 어떻게 전달되는지 라우팅 테이블을 단계별로 확인하면서 문제를 분석해보자.
1️⃣ 서버 1 (172.17.1.10)에서 서버 2 (172.16.1.10)로 패킷을 보내는 과정
🚀 서버 1에서 서버 2로 ping을 보낼 때
📌 서버 1의 라우팅 테이블 확인
default via 192.168.1.1 dev ens192
172.16.1.0/24 via 192.168.1.1 dev ens192 ✅ (서버 2로 가는 경로)
172.17.1.0/24 dev ens192 proto kernel scope link src 172.17.1.10
📌 패킷 흐름
- 서버1 (172.17.1.10)에서 172.16.1.10으로 패킷을 전송
- 라우팅 테이블에 172.16.1.0/24로 가는 경로가 있음 → 게이트웨이(192.168.1.1)를 통해 서버 2로 전달
- 서버2 (172.16.1.10)가 서버1의 패킷을 받음
✅ 서버 1에서는 문제가 없음! 서버2가 서버1의 패킷을 받는것도 문제가 없음!
2️⃣ 서버 2 (172.16.1.10)에서 패킷을 받고 서버1로 응답을 보낼 때
🚀 서버 2에서 라우팅 테이블 확인
default via 192.168.1.1 dev ens192
172.16.1.0/24 dev ens192 proto kernel scope link src 172.16.1.10
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 ❌ (문제 발생!)
📌 패킷 흐름 분석
- 서버 1에서 ping 172.16.1.10을 전송
- 서버 2가 패킷을 받지만, 받은 후 서버1에 응답하려고 라우팅 테이블에서 172.16.x.x을 찾아보니 172.17.0.0/16이 docker0로 설정됨
- 운영체제가 "172.17.x.x로 향하는 패킷은 docker0로 보내야 한다!"라고 판단
- 결과적으로 패킷이 docker0 네트워크 내부로 들어가 버리고, 서버 2에서 정상적으로 응답하지 못함
🚨 즉, 172.17.1.10을 찾지 못하고 패킷이 잘못된 경로로 가서 통신이 차단됨!
✅ 서버 2에서 Docker가 기본적으로 172.17.0.0/16을 사용하면서, 172.17.1.10이 올바르게 인식되지 않는 것이 문제! 🚨
4. 해결 방법: Docker의 기본 네트워크(docker0)를 변경하기
해결 방법은 Docker가 자동으로 생성한 docker0 네트워크의 서브넷을 기존 네트워크와 겹치지 않는 범위로 변경하는 것!
방법 1 - /etc/docker/daemon.json 수정하여 기본 네트워크 변경
1️⃣ Docker의 기본 네트워크를 변경 (없으면 새로 생성)
cat <<EOF > /etc/docker/daemon.json
{
"bip": "192.168.100.1/24"
}
EOF
✅ bip 설정을 통해 기본 브릿지 네트워크(docker0)의 서브넷을 기존 네트워크와 겹치지 않도록 변경
🚨 변경할 서브넷 추천
- 192.168.100.0/24
- 10.10.10.0/24
- 📌 이런식으로 기존 네트워크와 겹치지 않는 범위를 선택해야 한다.
2️⃣ Docker 서비스 재시작
systemctl restart docker
Docker를 재시작하면 새로운 docker0 네트워크가 적용됨
3️⃣ 변경된 네트워크 확인
docker network inspect bridge
Subnet: 192.168.100.0/24가 설정되었는지 확인!
4️⃣ 기존 컨테이너 재시작
docker ps -q | xargs docker restart
모든 컨테이너를 재시작하여 새 네트워크를 적용!
방법 2 - 컨테이너 실행 시 별도 네트워크 지정
1️⃣ 새로운 Docker 네트워크 생성
docker network create --subnet=192.168.100.0/24 my_custom_network
192.168.100.0/24 범위의 사용자 정의 네트워크 생성
2️⃣ 컨테이너 실행 시 네트워크 지정
docker run --net=my_custom_network --ip=192.168.100.100 -d 이미지
컨테이너가 192.168.100.100 IP를 사용하도록 설정
3️⃣ 네트워크 확인
docker network inspect my_custom_network
192.168.100.0/24 서브넷이 설정되었는지 확인!
5. 핵심 정리
- Docker 기본 네트워크(docker0)가 자동으로 172.17.0.0/16을 사용하면서 기존 네트워크와 충돌하는 문제 발생! 🚨
- Docker 실행 후 네트워크 경로가 꼬여, 기존 네트워크(172.17.1.0/24)와의 통신이 차단됨.
- 해결 방법
- /etc/docker/daemon.json에서 bip 설정을 변경하여 기본 네트워크를 다른 서브넷(192.168.100.0/24)으로 변경
- 새로운 Docker 네트워크를 생성(docker network create)하고 컨테이너 실행 시 네트워크를 지정
✅ 이제 Docker 실행 후에도 기존 네트워크 연결이 유지되면서, 서버2에 정상적으로 접근할 수 있다.
'🌀Full-Stack&Beyond' 카테고리의 다른 글
쿠버네티스 아키텍처 완벽 가이드: 컨테이너 오케스트레이션부터 배포 흐름까지 (0) | 2025.03.19 |
---|---|
도커 Nginx 환경에서 logrotate를 활용한 자동 로그 관리 방법 (0) | 2025.02.27 |
네트워크 기초 완벽 정리: 패킷, 라우팅, 게이트웨이, 네트워크 인터페이스 (0) | 2025.02.26 |
서브넷 마스크와 네트워크 대역 쉽게 이해하기 (0) | 2025.02.26 |
인터넷에 www.naver.com을 입력하면 무슨 일이 일어날까? 🌍 (0) | 2025.02.23 |