192.168./172.16–31./10. 사설 네트워크 IP 의 모든 것

Photo by Nastya Dulhiier on Unsplash

192.168.x.x, 172.16–31.x.x, 10.x.x.x 형태의 IP 대역을 활용해 보신 분 있다면, 여기 붙어라.

회사 내에 On-Premise 환경을 구축하거나, 클라우드 환경 내 사설 네트워크 (AWS VPC 등) 를 구축할 때, 어떻게 네트워크를 설계하고 IP 를 할당 할지 혼란스러운 경우가 있다.

특히 웹 서비스의 경우, 서비스 이용자가 최초로 진입하는 DMZ (Demilitarized Zone) 를 위한 public-zone 설정, DMZ 를 경유한 웹 요청의 내부적 처리를 위한 private-zone 설정 등. 아래와 같이 혼란스럽고 기본 개념을 충분히 숙지하지 않으면 괜히 시간만 낭비하는 상황들이 있다.

• 내 PC (예: 13.124.43.23) 에서 private-zone 에 생성한 서버 (예: 10.0.1.12) 가 접근이 안돼요.
  - AWS 예: 내 PC 에서 private-subnet 에 생성한 EC2/ElastiCache/RDS 가 접근이 안돼요.
• 서버1 (예: 10.0.1.13) to 서버2 (예: 14.125.44.2) 형태의 API Call 을 위해 서버2의 방화벽 허용 설정을 하였는데 통신이 안돼요.
• 사설 네트워크를 설계하고 특정 서버에 IP (예: 13.54.2.4) 를 할당 하였는데요! public-ip 형태로 보이는데 접근이 안되네요! 😅😅😅

그렇다. 위 사항들은 사설 (private) 네트워크 & 공인 (public) 네트워크 및 IP 할당에 대한 기본적인 이해만 있다면 누구든지 쉽게 원인은 분석하고 대응할 수 있는 문제이다.

요약/결론

• 192.168.x.x, 172.16–31.x.x, 10.x.x.x IP 대역은 사설 네트워크를 위한 것이다. 해당 자원이 속한 사설 네트워크 내에서만 서로 요청이 가능하다. (사설 네트워크 IP 대역은 해당 네트워크 바깥으로 나가서 요청이 처리될 수 없다는 얘기이다.)
• Client 가 요청하는 IP 의 형태 (공인 IP or 사설 IP) 에 따라 목적지에서 받아들이는 요청지 (source ip) 의 정보는 다르다.

192.168./172.16–31./10. IP 대역은 사설 네트워크를 위한 것이다.

인터넷 주소 할당을 관리하는 IANA/ICANN 에서는 RFC-1918 의 내용을 토대로 사설 네트워크 (Private Internet) IP 활용을 제안하고 있다.

RFC-1918: 사설 네트워크에서 활용하는 IP 대역

* 사설 네트워크에 활용하는 IP 대역 범위는 10.0.0.0 ~. 10.255.255.255, 172.16.0.0 ~ 172.31.255.255, 192.168.0.0 ~ 192.168.255.255 이다.

사설 네트워크에서 활용하는 IP 범위는 위 3가지 형태이다. 인터넷이 발달하고 확장되면서 할당할 수 있는 IPv4 형태의 IP 가 고갈되었는데, 개인/조직의 내부 사설 네트워크에서는 위 IP 범위를 마음껏 활용할 수 있다.

보통 IP 는 특정한 PC/자원 등을 전 세계적으로 유일하게 가리키는데 활용하는데, 위 3 범위의 IP 는 특정 개인/조직 내에서 설정한 사설 네트워크 안의 유일한 자원을 가리킨다. 아래 처럼 활용이 가능하다.

각 조직에서 사설 네트워크를 구성하고 IP 할당하는 예

Company-A 의 IP 활용과 Company-B 의 IP 활용이 겹치는 것을 걱정하지 않아도 된다. 사설 네트워크 IP 대역은 말 그대로 해당 조직 내에서만 활용하는 IP 대역이니까.

이것이 가능한 이유는 사설 네트워크 IP 대역을 각 라우터에서 어떻게 취급하고 있는지를 보면 알 수 있다.

RFC-1918: 인터넷의 라우터들은 사설 네트워크 주소를 활용하지 않도록 설정되어 있다.

