NAT 와 사설 네트워크

마지막이 자주 오해되는 지점입니다. NAT 뒤에 있으면 외부에서 먼저 연결할 수 없어 안전해 보이지만, 그것은 의도한 보안이 아니라 구조의 부산물입니다. 포트 포워딩을 하나 열면 그대로 노출되고, 내부에서 나가는 통신은 전혀 검사되지 않습니다.

흔한 실수: NAT 를 방화벽으로 여겨 별도 정책을 두지 않는 것. 내부 기기가 감염돼 밖으로 데이터를 보내는 것은 NAT 가 막지 않습니다.

양쪽 모두 외부에서 먼저 연결할 수 없으므로, 각자 자기 공인 주소를 알아내고 동시에 연결을 시도합니다.

4번이 이 방식의 핵심입니다. 내가 밖으로 보낸 패킷이 NAT 에 "이 주소와 통신 중"이라는 항목을 만들고, 그 덕분에 상대의 응답처럼 보이는 패킷이 통과합니다.

NAT 종류에 따라 성공률이 다릅니다. 도착지마다 다른 포트를 쓰는 방식이면 미리 알아낸 포트가 무효라 직접 연결이 실패하고 중계로 넘어갑니다.

흔한 실수: STUN 만 두고 TURN 을 생략하는 것. 기업 방화벽이나 엄격한 NAT 환경에서는 직접 연결이 실패하고, 중계 서버가 없으면 통화가 아예 안 됩니다.

인터넷에서 직접 닿아야 하는지와 가용영역을 기준으로 나눕니다.

가용영역마다 같은 구성을 반복합니다. 영역 하나가 죽어도 나머지로 서비스가 유지됩니다.

주소 범위를 정할 때 볼 것들입니다.

두 번째가 나중에 큰 문제가 됩니다. 모든 팀이 10.0.0.0/16 을 쓰면 VPC 를 서로 연결할 수 없습니다.

흔한 실수: 서브넷을 필요한 크기에 딱 맞게 잡는 것. IP 는 사설 대역이라 넉넉하고, 부족해서 다시 설계하는 비용이 훨씬 큽니다.

NAT 게이트웨이나 그에 준하는 출구가 필요합니다. 프라이빗 서브넷은 인터넷 게이트웨이로 직접 나갈 수 없습니다.

세 번째를 자주 놓칩니다. S3 나 DynamoDB 같은 같은 클라우드 서비스를 부르는데 NAT 게이트웨이를 거치면 데이터 처리 요금이 그대로 붙습니다. 엔드포인트를 만들면 그 트래픽이 내부망으로 빠져 비용이 크게 줄어듭니다.

라우팅 설정도 함께 봐야 합니다. 프라이빗 서브넷의 라우팅 표에서 기본 경로가 NAT 게이트웨이를 가리켜야 하고, NAT 게이트웨이 자체는 퍼블릭 서브넷에 있어야 합니다.

흔한 실수: NAT 게이트웨이를 프라이빗 서브넷에 두는 것. 자기도 나갈 길이 없어 아무것도 통과하지 못합니다.