NAT와 Firewall Policy

네트워크 경계에서 일어나는 두 가지 일

Private network가 public internet과 통신할 때는 보통 두 가지 문제가 동시에 등장한다.

첫 번째는 주소 문제다. 내부 host는 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 같은 private IP를 사용할 수 있다. 이 주소는 내부 network에서는 유효하지만 public internet에서는 직접 routing되지 않는다. 따라서 외부와 통신하려면 private IP를 public IP로 바꾸거나, public IP로 들어온 요청을 내부 private IP로 전달하는 변환 과정이 필요하다.

두 번째는 보안 정책 문제다. 어떤 traffic을 허용하고 어떤 traffic을 차단할지 결정해야 한다. 외부에서 내부로 들어오는 모든 packet을 허용하면 공격 표면이 커지고, 내부에서 외부로 나가는 traffic을 무조건 허용하면 침해된 host가 외부 command-and-control server와 통신할 수 있다.

이 두 문제를 담당하는 대표 기능이 NAT와 Firewall이다.

NAT:
IP address와 port를 변환한다.

Firewall:
traffic을 허용하거나 차단한다.

두 기능은 같은 장비나 같은 cloud gateway 안에 함께 들어 있는 경우가 많다. 하지만 역할은 다르다. NAT는 address translation이고, Firewall은 policy enforcement다.

---

Apartment analogy로 이해하기

NAT와 Firewall은 아파트 비유로 이해하기 쉽다.

Apartment Building = Private Network
Apartment Number   = Private IP Address
Street Address     = Public IP Address
Front Desk/Guard   = Firewall
Mailroom/Directory = NAT Table

아파트 안에는 101호, 102호, 103호 같은 호수가 있다. 이 호수는 건물 내부에서는 유일하지만, 다른 아파트 건물에도 같은 101호가 있을 수 있다. 즉 전 세계적으로 유일한 주소가 아니다.

Private IP도 비슷하다.

192.168.0.10
192.168.0.11
192.168.0.12

이 주소들은 집, 회사, 학교, 카페, 데이터센터 내부에서 반복해서 사용될 수 있다. 하지만 public internet에서는 이 주소들로 직접 route할 수 없다.

외부 세계에서 아파트를 찾을 때는 건물의 도로명 주소가 필요하다.

내부 주소:
Apartment 101

외부에서 보이는 주소:
123 Main Street

네트워크로 바꾸면 다음과 같다.

Private IP:
192.168.0.10

Public IP:
203.0.113.5

NAT는 내부 호수와 외부 주소 사이의 mapping을 관리하는 역할에 가깝다. Firewall은 이 출입 요청이 허용된 것인지 판단하는 경비원에 가깝다.

NAT:
이 응답은 내부의 어느 host에게 돌아가야 하는가?

Firewall:
이 traffic은 들어오거나 나가도 되는가?

---

NAT가 필요한 이유

NAT의 대표적인 배경은 IPv4 address 부족이다. 모든 device가 public IPv4 address를 하나씩 가져야 한다면 주소가 부족해진다. NAT를 사용하면 여러 내부 host가 하나 또는 소수의 public IP를 공유할 수 있다.

예를 들어 사무실에 100대의 PC가 있다고 하자.

PC 1:   192.168.1.10
PC 2:   192.168.1.11
PC 3:   192.168.1.12
...
PC 100: 192.168.1.109

이 100대가 각각 public IP를 하나씩 가질 필요는 없다. NAT 장비가 하나의 public IP 또는 public IP pool을 사용해 외부와 통신할 수 있다.

Internal private IPs
  ↓
NAT device
  ↓
Public IP
  ↓
Internet

NAT의 효과는 크게 두 가지다.

효과	설명
Public IPv4 절약	여러 private host가 하나 또는 소수의 public IP를 공유
내부 주소 은닉	외부 server는 내부 private IP를 직접 보지 않음

다만 주의할 점이 있다.

NAT는 내부 주소를 숨기는 효과가 있지만, NAT 자체를 완전한 보안 장치로 보면 안 된다. 실제 접근 제어는 Firewall policy와 함께 설계해야 한다.

---

Private IP와 Public IP