* 인터넷 네트워크에 존재하는 라우터에서는 사설 네트워크 관련 처리를 거부하도록 설정되어야 한다.

즉, 사설 네트워크 IP 대역은 해당 네트워크 바깥으로 나가서 요청이 처리될 수 없다는 얘기이다. 그래서 다른 조직의 사설 네트워크에서 활용하는 IP 가 겹치더라도 걱정하지 않아도 된다.

Client 가 요청하는 IP 의 형태 (공인 IP or 사설 IP) 에 따라 목적지에서 받아들이는 요청지 (source ip) 의 정보는 다르다.

회사 내 사설 네트워크에서 할당받은 내 PC 의 IP 를 “10.0.0.99” 라고 하자. 그렇다면 회사 바깥에서 내 PC 를 IP 로 접근하고 싶을 경우 어떻게 해야하나? 기본적으로는 ‘못한다’ 이다.

회사 바깥의 특정 Client 에서 “10.0.0.99” 로 어떠한 요청을 해도 (위에서 언급한 라우터의 제한 사항으로) 목적지에 도달하지 못하고 Client 가 속한 네트워크 내에서만 요청이 머물것이다.

단, 각 주체별 네트워크가 VPN 연결 구성이 되어있다면 가능하다. VPN 은 별개의 네트워크를 하나의 망 처럼 연결해주는 역할을 하는데, VPN 환경이 구축되어 있다면 사실 회사 바깥의 특정 Client 또한 동일 네트워크 범주에 속하게 되니 “바깥” 이라고 보기는 힘들다.

인터넷으로 향하는 모든 요청들은 응답을 받기 위한 유일한 공인 IP (public-ip) 를 가져야 하는데, 사설 네트워크 내 특정 PC 는 어떻게 인터넷으로의 요청을 수행할까?

인터넷과 직접 연결되는 Gateway 는 공인IP (public ip) 를 가진다.

Company-A 의 사설 네트워크에 속해 있는 특정 Client (예: 10.0.0.1) 에서 인터넷으로 요청하면 필시 인터넷과 사설 네트워크를 연결해주는 Gateway (예: NAT Gateway) 를 거치게 된다. Gateway 는 Gateway 를 유일하게 가리키는 공인 IP (public ip) 를 가지고 있으며, 우리가 구글 혹은 아마존으로 웹 요청을 할 경우 발신지 IP (source ip) 는 Gateway IP 가 된다.

구글 혹은 아마존에서 처리된 응답 결과는 해당 Gateway IP 로 응답하게 되며, Gateway 는 웹 요청이 연결돼있는 동안 연결에 대한 정보를 가지고 있으므로 사설 네트워크의 특정 Client (예: 10.0.0.1) 로 결과를 전달하게 된다.

주의할 점은, 같은 네트워크에 위치한 자원들 간에 통신을 할 때 어떤 IP (공인 IP 또는 사설 IP) 로 요청을 하는지에 따라 취급되는 방식이 다를 수 있다는 것이다.

Destination 을 사설IP 로 요청했을 때와 공IP 로 요청했을 때는 차이가 있다.

위 그림과 같이 Client 와 동일망에 존재하는 Server 가 private-ip 와 public-ip 를 동시에 가지고 있다고 해보자.

• Client 가 Server 의 공인 IP (13.12.13.2) 로 요청을 한다면, 해당 요청은 해당 네트워크의 바깥으로 요청된 후 라우터를 거쳐 해당 네트워크의 Server 로 다시 요청된다. 즉 Server 가 알게되는 Client 의 정보는 Client 의 사설 네트워크 IP 가 아니라 Gateway 의 공인 IP 를 요청지 IP 로 알게 된다.
• Client 가 Server 의 사설 네트워크 IP (10.1.0.1) 로 요청을 한다면, 해당 요청은 해당 네트워크 내부에 설정된 라우팅 규칙대로 Server (10.1.0.1) 로 향하게 될 것이다. Server 가 알게되는 Client 의 정보는 Client 의 사설 네트워크 IP 정보 그대로이다.

최근 클라우드 환경이 나오면서 직접 개별 네트워크를 구성하고 방화벽 설정하는 경우가 많은데, 위 사항을 고려하여 설정시 발생하는 사소한 문제들을 잘 해결할 수 있기를 바란다.