imbizcorp

네트워크 인프라 이해하기 · 제3부 · 다른 네트워크와 인터넷으로는 어떻게 나갈까

공유기에 연결된 여러 PC는 공인 IP 주소 하나로 어떻게 인터넷을 사용할까

사설 주소의 의미부터 PAT Mapping, 반환 트래픽, 상태 경계와 포트 전달 진단까지

BY 주식회사 아이엠비즈니스플랫폼 PUB 2026-07-24 UPD 2026-10-26 READ 약 14분 VERIFY 표준·공식 자료 대조 $ myip$ cidr$ subnet

사설 IP를 사용하는 PC의 패킷은 인터넷으로 나갈 때 외부에서 회신할 수 있는 공인 주소와 포트로 바뀝니다. 경계 장비는 변환 전후 값을 NAT/PAT 매핑으로 남겨 두었다가 응답이 오면 원래 내부 PC를 찾습니다. 이 글에서는 한 통신의 왕복을 따라가며 주소·포트의 변화와 NAT, Connection Tracking, Stateful 방화벽이 각각 맡는 일을 구분합니다.

인터넷에서 찾을 수 없는 사설 주소로 어떻게 외부 서버와 통신할 수 있을까↑

RFC 1918은 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16을 사설 IPv4 공간으로 둡니다. 여러 조직이 같은 주소를 재사용하므로 인터넷 전체에서 10.0.0.25만 보고 한 호스트를 고를 수 없습니다.

전통적인 IPv4 인터넷 접속에서는 경계 장비가 사설 출발지와 조직의 공인 주소 사이에 대응 관계를 만듭니다. 사설 주소 자체가 보안 기능인 것은 아니며, 전용망이나 VPN 안에서는 주소가 겹치지 않는다면 NAT 없이 라우팅할 수도 있습니다.

두 회사가 모두 10.0.0.25를 사용해도 각자의 내부 라우팅 문맥에서는 문제가 없습니다. 그러나 인터넷의 라우터가 10.0.0.25를 어느 회사로 보내야 하는지 나타내는 전역 Route는 없습니다. 인터넷 접속 패킷이 경계를 나갈 때 조직에 도달 가능한 공인 Source로 바뀌어야 서버가 응답을 돌려보낼 수 있습니다. NAT는 이 서로 다른 주소 영역 사이에 대응 관계를 만드는 한 방법입니다.

반드시 모든 사설망 통신에 NAT가 필요한 것은 아닙니다. 본사와 지사가 겹치지 않는 RFC 1918 Prefix를 VPN과 Route로 연결했다면 사설 주소를 그대로 전달할 수 있습니다. 반대로 공인 주소를 사용해도 정책상 NAT를 적용할 수 있습니다. 주소 종류와 변환 여부, 방화벽 허용 여부는 각각 다른 결정입니다. 이 세 가지를 분리해야 “사설 IP라서 안전하다”거나 “NAT가 없어서 Route가 안 된다”는 잘못된 결론을 피할 수 있습니다.

NAT의 직접적인 책임은 헤더 값을 변환하고 되돌릴 대응 관계를 유지하는 것입니다. 이것만으로 사용자를 인증하거나 악성 트래픽을 판별하지는 않습니다. 사설 주소가 외부에서 바로 보이지 않는 현상과 방화벽 정책이 통신을 허용하는 판단은 결과가 비슷해 보여도 서로 다른 기능이므로, 설계와 장애 분석에서 분리해 기록해야 합니다.

이 절의 근거 IETF RFC 1918

공인 IP 하나를 여러 통신이 함께 쓰려면 PAT가 포트까지 구분해야 한다↑

NAT는 IP 주소를 다른 주소로 매핑하는 기능의 넓은 이름입니다. Basic NAT는 주소 중심의 대응 관계를 만들고, NAPT 또는 PAT는 TCP·UDP 포트나 ICMP 식별자 같은 Transport Identifier까지 사용해 여러 통신이 공인 주소를 공유하게 합니다.

대표적인 주소 변환의 차이
방식주요 대응용도
Static NAT고정된 내부·외부 주소예측 가능한 1:1 대응
Dynamic NAT내부 주소와 공인 주소 Pool사용 시점의 주소 할당
PAT/NAPT주소와 Transport Identifier여러 통신의 공인 주소 공유

제품은 SNAT, Hide NAT, Masquerade처럼 다른 이름을 사용할 수 있습니다. 이름보다 어느 방향의 어떤 필드를 바꾸고 어떤 항목을 남기는지 확인합니다.