NAT를 이해하려면 private IP와 public IP를 먼저 구분해야 한다.

Private IP

Private IP는 내부 network에서 사용하는 주소다.

대표적인 private address range는 다음과 같다.

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

예시는 다음과 같다.

Home PC:         192.168.0.10
Office PC:       10.10.1.25
Kubernetes node: 10.0.2.15
Database VM:     172.16.5.20

이 주소들은 public internet에서 직접 routing되지 않는다.

Public IP

Public IP는 인터넷에서 routing 가능한 주소다.

203.0.113.5
198.51.100.10

Public IP는 전 세계 internet에서 유일해야 한다. 외부 server와 통신하려면 packet의 source나 destination 중 적절한 위치에 routable public IP가 있어야 한다.

구분	Private IP	Public IP
사용 위치	내부 network	public internet
전 세계 유일성	필요 없음	필요
인터넷 routing	직접 routing되지 않음	routing 가능
예시	192.168.0.10, 10.0.1.5	203.0.113.5
NAT 필요성	외부 통신 시 변환 필요	외부 통신 가능

---

NAT의 기본 동작

가장 일반적인 NAT 흐름은 내부 client가 외부 server로 요청을 보내는 경우다.

Client:        192.168.0.10
NAT public IP: 203.0.113.5
External API:  198.51.100.20

Client가 외부 server로 요청을 보낸다.

Before NAT:
Source IP      = 192.168.0.10
Destination IP = 198.51.100.20

NAT 장비는 source IP를 public IP로 바꾼다.

After NAT:
Source IP      = 203.0.113.5
Destination IP = 198.51.100.20

외부 server는 203.0.113.5에서 요청이 왔다고 본다. 응답도 203.0.113.5로 보낸다.

External Server Response:
Source IP      = 198.51.100.20
Destination IP = 203.0.113.5

NAT 장비는 자신의 translation table을 보고 이 응답이 원래 192.168.0.10으로 가야 한다는 것을 확인한다.

After reverse NAT:
Source IP      = 198.51.100.20
Destination IP = 192.168.0.10

이렇게 private IP를 가진 내부 host가 public internet과 통신할 수 있다.

---

NAT Table

NAT는 단순히 packet 하나의 주소를 바꾸고 끝나는 기능이 아니다. NAT 장비는 translation state를 유지해야 한다.

예를 들어 내부 client가 외부 server에 연결할 때 NAT 장비는 다음과 같은 mapping을 기록한다.

Internal:
192.168.0.10:51524

Translated:
203.0.113.5:40001

Destination:
198.51.100.20:443

NAT table로 표현하면 다음과 같다.

Internal Address	Translated Address	Destination	State
192.168.0.10:51524	203.0.113.5:40001	198.51.100.20:443	established
192.168.0.11:51524	203.0.113.5:40002	198.51.100.20:443	established

여기서 중요한 점은 port다. 여러 내부 host가 같은 public IP 하나를 공유하려면 NAT 장비는 IP뿐 아니라 port까지 함께 사용해 connection을 구분해야 한다.

이 방식은 보통 PAT 또는 NAPT라고 부른다.

PAT  = Port Address Translation
NAPT = Network Address Port Translation

일상적으로 “NAT”라고 부르는 많은 구조는 실제로 source IP뿐 아니라 source port까지 변환하는 PAT/NAPT다.

---

Static NAT, Dynamic NAT, PAT

NAT는 mapping 방식에 따라 여러 종류로 나눌 수 있다.

Static NAT

Static NAT는 내부 private IP와 외부 public IP를 1:1로 고정 mapping하는 방식이다.

192.168.0.10 ↔ 203.0.113.10

이 방식은 외부에서 내부 server로 들어와야 하는 경우에 사용할 수 있다.

예를 들어 내부 web server를 외부에 공개한다고 하자.

Public IP:  203.0.113.10
Private IP: 192.168.0.10
Service:    TCP 443

외부 사용자는 203.0.113.10:443으로 접속하고, NAT 장비는 이를 192.168.0.10:443으로 전달할 수 있다.

장점은 mapping이 명확하다는 것이다. 단점은 public IP를 많이 사용한다는 것이다.

Dynamic NAT

