쪽팔리면 질문하지 맙시다. 소중한 답변 댓글을 삭제하는건 부끄러운 일 입니다
안녕하세요. 거진 일주일을 삽질해봐도 답이 나오지 않아 문의드립니다.
현재 공부도 할 겸, Docker-compose 를 통해 DB, 웹서버 등을 각각의 컨테이너로 구축하여 운용 중에 있습니다.
DB 를 사용하는 컨테이너가 여러개 돌아가는 상황이라, DB 와 Web 을 각각의 컨테이너로 구성하였습니다.
이런 상황에서, 각 컨테이너에서 접근해야 하는 사용자에게만 DB 컨테이너로의 접근을 허가하고, 나머지 IP 에서는 접근을 차단하려고 합니다.
(단일 서버 내에서 docker container 끼리 통신해야 하는 상황)
이를 위해 Docker-compose 에서 별도의 network 를 생성하고, 모든 컨테이너에 각각의 static IP 부여, 각각의 유저에 대한 접근 권한을 설정하였습니다.
그러나, 정작 DB서버 로그를 확인해 보면, 컨테이너 IP 가 아닌 네트워크의 게이트웨이 IP 가 찍혀 DB 서버로의 정상적인 접근이 불가능한 상황입니다.
예를 들어, 네트워크 게이트웨이 IP가 172.1.0.1 이고, A (172.1.0.4) 가 DB 로 접속할 컨테이너, B (172.1.0.2) 가 DB 컨테이너라고 해 보면,
A 에서만 a_admin 유저로 접속을 허가하기 위해, DB 유저 생성 시 'a_admin'@'172.1.0.4' 로 지정하였습니다.
그러나 A 에서 접속이 불가능하여 DB 로그를 확인해 보면, 'a_admin'@'172.1.0.1' 이라 출력됩니다.
그러니깐, DB 컨테이너 측에서는 Inbound IP 를 게이트웨이 IP로 인식해버리는 상황입니다.
A 에서 B 로 ping 을 날리고, B 측에서 tcpdump 를 통해 확인해 봐도, 172.1.0.4 가 아닌 172.1.0.1 이 찍힙니다.
혹시 몰라서, 네트워크와 고정 IP를 설정하지 않고, Docker 에서 기본으로 잡아주는 것을 사용하면,
DB 에서는 희안하게 A 컨테이너의 IP 를 잘 인식합니다.
이론 상, Static IP 를 지정하면, (모든 컨테이너는 단일 서버에서 돌아가므로) IP 를 통해 특정 컨테이너만 접속을 허가할 수 있을 것이라 생각하였는데,
이론이 틀린건지, 설정에 문제가 있는건지,, 공부하기도 쉽지 않네요.
ping 을 날려도 동일한 것을 보면 docker 자체 문제라고 생각되긴 하지만.. 뭐가 문제인지 모르겠습니다.
Google 서치를 해 봐도, 이런 사례는 도무지 찾아볼 수 없어서 여쭙고자 합니다. 아래쪽에 docker-compose.yml 설정 일부 발췌하 남겨두겠습니다.
고견 미리 감사드립니다 :D
version: "3.8" services: database: container_name: database image: mariadb:latest expose: - "3306" networks: customNet: ipv4_address: 172.1.0.2 client: container_name: client networks: customNet: ipv4_address: 172.1.0.4 networks: customNet: driver: bridge ipam: config: - subnet: 172.1.0.0/16 gateway: 172.1.0.1
À§¿Í °°Àº ¹æ¹ýÀ» ÇؾßÇÑ´Ù¸é DB¸¦ reverse proxy¸¦ ÅëÇؼ Á¢¼ÓÇÏ°Ô ÇÑ ´ÙÀ½, ±× reverse proxy °úÁ¤¿¡¼ allow¿Í deny¸¦ Çغ¼ °Í °°½À´Ï´Ù.
³ª¸ÓÁö µ¥ÀÌÅͺ£À̽º¿¡´Â Á¢±ÙÇÒ ¼ö ¾ø±¸¿ä.
¸®¹ö½º ÇÁ·Ï½Ã´Â, ÀÌ ¹®Á¦°¡ ÇØ°áµÇÁö ¾ÊÀ¸¸é µµÀÔÇغ¼±î ½Í¾ú´Âµ¥,, ¸®¹ö½ºÇÁ·Ï½Ã ¼ÂÆõµ Á» ¾Ë¾ÆºÁ¾ß°Ú³×¿ä.
´äº¯ °¨»çµå¸³´Ï´Ù~
¿¹¸¦ µé¾î NIC¿¡ 192.168.100.254/24¸¦ ÇÒ´çÈÄ ÄÁÅ×À̳ʵéÀ» 192.168.100.0/24ÀÇ ÁּҴ븦 ÇÒ´çÇÏ´Â ¹æ¹ýÀÔ´Ï´Ù
¿ÜºÎ Åë½ÅÀÌ ÇÊ¿äÇÏ´Ù¸é ³×Æ®¿öÅ© ÀåºñÂÊ¿¡ ÇØ´ç ¼ºê³ÝÀ» Ãß°¡ÇØÁÖ°í, NAT ó¸®Çϸé Á¤»ó 󸮵˴ϴÙ
ºê¸´Áö·Î È£½ºÆ®¶û µ¿ÀÏ ³×Æ®¿öÅ©¿¡ ºÙÀ̸é Á¦´ë·Î ¾Ë¾Æ¸ÔÀ»²®´Ï´Ù
Áö±Ý »óÅ°¡ ¹«Á¶°Ç ÄÁÅ×À̳Ê-GW-ÄÁÅ×ÀÌ³Ê ÀÌ·¸°Ô Åë½ÅÀÌ µÇ´Â°Í°°À¸´Ï±î¿ä
Àú·¸°Ô ÇÑ°æ¿ì ¿ÜºÎ Á¢±Ù ¸·À»·Á¸é NICÂÊÀÇ ÁÖ¼Ò Çϳª¸¸ deny·Î µî·ÏÇÏ¸é µË´Ï´Ù
¶ö±î 2°³ÀÇ ÄÁÅ×À̳ʰ¡ µ¿ÀÏ ¼¹ö¶ó¸é ¾ÖÃÊ¿¡ ¼¹öÀÇ ¹æȺ®¿¡¼ ¾È ¿¾îÁÖ¸é ¿ÜºÎ¿¡¼ Á¢±ÙÀÌ ¾È µË´Ï´Ù (´Ù¸¥ ÄÁÅ×À̳ʴ Á¢±Ù °¡´É)
ÀÌ ¹æ¹ý µµÀÔµµ °í·ÁÇغÁ¾ß°Ú½À´Ï´Ù. ´äº¯ °¨»çµå¸³´Ï´Ù~
´Ù¸¸ Á¢±Ù ±ÝÁöÂÊÀº ¼³Á¤ ¾È Çسö¼ (ÇÊ¿äÇÏ¸é ³×Æ®¿öÅ© Àåºñ¿¡¼ ¼³Á¤ÇÏ´ÂÁö¶ó) ¾î¶»°Ô µÉÁö ¸ð¸£°Ú³×¿ä
ÀÛ¾÷Àü ¿øº¹ ÆíÇÏ°Ô ¼³Á¤ÆÄÀÏ ¹é¾÷ÇصνŴÙÀ½ ½ÃµµÇغ¸¼¼¿ä (³ªÁß¿¡ ¿øº¹½Ã ÀÌ°É µ¤¾î¾²°í, NICÀÇ ÁÖ¼Ò¸¸ Á¦°ÅÇÏ¸é µÊ)
ÁÖ¼Ò Ãß°¡ -> ÁÖ¼Ò ¼³Á¤ º¯°æ¹× Àç½ÇÇà -> ÆÐŶÀÌ ¾î¶»°Ô Èê·¯°¡´ÂÁö È®ÀÎ
ÀÌÁ¤µµ¸¸ ÇغÁµµ Àß µÇ´ÂÁö È®ÀÎÀº °¡´ÉÇÒ²®´Ï´Ù (¼º°øÇÏ¸é ¹Ù·Î °¥²¨°í, ½ÇÆÐÇϸé NIC¿¡ »õ·Î Ãß°¡ÇÑ ÁÖ¼Ò¸¦ °æÀ¯Çؼ °¥Å״ϱî¿ä)
NIC ¿¡ ¼ºê³Ý Ãß°¡ÇÏ´Â ¹æÇâÀ¸·Î ¾Ë¾ÆºÁ¾ß°Ú³×¿ä.
Áñ°Å¿î ÇÑ°¡À§ º¸³»¼¼¿ä~
¾Æ¹«·¡µµ bridge ½ÄÀÌ ¾Æ´Ï°í nat½ÄÀ¸·Î ±¸¼ºÀÌ µÇÁö ¾Ê¾Ò³ª ½Í½À´Ï´Ù.
bridge´Â ÀÚ½ÅÀÇ ip¸¦ °®°í ±×°ÍÀ¸·Î Åë½ÅÈ÷Áö¸¸ nat´Â »óÀ§ÀÇ ip·Î Á¢±ÙÀ» ÇÏ°Ô µÇ¾î ÀÖÀ¸´Ï±î¿ä.
dbÂÊ¿¡¼ gatewayÀÇ ip°¡ º¸ÀÎ´Ù´Â°Ç gateway°¡ nat°¡ µÇ¾î proxy¸¦ ÇØÁÖ°í ÀÖ´Â µí ÇÕ´Ï´Ù.
³×Æ®¿öÅ© ¼³Á¤ ºÎºÐÀ» Á» »ìÆ캸¼Å¾ß ÇÒ µí ÇÕ´Ï´Ù.
docker-compose network °ü·Ã ¼³Á¤À» Á» ã¾Æº¸¸é¼, »ðÁú Á» ´õ ÇغÁ¾ß ÇÒ °Í °°³×¿ä. ´äº¯ °¨»çµå¸³´Ï´Ù~