내부 PC 두 대가 동시에 같은 서버 203.0.113.20:443에 접속한다고 해 보겠습니다. 첫 흐름은 10.0.0.25:51514, 둘째는 10.0.0.26:51514에서 시작할 수 있습니다. 공인 IP 하나만 Source로 쓰면 바깥에서 두 흐름을 구분할 추가 값이 필요합니다. PAT 장비는 예를 들어 각각 198.51.100.8:40001과 198.51.100.8:40002로 매핑해 응답의 목적지 포트를 구분 기준으로 만듭니다.

TCP와 UDP의 포트 공간은 프로토콜과 함께 구분하므로 같은 포트 번호라도 서로 다른 매핑을 만들 수 있습니다. ICMP Echo에는 TCP·UDP 포트가 없어서 구현에 따라 Identifier 같은 값을 구분 기준으로 사용합니다. Endpoint-Independent Mapping과 Address and Port-Dependent Mapping의 차이, 그리고 Filtering 동작의 차이는 P2P·VoIP 애플리케이션의 도달 가능성에도 영향을 줍니다. 따라서 “PAT는 포트를 바꾼다”에서 멈추지 말고 어떤 프로토콜 값까지 대응 관계에 포함하는지, 외부 통신 상대(Endpoint)를 얼마나 제한하는지 확인해야 합니다.

장비는 충돌이 없다면 내부 Source 포트를 그대로 보존할 수도 있고, 이미 사용 중이거나 정책상 필요하면 다른 포트를 고를 수도 있습니다. 그러므로 PAT를 거치면 항상 포트가 바뀐다고 단정할 수 없습니다. 또한 외부 상대 주소까지 매핑 Key에 포함하는지, 같은 내부 Tuple을 다른 목적지에도 재사용하는지는 장비의 NAT 방식과 설정에 따라 달라집니다.

이 절의 근거 IETF RFC 3022 · IETF RFC 4787

밖으로 나가는 첫 패킷에서 내부 값과 공인 값을 하나의 매핑으로 묶는다↑

내부 단말 10.0.0.25:51514가 서버 203.0.113.20:443에 TCP 연결을 시작한다고 가정합니다. 경계 장비는 공인 주소 198.51.100.8과 사용할 외부 포트 40001을 선택할 수 있습니다.

변환 전  TCP 10.0.0.25:51514      → 203.0.113.20:443
    변환 후  TCP 198.51.100.8:40001   → 203.0.113.20:443

장비는 이 관계를 NAT Translation 항목에 남기고 IP·TCP 헤더를 바꾼 뒤 필요한 Checksum을 조정합니다. 다만 PAT를 사용해도 외부 포트 번호가 내부 포트 번호와 같을 수 있습니다.

새 SYN이 NAT 정책과 Route를 통과하면 장비는 사용 가능한 공인 Tuple을 찾고 Translation Entry를 만듭니다. 항목에는 내부 쪽 Source, 외부에서 보일 Source, Destination, 프로토콜과 생성·마지막 사용 시각 같은 정보가 들어갈 수 있습니다. 구현에 따라 Destination을 조회 Key 또는 부가 상태로 다루는 방식은 다르지만, 운영자는 안쪽과 바깥쪽 Tuple을 한 Entry에서 연결할 수 있어야 합니다.

포트 보존이 가능하면 장비는 내부 51514를 외부에서도 유지할 수 있습니다. 이미 같은 공인 Tuple이 사용 중이거나 정책상 다른 Pool을 써야 하면 40001 같은 값을 고릅니다. 패킷 헤더를 바꾼 뒤 IPv4 헤더 Checksum과 TCP·UDP가 계산하는 의사 헤더 관련 Checksum도 일관되게 조정해야 합니다. 단, IPv4 UDP의 체크섬 값이 0이면 0을 그대로 유지합니다. 캡처에서 변환 전후 패킷을 비교할 때는 주소·포트뿐 아니라 TCP Sequence Number와 Flag를 함께 봐야 같은 패킷임을 확인할 수 있습니다.

이 Entry는 단순 로그가 아니라 반환 변환에 쓰이는 현재 상태입니다. 생성 시각, 마지막 사용 시각, 프로토콜 상태와 Timeout이 구현에 따라 함께 기록됩니다. 장애 분석에서는 안쪽 캡처와 바깥쪽 캡처의 주소가 다르다는 사실을 오류로 보지 말고, Flag·Sequence·시각과 Translation 값을 묶어 같은 통신 흐름인지 확인합니다.