Dynamic NAT는 내부 private IP를 public IP pool 중 하나로 동적으로 mapping하는 방식이다.

Private pool:
192.168.0.0/24

Public pool:
203.0.113.10-203.0.113.20

내부 client가 외부로 나갈 때 public IP pool에서 하나를 할당받고, session이 끝나면 반환된다.

장점은 static NAT보다 유연하다는 것이다. 단점은 동시에 통신하는 내부 host 수가 public IP pool보다 많으면 문제가 생길 수 있다는 점이다.

PAT 또는 NAT Overload

PAT는 여러 private IP가 하나의 public IP를 공유하도록 port를 함께 변환하는 방식이다.

192.168.0.10:51524 → 203.0.113.5:40001
192.168.0.11:51524 → 203.0.113.5:40002
192.168.0.12:51524 → 203.0.113.5:40003

외부에서 보면 모두 203.0.113.5에서 온 요청처럼 보이지만, NAT 장비는 port mapping을 통해 내부 host를 구분한다.

이 방식은 가정용 router, 회사 인터넷 egress, cloud NAT gateway에서 매우 흔하게 사용된다.

---

SNAT와 DNAT

운영 관점에서는 SNAT와 DNAT를 구분하는 것이 중요하다.

SNAT

SNAT는 Source NAT다. Packet의 source address를 바꾼다. 내부 host가 외부 internet으로 나갈 때 주로 사용한다.

Before SNAT:
Source      = 192.168.0.10
Destination = 198.51.100.20

After SNAT:
Source      = 203.0.113.5
Destination = 198.51.100.20

대표 용도는 다음과 같다.

• private subnet instance의 outbound internet access
• 내부 server의 package update
• 외부 API 호출
• Kubernetes node 또는 pod의 egress traffic
• VPC private resource의 public service 접근

DNAT

DNAT는 Destination NAT다. Packet의 destination address를 바꾼다. 외부에서 public IP로 들어온 traffic을 내부 private server로 전달할 때 사용한다.

Before DNAT:
Source      = 198.51.100.50
Destination = 203.0.113.10:443

After DNAT:
Source      = 198.51.100.50
Destination = 192.168.0.10:443

대표 용도는 다음과 같다.

• port forwarding
• public IP를 내부 web server로 연결
• load balancer 또는 reverse proxy 전단 NAT
• Kubernetes NodePort 또는 Service traffic 처리 구조 일부
• firewall에서 external VIP를 internal server로 mapping

SNAT와 DNAT를 함께 쓰는 경우도 많다. 외부 사용자가 public IP로 들어오고, 내부 server가 응답을 같은 firewall을 통해 되돌려 보내야 하는 구조에서는 destination과 source가 모두 변환될 수 있다.

---

NAT와 Routing의 차이

NAT와 routing은 자주 헷갈리지만 다른 개념이다.

Routing은 packet을 어느 next hop으로 보낼지 결정한다.

Destination 198.51.100.20은 gateway 10.0.0.1로 보낸다.

NAT는 packet의 address 또는 port를 바꾼다.

Source 192.168.0.10을 203.0.113.5로 바꾼다.

구분	Routing	NAT
목적	packet의 경로 결정	packet의 주소 또는 port 변환
기준	destination IP, route table	NAT rule, connection state
결과	next hop 결정	source/destination address 변경
예시	0.0.0.0/0 → gateway	192.168.0.10 → 203.0.113.5

NAT가 있어도 route가 없으면 packet은 나갈 수 없다. 반대로 route가 있어도 private IP가 public internet에서 routable하지 않으면 응답이 돌아오지 않는다.

---

Firewall의 기본 역할

Firewall은 network traffic을 허용하거나 차단하는 보안 장치다.

Firewall의 기본 질문은 다음과 같다.

이 packet 또는 connection을 허용할 것인가?
차단할 것인가?
기록할 것인가?
검사할 것인가?
다른 보안 기능으로 넘길 것인가?

Firewall rule은 보통 다음 조건을 본다.

Source IP
Destination IP
Protocol
Source port
Destination port
Direction
Interface 또는 zone
Connection state
Application
User identity
Threat signature

가장 단순한 firewall rule은 다음처럼 표현할 수 있다.

