Docker 네트워크 요청의 출발지와 목적지 및 전달과정

Docker 네트워크 요청의 출발지와 목적지 및 전달과정

 

 

만약 도커 컨테이너에서

외부 요청이 목적지에 도착 전 거친 네트워크 인터페이스의 IP와 포트를 출발지(src)로 표시하게 작성었다면,

curl 명령어로 구동중인 호스트의 가상 인터페이스 IP(192.168.1.10)와 로컬호스트 IP(127.0.0.1)의 60431번 포트에 요청을 보내보면 출발지의 IP가 다르게 표시됨을 확인할 수 있습니다.

 

일단 위 src IP를 살펴보면

  - 172.17.0.1  :  컨테이너 브리지 인터페이스(docker0)의 IP

  - 192.168.1.10  :  호스트 인터페이스(eth1)의 IP  

 

 - eth1 : 외부 요청을 받아들이는 네트워크 인터페이스

 - docker0 : 도커 컨테이너가 사용하는 네트워크 인터페이스

   → 도커 컨테이너가 외부와 통신하려면 docker0을 거쳐야 합니다.

   → 도커 컨테이너는 생성될 때 docker0에 부여된 172.17.0.0/16 범위에 해당하는

       172.17.0.2~172.17.255.254(172.17.0.1은 docker0에서 사용) 사이의 IP를 할당받습니다.

 

   → 외부 IP에서 들어오는 요청을 컨테이너 내부 IP로 전달하는 경우 경로 전달규칙이 리눅스 호스트에 설정됩니다.

       (ex. 모든 네트워크 어댑터(0.0.0.0)의 60431번 포트로 들어오는 요청을 컨테이너 내부로 전달시)

        그 결과 컨테이너 내부로 요청을 보낼 경우 출발지는 192.168.1.10:60431이 표시됩니다.

 

    → 반면에 127.0.0.1이나 localhost와 같은 내부 IP에서 컨테이너 내부로 요청을 전달할 경우

         docker-proxy 프로세스가 컨테이너 내부로 요청을 전달하는 역할을 하며

         이 과정에서 도커가 사용하는 네트워크 인터페이스의 IP인 172.17.0.1을 출발지로 사용합니다.

 

     → 따라서 docker-proxy 프로세스에 문제가 발생하면

         내부 IP로는 컨테이너 내부에 요청을 전달할 수 없을 뿐 만 아니라

         컨테이너 내부에서 호스트 외부 IP와 포트로 요청을 보낼 수 없는 문제가 발생합니다.

 

  ※ 참고 :  생활 네트워크 : Hairpin NAT / NAT Loopback의 이해 - 1 편_서버포럼