이 절의 근거 IETF RFC 3022 · IETF RFC 7857

돌아온 응답의 공인 IP·포트만 보고 원래 내부 PC를 어떻게 찾아낼까↑

서버 응답의 목적지는 198.51.100.8:40001입니다. 경계 장비는 이 값과 프로토콜, 통신 상대 같은 구현별 조회 정보를 이용해 기존 NAT Mapping을 찾습니다. 일치하는 항목이 있으면 Destination IP·포트를 10.0.0.25:51514로 다시 바꾸어 내부로 전달합니다.

매핑이 만료되거나 장비 재시작으로 사라졌다면 늦게 온 응답을 어느 내부 통신으로 보낼지 결정하지 못할 수 있습니다. UDP와 TCP의 항목 유지 방식, Endpoint 매핑, Filtering 동작과 Timeout은 표준 요구사항과 제품 구현을 함께 확인해야 합니다.

응답 SYN-ACK의 Destination 198.51.100.8:40001은 공유기 자신의 서비스 포트가 아니라 기존 내부 흐름을 가리키는 공인 쪽 Tuple입니다. 장비가 매핑을 찾으면 Destination을 10.0.0.25:51514로 바꾸고 내부 Route와 Neighbor 정보를 사용해 PC로 보냅니다. 같은 공인 IP를 쓰는 다른 PC는 다른 외부 포트와 연결되어 있으므로 이 응답을 받지 않습니다. “공인 IP 하나로 여러 PC를 구분”하는 핵심이 이 조회에 있습니다.

기존 매핑이 없는 외부 패킷만으로는 원래 내부 목적지를 알아낼 수 없습니다. 장비 자체 서비스, Static DNAT 또는 포트 전달 규칙이 없다면 보통 이 패킷은 폐기되지만, 이를 NAT 자체의 보안 정책이라고 부르지는 않습니다. 타임아웃 직후 도착한 UDP 응답, 장비에 장애 전환이 일어나면서 상태가 사라진 통신 흐름, L4 정보가 모든 조각에 들어 있지 않은 IP Fragment는 구현별 차이가 드러나는 사례입니다. 장애 때는 항목의 생성·마지막 사용·만료 시각을 패킷 시각과 대조해야 합니다.

Entry가 Timeout으로 사라졌거나 장애 조치 후 새 장비에 동기화되지 않았다면 같은 응답이 와도 복원할 근거가 없습니다. 이때 라우팅 테이블에 내부 대역이 있고 방화벽 정책이 허용이어도 세션은 이어지지 않을 수 있습니다. 따라서 반환 실패는 공인 인터페이스에 패킷이 도착했는지, Translation 조회가 성공했는지, 복원된 패킷의 내부 Route가 있는지 순서대로 나눠 봅니다.

이 절의 근거 IETF RFC 3022 · IETF RFC 7857

한 장비에 보이는 NAT Translation Table, Session Table과 State Table은 각각 무엇을 기록할까↑

한 장비가 주소 변환과 Stateful 방화벽을 함께 수행하면 관리 화면에서 NAT Mapping, 연결 항목과 방화벽의 정책 상태가 서로 연결되어 보일 수 있습니다. 그래도 논리적 질문은 다릅니다. NAT Mapping은 어떤 주소·포트를 무엇에 대응시켰는지, 방화벽 상태는 이 방향의 패킷을 정책상 허용할지를 답합니다.

일부 구현은 하나의 세션 구조에 두 정보를 함께 저장하고, 다른 구현은 NAT Translation Table, Session Table과 State Table을 나눕니다. 따라서 “NAT가 TCP Connection 상태를 항상 직접 관리한다”거나 “NAT가 곧 방화벽이다”라고 일반화하지 않습니다.

한 TCP SYN이 들어왔을 때 NAT 기능은 변환할 Tuple을 정하고, Connection Tracking 기능은 SYN·SYN-ACK·ACK 같은 흐름 진행을 기록하며, 방화벽 정책은 이 패킷과 방향을 허용할지 결정할 수 있습니다. 제품은 이 정보를 하나의 세션 화면에 합쳐 보여 주기도 합니다. 화면 한 줄이라는 이유로 세 기능의 생성 조건, Timeout과 삭제 원인이 같다고 가정하면 장애 분석에서 중요한 차이를 놓칩니다.