allow tcp from 0.0.0.0/0 to web-server port 443
deny all other inbound traffic

Firewall의 핵심은 정책 기반 통제다.

---

Stateless Firewall과 Stateful Firewall

Firewall은 connection state를 추적하는지에 따라 stateless와 stateful로 나눌 수 있다.

Stateless Firewall

Stateless firewall은 packet 하나하나를 독립적으로 검사한다. 이전 packet이나 connection의 흐름을 기억하지 않는다.

예를 들어 다음 rule이 있다고 하자.

allow outbound tcp 443
deny inbound all

내부 client가 외부 HTTPS server로 요청을 보낸 경우, 응답 packet은 inbound 방향으로 돌아온다. Stateless firewall은 이 응답이 내부에서 시작된 connection의 일부인지 기억하지 못한다. 따라서 별도 inbound rule이 없으면 응답이 막힐 수 있다.

Packet 단위 검사
Connection state 기억 없음
Return traffic을 별도로 허용해야 할 수 있음

Stateful Firewall

Stateful firewall은 connection state를 추적한다.

내부 client가 외부 server로 연결을 시작하면 firewall은 state table에 이 connection을 기록한다.

Internal client → External server: allowed
State table에 connection 기록
External server → Internal client: established response로 허용

예시 state table은 다음과 같다.

Source	Destination	Protocol	State
192.168.0.10:51524	198.51.100.20:443	TCP	established

Stateful firewall은 return traffic을 connection context 안에서 판단할 수 있다.

내부에서 시작한 connection의 응답인가?
이미 established된 session인가?
비정상적인 SYN packet인가?

일반적인 기업 firewall, cloud security group, home router firewall은 stateful 동작을 포함하는 경우가 많다.

---

Application Firewall과 NGFW

기본 firewall은 IP, port, protocol 중심으로 traffic을 제어한다. 하지만 modern application 환경에서는 이것만으로 부족할 수 있다.

예를 들어 둘 다 TCP 443을 사용해도 traffic의 성격은 다를 수 있다.

HTTPS web browsing
Slack
GitHub
Malware C2
파일 공유 서비스
관리자 console

더 고급 firewall은 application layer까지 검사한다.

HTTP method
URL path
TLS SNI
User identity
Application signature
Payload pattern
Threat intelligence
Malware signature

이런 기능을 가진 장비를 흔히 NGFW(Next-Generation Firewall)라고 부른다.

구분	검사 기준
Packet filter	IP, port, protocol
Stateful firewall	connection state
Application firewall	application-level context
NGFW	application, user, content, threat intelligence, IPS 등

---

NAT와 Firewall은 어떻게 함께 동작하는가

NAT와 Firewall은 같은 장비에서 함께 동작하는 경우가 많다. 하지만 역할은 다르다.

NAT:
주소 변환

Firewall:
허용/차단 판단

예를 들어 private server가 외부 API를 호출한다고 하자.

Private Server: 192.168.0.10
External API:   198.51.100.20:443
NAT Public IP:  203.0.113.5

처리 흐름은 대략 다음과 같다.

1. Server가 외부 API로 packet 생성
2. Firewall policy가 outbound HTTPS를 허용하는지 확인
3. NAT가 source IP를 public IP로 변환
4. Packet이 internet으로 전송
5. 응답 packet이 NAT public IP로 돌아옴
6. NAT table을 보고 내부 server로 되돌림
7. Stateful firewall이 established traffic으로 허용

실제 장비마다 NAT와 firewall policy의 처리 순서가 다를 수 있으므로, 운영에서는 vendor별 packet flow 문서를 확인해야 한다. Conceptual level에서는 정책 판단과 주소 변환이 모두 필요하다는 점이 중요하다.

---

Firewall은 내부와 외부 사이에만 있는 것이 아니다

초기 설명에서는 firewall을 보통 내부 network와 internet 사이에 놓는다.

Internal Network
  ↓
Firewall
  ↓
Internet

하지만 현대 네트워크에서는 firewall이 단순히 내부와 외부 사이에만 있는 것은 아니다. Firewall은 서로 다른 trust level을 가진 network 사이에 배치할 수 있다.

