Django poj.c E2) 실패한 모든 시도의 원인은 방화벽이었다 - 32일차

Code E - Server 2번 글, 프로젝트 32일차 (목)

 

 

 

 

 

0. 

해결 방법

Docker 가 사용하는 172번으로 시작하는 IP의 nas 방화벽 개방

(default bridge - 172.17.0.1~ , custom bridge - 172.18.0.1~ )

 

 

 

 

1.

기존에 시도했던 Docker in docker 가 작동하지 않았던 이유도,

우분투 컨테이너에 정상적으로 설치했던 도커 엔진이 작동하지 않았던 이유도,

도커 브릿지에 묶여 있는 컨테이너 사이에 통신이 불가능했던 이유도,

그 외에 수없이 생성되었다 삭제된 컨테이너와 이미지들 모두가,

그 모두의 원인은 단 하나였다.

 

그 한 가지 원인을 깨닫는데 하루

해결하는데 하루가 걸렸다.

 

 

 

 

 

2. 원인

 

22번 포트를 이용한 ssh 접속이나, DB와 연동하여 레코드를 CRUD 하는 것 모두 동작한다.

 

그러나 브릿지로 연결된 다른 컨테이너와의 통신이 동작하지 않았다.

한참을 헤맨 뒤에 iputils-ping를 설치하고 ping 8.8.8.8을 날렸을 때

구글 서버로부터 응답을 받지 못한다는 것을 깨달았다.

 

밖에서 안으로 접속은 가능했으나 안에서 밖으로 어떠한 신호도 나가지 못하고 있었던 것이다. 

 

apt-get이 정상적으로 작동했기 때문에 안에서 밖으로의 통신이 원활하지 않다는 생각을 떠올리는데 너무 오래 걸렸다.

 

 

 

 

 

 

3. 겨우 찾아낸 실마리

 

같은 조건의 컨테이너를 nas가 아닌 mac의 도커 엔진으로 작성했을 때는 잘 동작한다는 점을 깨달았고

mac 환경과 nas 환경이 무엇이 다를까 고민하였다.

 

어느 블로그였는지 스택오버플로우 글이었는지 기억은 나지 않으나

잠들기 전에 모바일로 읽은 문서에서 nas에서 docker container를 위해 포트를 개방하는 내용을 읽었다.

 

아.. 방화벽이 문제였을까?

 

다음날, 방화벽을 재설정하였고 문제가 모두 해결되었다.  

 

 

 

 

 

4. 방화벽의 원리?

 

방화벽의 규칙은 외부에서 내부로 접근했을 때만 작동한다고 생각을 하였다.

그러나 외부에서 내부로의 접근뿐 아니라 네트워크 전체를 지배하는 룰이었던 것 같다.

 

생각해보면 그동안 네트워크 안에서 사용했던 ip는 모두 192.168.0.xxx 범위 안에 있었다.

 

방화벽의 ip 관련 설정은 nas 구입 초기에 설정 한 이후 손을 댄 적이 없었다.

이후로는 어느 포트를 개방하고 닫을 것인지에 대해서만 수정했고

 

ip에 대해서는 생각을 전혀 안 하고 있었기 때문에

문제 원인을 찾는데 오랜 시간이 걸리지 않았나..

 

 

 

 

 

 

5.

요즘 원치 않게 리눅스와 터미널과 네트워크의 지식과 경험이 크게 늘고 있다.