High Availability에서도 무엇을 동기화하는지 따로 확인해야 합니다. 설정된 Static NAT만 Standby에 복제되고 동적 Translation이나 방화벽 상태는 복제되지 않으면 장비 전환 후 기존 세션이 끊길 수 있습니다. 반대로 세션 상태가 공유되어도 새 장비의 Return Route와 Neighbor 정보가 준비되지 않으면 패킷은 전달되지 않습니다. 운영 문서에는 테이블 이름보다 어떤 필드와 수명이 동기화되고, 전환 시험에서 기존 흐름과 새 흐름이 각각 어떻게 되는지 기록해야 합니다.

고가용성 장비에서는 설정 동기화와 상태 동기화도 구분해야 합니다. NAT Rule이 대기 장비에 있어도 활성 Translation과 TCP 상태가 넘어가지 않으면 기존 연결은 재설정될 수 있습니다. 제조사별 테이블 이름보다 장애 전환 시 실제로 어떤 상태가 복제되는지를 시험 결과로 남기는 편이 정확합니다.

이 절의 근거 IETF RFC 4787 · IETF RFC 7857

도해에서 확인할 내용 본문과 다른 주소를 쓰는 예시입니다. Outbound·Reply 패킷 화살표의 5-Tuple에서 192.168.10.25:51514와 198.51.100.20:40001의 대응을 비교합니다. 가운데 NAT Translation Entry의 응답 조회 키와 아래 세 상자의 역할을 읽고, 세션/Conntrack 정보와 방화벽 상태가 구현상 별도일 수 있다는 경계를 구분합니다.

↔ 도해는 좌우로 움직여 볼 수 있습니다.

도해 1. PAT 양방향 Header Rewrite와 Translation·Session·Firewall State의 경계 내부 TCP 5-Tuple이 PAT Mapping으로 공인 IP와 Port를 할당받고, Reply Packet이 Reverse Lookup으로 원래 Host에 돌아오는 과정과 NAT Translation Table, Session 또는 Conntrack Table, Stateful Firewall State가 구현상 구분될 수 있음을 보이는 그림 [도해 1. PAT 양방향 Header Rewrite와 Translation·Session·Firewall State의 경계] Inside Host 192.168.10.25:51514 VRF blue · inside zone NAT / PAT Engine Allocate 198.51.100.20:40001 Rewrite Header · Recalculate IP/TCP Checksum Outside Server 203.0.113.80:443 TCP peer TCP 192.168.10.25:51514 → 203.0.113.80:443 TCP 198.51.100.20:40001 → 203.0.113.80:443 TCP 203.0.113.80:443 → 198.51.100.20:40001 TCP 203.0.113.80:443 → 192.168.10.25:51514 NAT Translation Entry — 예시 (실제 Key와 Column은 구현·Mapping Mode에 따라 달라짐) ProtocolTCP Inside Local192.168.10.25:51514 Inside Global198.51.100.20:40001 VRF / Zoneblue / inside Outside Global203.0.113.80:443 Reverse MappingTCP + 198.51.100.20:40001 (+ peer/zone) TimerProtocol·Policy별 Aging Reply Match 후 Dst IP·Dst Port를 Inside Local로 Rewrite하고 Checksum을 다시 계산한 뒤 LAN Route/Adjacency를 조회한다. NAT Translation Table Address·Port Mapping과 Aging Static / Dynamic / PAT Rule 결과 Packet Header Rewrite의 근거 Session / Conntrack Table 5-Tuple·Direction·Timer·TCP 관측 상태 NAT Entry와 연결될 수 있으나 별도 객체일 수 있음 구현에 따라 노출 방식과 명칭이 다름 Stateful Firewall State Policy Match·Direction·Allow/Drop 상태 NAT와 같은 장비여도 같은 기능은 아님 NAT와 Firewall은 서로 다른 기능이다 도해의 한 Packet 흐름이 실제 장비에서는 Mapping, Lookup Key, Timer와 서로 다른 State Store의 관계로 구현된다.

외부에서 먼저 접속하거나 NAT를 두 번 거치면 왜 조건이 더 필요할까↑

내부에서 시작한 PAT 항목은 그 흐름의 응답을 되돌립니다. 외부 사용자가 먼저 내부 서버에 접속하려면 공인 주소·포트를 내부 목적지에 연결하는 DNAT 또는 포트 전달 규칙과 별도의 방화벽 허용이 필요합니다.