Internet ↔ DMZ
DMZ ↔ Internal Network
User Network ↔ Server Network
Production ↔ Development
Kubernetes Worker ↔ Database Network
VPC A ↔ VPC B
On-premises ↔ Cloud

즉 firewall의 본질은 security domain 사이의 traffic policy enforcement다.

다른 보안 신뢰 수준을 가진 영역 사이에서
어떤 traffic을 허용할지 결정하는 장치

---

DMZ와 Firewall

DMZ는 외부에서 접근해야 하지만 내부 trusted network에는 직접 접근하면 안 되는 server를 배치하는 중간 network다.

Internet
  ↓
Firewall
  ↓
DMZ
  ↓
Firewall
  ↓
Internal Network

예를 들어 web server와 mail gateway는 외부 사용자에게 열려 있어야 할 수 있다.

DMZ
├── Public Web Server
└── Mail Gateway

하지만 database나 internal file server는 DMZ에 두면 안 된다.

Internal Network
├── Database
├── File Server
└── Internal Admin System

DMZ의 목적은 외부 노출이 필요한 시스템이 침해되더라도 내부 network 전체로 바로 확산되지 않도록 blast radius를 줄이는 것이다.

---

NAT를 보안 기능으로 오해하지 않기

NAT는 내부 IP를 외부에 숨기는 효과가 있다. 하지만 NAT 자체를 firewall과 동일시하면 안 된다.

예를 들어 내부 server에 static NAT 또는 port forwarding이 설정되어 있다고 하자.

203.0.113.10:443 → 192.168.0.10:443

이때 firewall rule이 너무 넓게 열려 있으면 외부 사용자는 내부 server에 접근할 수 있다.

NAT mapping 존재
+
Firewall allow 존재
=
외부에서 내부 server 접근 가능

즉 NAT가 있다고 해서 무조건 안전한 것은 아니다. NAT는 주소를 숨기거나 변환할 뿐이고, 실제 접근 허용 여부는 firewall policy가 결정해야 한다.

---

Port Forwarding

Port forwarding은 외부의 특정 public IP/port로 들어온 traffic을 내부 private IP/port로 전달하는 구성이다.

203.0.113.10:443  → 192.168.0.10:443
203.0.113.10:2222 → 192.168.0.20:22

가정용 router에서 게임 서버, NAS, SSH 서버를 열 때 자주 등장하는 개념이다. 운영 환경에서는 port forwarding을 신중하게 사용해야 한다.

주의할 점은 다음과 같다.

• 불필요한 port를 열지 않는다.
• SSH/RDP를 internet 전체에 열지 않는다.
• 가능하면 VPN, bastion, zero trust access를 사용한다.
• port forwarding 대상 server의 patch와 hardening을 유지한다.
• firewall log를 남긴다.
• source IP 제한을 적용한다.
• 외부 공개가 필요한 경우 load balancer 또는 reverse proxy를 우선 고려한다.

---

Inbound와 Outbound 정책

NAT와 firewall을 제대로 이해하려면 inbound와 outbound를 나눠야 한다.

Outbound

Outbound는 내부 host가 외부로 나가는 traffic이다.

Internal Client
  ↓
Firewall/NAT
  ↓
Internet

일반적으로 outbound에는 SNAT/PAT가 사용된다.

192.168.0.10:51524 → 203.0.113.5:40001

보안 관점에서는 outbound도 무조건 열어두면 안 된다. 침해된 내부 server가 외부 C2 server와 통신할 수 있기 때문이다.

Inbound

Inbound는 외부에서 내부로 들어오는 traffic이다.

Internet
  ↓
Firewall/NAT
  ↓
Internal Server

Inbound에는 DNAT, port forwarding, load balancer, reverse proxy가 사용될 수 있다.

보안 관점에서는 inbound는 최소한으로 열어야 한다.

allow 443 to public web endpoint
deny direct access to database
deny SSH from internet

---

Cloud VPC에서의 NAT

Cloud VPC에서도 NAT 개념은 매우 중요하다.

VPC의 private subnet에 있는 VM이나 container는 public IP가 없을 수 있다.

Private Subnet
└── App Server: 10.0.2.10

이 server가 외부 API를 호출하거나 package update를 하려면 internet egress가 필요하다. 하지만 public IP를 직접 붙이고 싶지는 않을 수 있다.

이때 NAT gateway, public gateway, virtual router appliance 같은 구성이 사용된다.

Private App Server
  ↓
NAT Gateway / Public Gateway / VRA
  ↓
Internet

이 구조의 핵심은 다음과 같다.

Private resource는 public inbound를 받지 않음
하지만 outbound internet access는 가능

즉 private subnet의 resource를 직접 public internet에 노출하지 않으면서도 외부로 나가는 traffic은 허용할 수 있다.

---

Kubernetes에서의 NAT

Kubernetes에서도 NAT는 중요한 역할을 한다. 특히 Service, NodePort, LoadBalancer, Pod egress에서 NAT와 유사한 packet rewriting이 일어날 수 있다.

Kubernetes Service는 stable virtual IP를 제공하고, 실제 Pod IP로 traffic을 전달한다.

Client
  ↓
Service ClusterIP
  ↓
Pod IP

iptables 또는 IPVS 기반 kube-proxy는 Service IP로 들어온 traffic을 backend Pod IP로 보내기 위해 destination address를 바꾼다. 이는 개념적으로 DNAT와 연결된다.

Destination:
Service IP:Port
  ↓
Pod IP:Port

Pod가 cluster 밖으로 나갈 때는 SNAT 또는 masquerade가 사용될 수 있다.

Pod IP
  ↓ SNAT/MASQUERADE
Node IP
  ↓
External Network

Kubernetes networking을 이해할 때도 다음 구분은 매우 중요하다.

DNAT:
Service IP → Pod IP

SNAT:
Pod IP → Node IP 또는 egress IP

다만 Kubernetes에서 실제 동작은 CNI plugin, kube-proxy mode, eBPF datapath, cloud provider integration에 따라 달라질 수 있다.

---

NAT와 IPv6

NAT는 IPv4 address 부족 문제와 강하게 연결되어 있다. IPv6에서는 address space가 훨씬 크기 때문에 모든 device에 globally unique address를 줄 수 있다.

따라서 IPv6 환경에서는 IPv4식 NAT 필요성이 줄어든다. 하지만 이것이 firewall이 필요 없다는 뜻은 아니다.

IPv6:
주소는 충분할 수 있음

Firewall:
여전히 필요함

IPv6에서는 host가 public routable address를 가질 수 있기 때문에 오히려 firewall policy가 더 중요해질 수 있다.

즉 IPv6에서의 보안 관점은 다음과 같이 바뀐다.

NAT로 숨긴다
→ firewall과 segmentation으로 통제한다

---

NAT의 한계

NAT는 유용하지만 여러 한계가 있다.

End-to-End Connectivity 약화

인터넷의 원래 모델은 host 간 end-to-end 통신이다. NAT는 중간에서 address와 port를 바꾸기 때문에 end-to-end model을 약화시킨다.

Host A ↔ Host B

중간에 NAT가 있으면:
Host B는 Host A의 실제 private address를 모름

P2P와 실시간 통신 문제

VoIP, video call, online gaming, P2P application은 NAT 때문에 연결이 어려워질 수 있다.

이때 다음 기술이 필요할 수 있다.

STUN
TURN
ICE
UPnP
NAT traversal
hole punching

Protocol 문제

일부 protocol은 payload 안에 IP address나 port 정보를 넣는다. NAT가 IP header만 바꾸면 application payload 안의 주소와 실제 주소가 불일치할 수 있다.

대표적으로 다음 protocol에서 문제가 생길 수 있다.

FTP
SIP
H.323
IPSec 일부 mode

이런 경우 ALG(Application Level Gateway)나 별도 설정이 필요할 수 있다.

로그와 추적성 문제

여러 내부 host가 하나의 public IP를 공유하면 외부에서는 모두 같은 IP로 보인다.

External log:
203.0.113.5 accessed service

하지만 실제 내부 host를 찾으려면 NAT translation log가 필요하다.

203.0.113.5:40001 at 10:01:22
→ 192.168.0.10:51524

따라서 enterprise 환경에서는 NAT log와 timestamp 관리가 중요하다.

---

Firewall Rule 설계 원칙