DNAT 규칙이 공인 198.51.100.8:8443을 내부 10.0.0.50:443에 연결한다면 외부 SYN의 Destination이 경계에서 바뀝니다. 그 뒤 방화벽 정책, 내부 Route와 서버의 LISTEN 포트가 모두 맞아야 합니다. 서버의 응답도 같은 경계를 지나 기존 매핑을 사용해야 외부 클라이언트가 198.51.100.8:8443에서 온 응답으로 인식합니다. DNAT 한 줄은 End-to-End 공개 절차 전체가 아닙니다.

Hairpin NAT에서는 내부 클라이언트가 공인 주소로 접속하므로 Source와 Destination 양쪽을 변환해야 Return Path가 다시 NAT 장비를 지나는 구성이 필요할 수 있습니다. CGNAT에서는 가입자 공유기 바깥에 통신사 Translation이 하나 더 있어 가입자 공유기의 설정만으로는 상위 매핑을 만들 수 없습니다. 이 경우 포트 Control 프로토콜 같은 지원 여부, 공인 IPv4 옵션, IPv6와 Reverse Proxy·VPN 같은 대안을 검토합니다. 상위 NAT 유무를 살피는 단서로 WAN 주소와 외부 관찰 주소를 비교합니다. 주소 비교만으로 NAT 단계 수를 확정할 수는 없습니다.

가정용 NAT 뒤에 통신사 CGNAT가 있으면 변환을 두 번 거칩니다. 이때 가정 장비의 포트 전달만 설정해도 통신사 공인 주소에 대한 인바운드 매핑은 생기지 않습니다. VPN, SIP, 일부 P2P처럼 Endpoint 정보나 인바운드 연결에 의존하는 서비스는 이중 NAT와 짧은 Timeout의 영향을 받을 수 있으므로 각 경계의 공인 주소·Translation·제어 권한을 따로 확인합니다.

이 절의 근거 IETF RFC 6598 · IETF RFC 6888

포트 전달이 안 될 때는 주소 변환과 방화벽 허용을 따로 확인한다↑

상황: NAS 포트 전달을 설정했지만 외부에서 접속되지 않습니다.

  1. 공유기 WAN 주소와 외부에서 관찰한 공인 주소가 같은지 비교합니다.
  2. WAN 주소가 100.64.0.0/10이거나 두 값이 다르면 상위 NAT 존재 여부를 확인합니다.
  3. DNAT의 외부 포트, 내부 IP·포트와 서버의 Default Gateway가 맞는지 확인합니다.
  4. NAT Hit와 방화벽 허용·차단 로그를 별도로 봅니다.
  5. 외부 네트워크에서 다시 시험하고 요청과 응답을 양쪽에서 캡처합니다.

CGNAT 환경이면 통신사의 공인 IP 옵션, IPv6 공개 또는 인증된 VPN·중계 방식을 검토합니다.

세 지점의 Tuple을 표로 만들면 원인을 빠르게 좁힐 수 있습니다. 외부 클라이언트 쪽, NAT의 외부 인터페이스, 내부 서버 쪽에서 같은 시각의 Source·Destination IP·포트와 TCP Flag를 기록합니다. 외부 인터페이스에 들어온 SYN이 내부 서버에 도착하지 않으면 NAT 정책·내부 Route·방화벽을 봅니다. 내부 서버가 SYN을 받아 SYN-ACK을 보냈는데 외부 인터페이스에 응답이 없다면 매핑 조회·상태와 반환 Route를 봅니다. 한 지점의 패킷만으로 변환 성공과 허용 성공을 동시에 판정하지 않습니다.

운영 Log에는 공인 Tuple만 남기지 말고 내부 Tuple, 프로토콜, 시작·종료 시각과 장비 식별자를 보존해야 여러 사용자가 공유한 주소를 추적할 수 있습니다. Clock Synchronization이 틀리거나 포트 정보가 빠지면 공인 IP 하나만으로 원래 클라이언트를 찾기 어렵습니다. 변경 뒤에는 새 세션과 기존 세션을 나누어 시험하고, Translation Entry·방화벽 Hit·서버 Log가 같은 흐름을 가리키는지 재검증합니다.

이 순서면 “NAT 문제”라는 넓은 표현을 패킷 미도착, Rule 불일치, 정책 거부, 내부 전달 실패, Return Path 또는 상태 손실로 좁힐 수 있습니다. 성공 시험도 외부에서 새 세션을 만들고 안쪽·바깥쪽 Tuple과 응답을 함께 저장해야 재현 가능한 근거가 됩니다.