Firewall rule은 단순히 “열고 닫기”가 아니라 정책 설계다.

좋은 rule은 다음 특성을 가져야 한다.

source가 명확하다.
destination이 명확하다.
port/protocol이 명확하다.
direction이 명확하다.
목적이 설명되어 있다.
만료 또는 검토 주기가 있다.
logging 필요 여부가 정해져 있다.

좋지 않은 rule은 다음과 같다.

allow any any

더 나은 rule은 다음처럼 구체적이다.

allow tcp from lb-sg to app-sg port 8080
allow tcp from app-sg to db-sg port 5432
deny all other inbound traffic

정책 설계 원칙은 다음과 같다.

원칙	설명
Default deny	명시적으로 허용한 traffic만 허용
Least privilege	필요한 source, destination, port만 허용
Segmentation	network zone별로 접근 범위 분리
Logging	중요한 allow/deny event 기록
Rule review	오래된 rule 정리
Change control	rule 변경 이력 관리
Egress filtering	outbound traffic도 제한
Defense in depth	firewall 하나에만 의존하지 않음

---

Troubleshooting 관점

NAT와 Firewall 문제는 증상이 비슷하게 나타난다.

접속이 안 된다.
외부에서는 되는데 내부에서는 안 된다.
내부에서는 되는데 외부에서는 안 된다.
응답이 돌아오지 않는다.
특정 port만 안 된다.
health check가 실패한다.

이때 DNS, route, NAT, firewall, return path, host firewall, application listen 상태를 분리해서 확인해야 한다.

Outbound가 안 되는 경우

Private host가 외부 internet에 접속하지 못한다면 다음을 확인한다.

확인 항목	질문
Route	default route가 NAT/firewall로 향하는가?
SNAT	private IP가 public IP로 변환되는가?
Firewall outbound	destination port가 허용되어 있는가?
Return traffic	stateful return traffic이 허용되는가?
DNS	domain name이 resolve되는가?
NAT table	translation entry가 생성되는가?
Public IP	NAT 장비가 사용할 public IP가 있는가?

Inbound가 안 되는 경우

외부에서 내부 service로 접속이 안 된다면 다음을 확인한다.

확인 항목	질문
Public IP	외부 사용자가 올바른 public IP로 접속하는가?
DNAT	public IP/port가 내부 server로 mapping되는가?
Firewall inbound	해당 source와 port가 허용되어 있는가?
Internal route	내부 server가 응답을 firewall로 되돌려 보내는가?
Server listen	service가 올바른 port에서 listen 중인가?
OS firewall	host 내부 firewall이 막고 있지 않은가?
Asymmetric routing	return path가 다른 장비로 빠지지 않는가?

NAT Table은 있는데 통신이 안 되는 경우

NAT translation entry가 생겼다고 해서 application 통신이 성공했다는 뜻은 아니다.

NAT entry 존재
≠
application 통신 성공

가능한 원인은 다음과 같다.

• firewall이 return traffic을 차단
• 내부 server의 default gateway가 잘못됨
• destination server가 응답하지 않음
• asymmetric routing 발생
• MTU 문제
• application이 localhost에만 bind
• security group 또는 ACL에서 차단

Firewall Rule은 열었는데 안 되는 경우

Firewall rule만 보고 판단하면 안 된다. NAT, route, host firewall, application bind, DNS까지 함께 확인해야 한다.

Firewall allow
+
NAT 없음
=
외부에서 내부 private IP로 도달 불가

또는 다음과 같은 경우도 있다.

DNAT 설정 있음
+
Firewall deny
=
connection blocked

즉 NAT와 Firewall은 함께 봐야 한다.

---

NAT와 Firewall을 구분하는 기준

NAT와 Firewall을 헷갈리지 않으려면 다음 질문으로 구분하면 된다.

주소가 바뀌는가?
→ NAT

traffic 허용 여부를 판단하는가?
→ Firewall

더 구체적으로는 다음과 같다.

질문	관련 기능
private IP를 public IP로 바꾸는가?	NAT
public IP를 internal server로 forwarding하는가?	NAT
source port를 바꿔 connection을 구분하는가?	PAT
특정 source에서 오는 traffic을 허용하는가?	Firewall
특정 port를 차단하는가?	Firewall
established connection의 응답인지 확인하는가?	Stateful Firewall
application payload를 검사하는가?	Application Firewall / NGFW

---

앞선 네트워킹 개념들과의 연결

Load Balancer

Load Balancer 앞뒤에도 NAT와 Firewall이 등장할 수 있다.

Internet
  ↓
Firewall / DNAT
  ↓
Load Balancer
  ↓
Application Servers

또는 cloud에서는 다음처럼 구성할 수 있다.

DNS
  ↓
Public Load Balancer
  ↓
Firewall policy
  ↓
Private App Subnet

Load Balancer는 traffic을 backend로 분산하고, Firewall은 허용할 traffic을 통제하며, NAT는 필요한 경우 주소를 변환한다.

DNS

DNS는 domain name을 public endpoint로 변환한다.

app.example.com → 203.0.113.10

그 public IP 뒤에는 firewall, DNAT, load balancer가 있을 수 있다.

Client
  ↓ DNS
203.0.113.10
  ↓ Firewall / DNAT
192.168.0.10

DNS가 올바른 public IP를 반환하더라도 firewall rule이나 NAT mapping이 잘못되어 있으면 접속은 실패한다.

VPC

VPC에서 private subnet resource는 기본적으로 public internet에서 직접 접근되지 않는 구조로 설계할 수 있다. 외부로 나가야 할 때는 NAT gateway 또는 public gateway 성격의 구성, 들어와야 할 때는 load balancer, floating IP, DNAT, firewall policy가 필요하다.

Private Subnet
  ↓ outbound
NAT Gateway
  ↓
Internet

Internet
  ↓
Load Balancer / DNAT
  ↓
Private Service

Virtual Networking

Virtual networking 환경에서는 NAT와 Firewall도 software-defined resource가 될 수 있다.

Virtual Firewall
Virtual Router
Virtual NAT Gateway
Virtual Load Balancer

이 기능들은 physical appliance가 아니라 VM, managed service, eBPF datapath, SDN rule, cloud control plane으로 구현될 수 있다.

---

자칫 실수하기 쉬운 부분

실수	문제
NAT를 Firewall과 동일시	NAT는 주소 변환이고, 접근 제어는 Firewall policy가 담당
route 없이 NAT만 설정	packet이 올바른 next hop으로 가지 못함
DNAT만 설정하고 inbound rule 누락	public IP로 들어와도 firewall에서 차단
SNAT 없이 private IP로 internet 접근 시도	return traffic이 돌아오지 않음
outbound를 모두 허용	침해된 host의 외부 통신을 통제하기 어려움
NAT table만 보고 통신 성공으로 판단	application, firewall, return path 문제가 남을 수 있음
SSH/RDP port forwarding을 internet 전체에 공개	brute-force와 취약점 공격 표면 증가
Kubernetes Service 동작에서 DNAT/SNAT를 무시	Service, Pod egress, NodePort troubleshooting이 어려워짐

---

정리

NAT와 Firewall은 private network와 public internet 사이에서 자주 함께 동작하지만 역할이 다르다.

항목	정리
NAT	IP address 또는 port를 변환
Firewall	traffic을 rule과 state에 따라 허용 또는 차단
SNAT	outbound traffic의 source address 변환
DNAT	inbound traffic의 destination address 변환
PAT/NAPT	여러 내부 host가 하나의 public IP를 port로 구분해 공유
Stateful Firewall	connection state를 추적해 return traffic 허용
Port Forwarding	public IP/port를 internal IP/port로 전달
Cloud VPC	private subnet의 egress와 public ingress 설계에 NAT/Firewall 사용
Kubernetes	Service traffic과 Pod egress에서 DNAT/SNAT 개념이 중요
운영 주의점	DNS, route, NAT, firewall, return path, host firewall을 함께 확인

NAT는 private network와 public internet 사이에서 address와 port를 변환해 통신을 가능하게 한다. Firewall은 서로 다른 security domain 사이에서 어떤 traffic을 허용할지 결정한다. 두 기능은 함께 동작할 때 private network의 외부 통신과 보안 통제를 동시에 가능하게 하지만, 서로 대체되는 개념은 아니다.