이 절의 근거 IETF RFC 3022 · IETF RFC 7857 · IETF RFC 6888

도해에서 확인할 내용 본문과 다른 주소·포트를 쓰는 예시입니다. 외부 TCP 8080 포트 접속이 DNAT Rule과 매핑을 거쳐 내부 서버로 전달되고, 응답의 출발지가 다시 공인 주소로 바뀌는 흐름을 봅니다. 요청 목적지의 198.51.100.78:8080 → 192.168.1.80:8080 변환과 응답 출발지의 공인 주소 복원 설명을 비교합니다.

↔ 도해는 좌우로 움직여 볼 수 있습니다.

도해 2. 포트포워딩(DNAT): 밖에서 걸려온 접속을 안쪽 서버로 넘겨주기DNAT(포트포워딩): 외부 클라이언트의 공인 IP:포트 접속을 공유기가 규칙에 따라 내부 사설 서버로 목적지 변환하고, 응답은 세션 기록으로 자동 Reverse Mapping[도해 2] 포트포워딩(DNAT): 밖에서 걸려온 접속을 안쪽 서버로 넘겨주기 1. 외부 클라이언트 (203.0.113.99)접속 시도: 198.51.100.78:8080 (공인 IP:포트)외부에서는 공인 주소만 안다2. 공유기 DNAT 엔진 (포트포워딩 규칙 매칭)규칙: WAN TCP 8080 ➔ 192.168.1.80:8080Dst 변환: 198.51.100.78:8080 ➔ 192.168.1.80:8080세션 기록 ➔ 응답은 같은 기록으로 자동 Reverse Mapping3. 내부 서버 (192.168.1.80:8080) 수신✓ 응답의 출발지는 공인 198.51.100.78:8080 으로 복원되어 나간다 DNAT(포트포워딩): 외부 클라이언트의 공인 IP:포트 접속을 공유기가 규칙에 따라 내부 사설 서버로 목적지 변환하고, 응답은 세션 기록으로 자동 Reverse Mapping

FAQ↑

NAT를 사용하면 외부 공격이 자동으로 차단되나요?
아닙니다. 변환과 접근 제어는 다른 기능입니다. 기존 매핑이 없는 패킷이 전달되지 않을 수는 있지만 방화벽 정책과 서비스 보안은 별도로 설계해야 합니다.
공인 IP 하나의 연결 수는 항상 약 6만 개인가요?
항상 그렇지 않습니다. 포트 공간은 제약 중 하나지만 목적지·프로토콜별 재사용, 공인 주소 수, 구현별 항목 한도와 Timeout을 함께 봐야 합니다.
IPv6에서도 IPv4처럼 NAT가 필수인가요?
아닙니다. IPv6 전역 주소는 종단 간 라우팅할 수 있으며 접근 제어는 방화벽이 담당합니다. 특수한 변환 기술이 있지만 IPv4 주소 공유와 같은 이유로 NAT를 전제하지 않습니다.

용어사전↑

이 글에서 쓴 핵심 용어 목록이며, 각 용어의 풀이는 전체 용어 사전에서 확인할 수 있습니다.

NAT Network Address Translation
PAT Port Address Translation
SNAT Source NAT
DNAT Destination NAT
NAT Translation
State Table
Hairpin NAT
CGNAT Carrier-Grade NAT
Checksum

출처와 검증

  1. IETF RFC 1918 — IPv4 사설 주소 공간
  2. IETF RFC 3022 — Traditional NAT와 NAPT의 변환 단계
  3. IETF RFC 4787 — UDP Unicast NAT 동작 요구사항
  4. IETF RFC 7857 — TCP·UDP·ICMP NAT 동작 요구사항 갱신
  5. IETF RFC 6598 — CGNAT 공유 주소 100.64.0.0/10
  6. IETF RFC 6888 — Carrier-Grade NAT 공통 요구사항

예시 공인 주소는 RFC 5737 문서 대역입니다. NAT 항목의 실제 키·이름·Timeout과 방화벽 상태의 결합 방식은 장비와 버전에 따라 다릅니다.

← 이전 글라우터는 여러 경로 중 패킷을 보낼 길을 어떻게 고를까다음 글 →정적 라우팅은 먼 곳의 장애를 어떻게 감지하고 백업 경로로 전환할까