Day 9: 네트워크 프로토콜들

1. 학습 요약

주제	요약
Telnet vs SSH	네트워크 장비 원격 접속 시 SSH는 암호화된 안전한 방식, Telnet은 평문이라 보안에 취약
HTTP vs HTTPS	HTTPS는 암호화를 통해 웹 통신을 보호, HTTP는 보안이 없는 일반 통신
NETCONF vs RESTCONF	네트워크 장비 자동화를 위한 API, NETCONF는 XML 기반, RESTCONF는 REST/JSON 기반
TCP/UDP 포트	서비스 식별용 번호, 충돌 방지를 위해 고유한 포트 지정
DHCP	IP 주소를 자동으로 할당해주는 클라이언트-서버 기반 프로토콜
DNS	도메인 이름을 사람이 읽을 수 있는 형태로 변환해주는 시스템
SNMP	네트워크 장비의 상태를 모니터링하고 관리하기 위한 프로토콜
NTP	네트워크 장비 간 정확한 시간 동기화를 위해 사용되는 프로토콜
NAT	사설 IP를 공인 IP로 변환하여 인터넷 통신을 가능하게 하는 기술

2. 이론 내용

1) 네트워크 프로토콜

1. Telnet과 SSH

- Telnet과 SSH는 모두 원격 컴퓨터에 접속하여 로그인할 수 있도록 해주는 프로토콜이다.

- Telnet은 암호화가 적용되지 않아 보안에 취약하기 때문에 오늘날에는 거의 사용되지 않으며,

비생산 환경(예: 실습)에서만 사용하는 것이 좋다.

- SSH는 데이터 전송 시 암호화를 적용하며, 인증 방식으로 공개 키를 사용할 수 있다.

사용자 이름과 비밀번호를 네트워크로 직접 보내는 방식보다 안전하다.

- SSH는 네트워크 장비, 클라우드 서버, 컨테이너 접속 등에서 많이 사용된다.

기본 포트 번호:

• SSH: 22번
• Telnet: 23번 (또는 TLS/SSL 환경에서는 992번)

2. HTTP와 HTTPS

• HTTP와 HTTPS는 웹 브라우저에서 인식하는 웹 접속용 프로토콜이다.
• HTTPS는 TLS나 SSL을 사용하여 암호화된 연결을 제공한다.
• 웹 브라우저의 주소창에서 http:// 또는 https://로 구분할 수 있다.
• 일부 브라우저는 ssh:// 또는 ftp:// 등의 프로토콜도 지원하여 원격 서버에 연결할 수 있다.

3. NETCONF와 RESTCONF

• NETCONF와 RESTCONF는 네트워크 장비(예: Cisco 라우터)를 관리하기 위한 프로토콜이다.
• NETCONF는 포트 830번을 사용한다.
• RESTCONF는 고정된 포트 번호가 없지만, 일반적으로 8000번 대 포트를 많이 사용한다.

4. 포트 충돌 방지와 TCP/UDP 포트 개념

• 다양한 네트워크 작업이 동시에 수행될 수 있기 때문에, 각 프로토콜은 고유한 기본 포트를 가져야 하며 표준을 준수해야 충돌을 피할 수 있다.
• TCP와 UDP 트래픽에서는 목적지 포트를 반드시 지정해야 하며, 출발지 포트는 전송 장치가 자동으로 생성한다.
• 시스템 포트 범위는 0~1023번이며, 이 외의 포트도 경우에 따라 사용될 수 있다.

5. 주요 프로토콜 및 포트 정리

포트 번호	프로토콜
22	SSH
23, 992	Telnet
53	DNS
80	HTTP
443	HTTPS (HTTP over TLS or SSL)
830	NETCONF
8008, 8080, 8888	RESTCONF

 

 

2) DHCP

네트워크에 연결된 모든 장비는 통신을 위해 IP 주소가 필요하다. 이 IP 주소를 하나하나 수동으로 설정하는 것은 번거롭고 시간이 많이 소모된다. 이러한 문제를 해결하기 위해 설계된 것이 바로 DHCP(Dynamic Host Configuration Protocol)이다. DHCP는 클라이언트/서버 모델 기반으로 동작하며, DHCP 서버가 클라이언트에게 IP 주소 및 네트워크 구성 정보를 자동으로 할당한다.

DHCP 서버는 IP 주소뿐 아니라 DNS 서버 주소, 기본 게이트웨이 주소 등 추가적인 구성 정보도 함께 제공할 수 있다. 예를 들어, Cisco 무선 액세스 포인트는 DHCP 요청에서 Option 43을 사용해 무선 LAN 컨트롤러(WLC)의 IP 주소를 받아올 수 있다.

 

DHCP의 장점

• 클라이언트 구성 작업 감소 및 비용 절감: 장비에 직접 접근해 수동 설정할 필요 없이 원격에서 자동으로 구성 가능. ISP의 경우, 고객의 모뎀(케이블, DSL 등)에 IP를 원격 할당 가능.
• 중앙 집중식 관리: DHCP 서버 하나로 여러 서브넷의 설정을 관리할 수 있어, 전체 네트워크 설정 변경 시 한 곳에서 조정 가능.

DHCP 주소 할당 방식

1. 자동 할당: 클라이언트에게 영구적인 IP 주소 할당
2. 동적 할당: 일정 기간(리스 타임) 동안 임시 IP 주소 할당
3. 수동 할당: 관리자가 특정 IP 주소를 클라이언트에 할당하고, DHCP 서버가 이를 전달

DHCP의 작동 방식

DHCP 서버는 클라이언트가 속한 서브넷을 파악한 뒤, 해당 서브넷의 주소 풀에서 IP를 할당한다. DNS나 기본 게이트웨이 주소는 일반적으로 서브넷 단위로 동일하게 구성된다.

• IPv4 DHCP 표준: RFC 2131, RFC 2132
• IPv6 DHCP 표준: RFC 3315 (기본), RFC 3633 (Prefix delegation), RFC 3736 (SLAAC 포함)

※ IPv6 DHCP에서는 기본 게이트웨이 주소를 제공하지 않으며, 해당 정보는 Router Advertisement(RA) 메시지를 통해 전달됨.

 

DHCP 릴레이 (Relay Agent)

DHCP 서버와 클라이언트가 서로 다른 서브넷에 위치할 경우, DHCP 릴레이 에이전트를 사용한다. 릴레이 에이전트는 클라이언트의 DHCP 메시지를 서버로 전달하고, 서버의 응답을 다시 클라이언트에게 전달하는 역할을 한다.

• 클라이언트 → 서버: 포트 67 사용
• 서버 → 클라이언트: 포트 68 사용

DHCP의 주요 메시지 (IPv4 기준)

1. DHCPDISCOVER: 클라이언트가 DHCP 서버를 찾기 위해 브로드캐스트 전송
2. DHCPOFFER: 서버가 IP 주소 제안 (유니캐스트 응답)
3. DHCPREQUEST: 클라이언트가 특정 서버의 제안을 수락하며 브로드캐스트로 요청
4. DHCPACK: 서버가 요청을 승인하고 최종 IP 할당 완료 (유니캐스트)

Q.  DHCPREQUEST는 왜 브로드캐스트로 보내는지?

! DHCP 서버가 여러 대일 수 있다

1. 클라이언트가 DHCPDISCOVER를 브로드캐스트로 보내면,
2. 네트워크 상에 있는 여러 DHCP 서버가 각각 DHCPOFFER를 클라이언트에게 보낼 수 있다.(이 때 Offer는 보통 유니캐스트로 전송됨.)
3. 클라이언트는 그 중 하나의 Offer를 선택하고, 그 선택을 명시적으로 알릴 필요가 있음.

! 그럼에도 "왜 브로드캐스트로 보내야 하냐?"

클라이언트는 자신이 수락한 Offer의 서버에만 응답할 목적이 있지만, 브로드캐스트로 보내는 이유는 다음과 같다:

1. 선택하지 않은 다른 DHCP 서버들에게 통보하기 위해

• DHCPREQUEST를 브로드캐스트로 보내면, 선택되지 않은 다른 DHCP 서버들도 이 메시지를 받고 나서 자신이 제안했던 IP를 반환할 수 있다.
• 즉, 자원을 회수할 수 있는 기회를 주는 것.
• 만약 클라이언트가 유니캐스트로만 요청하면, 다른 서버는 클라이언트가 자기 제안을 수락했는지 알 수 없다. 그럼 그 IP를 계속 유지하거나 충돌이 생길 수도 있음.

2. 아직 클라이언트의 IP가 정해지지 않았기 때문에

• DHCPREQUEST를 보낼 그 순간, 클라이언트는 아직 IP 주소를 공식적으로 할당받지 않은 상태야.
• 그러므로 유니캐스트 통신을 위한 정상적인 IP 스택이 작동하지 않을 수도 있다.
• 그래서 일단 브로드캐스트로 보내는 것이 안전한 기본 방식.

※ 경우에 따라 DHCPNAK(거부) 메시지가 응답되면 재시작이 필요하며, 리스 갱신 시 DHCPREQUEST로 갱신 진행됨.

 

DHCPv6의 주요 메시지

• SOLICIT, ADVERTISE, INFORMATION REQUEST, REPLY

DHCP 서버의 주요 역할

• IP 주소의 유일성 보장 (중복 할당 방지)
• ISP 환경에서도 널리 사용되며, 고객 장비에 동적으로 IP를 할당함

3) DNS

네트워크에서 장치는 숫자 형태의 IP 주소를 통해 데이터를 주고받는다. 하지만 숫자 주소는 기억하기 어렵기 때문에, 사람이 이해하기 쉬운 이름(도메인)을 사용하는 것이 일반적이다. 이 도메인 이름을 IP 주소로 변환해주는 프로토콜이 바로 DNS(Domain Name System)다.

예를 들어, http://www.cisco.com은 198.133.219.25와 같은 실제 IP 주소를 대신해 사용된다. 만약 Cisco가 서버의 IP 주소를 변경하더라도 도메인 이름은 그대로 유지되기 때문에 사용자는 이를 알 필요 없이 서비스를 계속 이용할 수 있다.

※ 참고: 198.133.219.25를 웹 브라우저 주소창에 직접 입력해도 www.cisco.com 웹사이트에 접속할 수는 없다.

DNS는 쿼리, 응답, 오류 처리, 레코드 전달 등 모든 작업에 대해 동일한 DNS 메시지 형식을 사용한다.

 

DNS 메시지 구성 요소 

DNS Message	SectionDescription
Question	어떤 이름을 변환할 것인가?
Answer	해당 이름의 IP 주소 등
Authority	권한 서버 정보
Additional	추가 정보

 

주요 레코드 종류

• A: 최종 장비의 IPv4 주소
• AAAA: 최종 장비의 IPv6 주소 (Quad-A)
• NS: 권한 있는 네임서버 정보
• MX: 메일 서버(Mail Exchange) 정보

클라이언트가 DNS 서버에 이름 질의를 하면, 서버는 먼저 자신의 레코드에 해당 이름이 있는지 확인하고, 없을 경우 다른 DNS 서버와 통신하여 해당 이름을 해석한다. 결과를 찾으면 이를 클라이언트에 전달하고, 해당 응답은 일정 시간 동안 캐시되어 동일한 요청이 반복될 때 응답 속도를 높여준다.

Windows PC에서는 ipconfig /displaydns 명령어로 로컬에 캐시된 DNS 항목들을 확인할 수 있다.

DNS 계층 구조 DNS는 계층적이고 분산된 구조로 되어 있으며, 각 DNS 서버는 전체 도메인 중 일부 영역(zone)에 대한 정보만을 관리한다. 다음은 DNS의 계층 구조 개념이다:

• 루트 도메인: 모든 도메인의 최상위에 위치
• Top-Level Domain (TLD): .com, .org, .edu, .au, .co 등 조직 종류나 국가를 나타냄
• Second-Level Domain: 예: cisco.com
• 하위 도메인: 예: www.cisco.com, ftp.cisco.com, mail.cisco.com

각 서버는 자신이 담당하는 영역 밖의 질의가 들어오면 해당 요청을 다른 적절한 DNS 서버로 전달하며, 이 구조 덕분에 DNS는 대규모로 확장 가능한 구조를 유지할 수 있다.

Top-Level Domain 예시

• .com: 기업
• .org: 비영리 단체
• .au: 오스트레일리아
• .co: 콜롬비아

※ 전체 TLD 목록은 "list of top-level domains"로 검색하면 확인할 수 있다.

 

4) SNMP

SNMP(Simple Network Management Protocol)은 서버, 라우터, 스위치, 방화벽 등 네트워크 장비들을 효율적으로 모니터링하고 관리하기 위해 만들어진 애플리케이션 계층 프로토콜이다. 네트워크 관리자들은 SNMP를 통해 네트워크 성능을 확인하고, 문제를 감지하며, 향후 확장을 계획할 수 있다.

 

SNMP 버전

• SNMPv1: 거의 사용되지 않음
• SNMPv2c: 64비트 성능 모니터링 지원, 기능 추가
• SNMPv3: 보안 기능 강화 (인증, 암호화, 무결성 제공)

SNMP 구성 요소

1. SNMP Manager: 네트워크 관리 시스템(NMS)의 일부로, 장비의 상태를 수집하고 명령을 전송함
2. SNMP Agent: 네트워크 장비에서 동작하며, 장비 정보를 MIB에 저장하고 매니저의 요청에 응답함
3. MIB(Management Information Base): 관리되는 장비의 정보 객체들을 계층 구조로 정리한 데이터베이스

SNMP 동작 방식

• get 요청: 매니저가 에이전트에게 정보 요청
• set 요청: 매니저가 장비의 설정 변경을 요청
• trap: 에이전트가 비정상 상황이나 이벤트 발생 시 매니저에게 자발적으로 알림

SNMP Polling (폴링 방식)

• NMS는 주기적으로 SNMP 에이전트에게 get 요청을 보내 트래픽 부하, 장비 상태 등을 모니터링한다.
• 이 데이터를 기반으로 평균, 최대값, 임계값 초과 알림 등을 GUI로 표현 가능하다.
• 예: Cisco 라우터의 CPU 사용률을 주기적으로 수집 후 그래프로 표현

SNMP Trap (트랩 방식)

• 폴링 방식의 단점 (지연, 대역폭 소모)을 보완하기 위해 에이전트가 이벤트 발생 즉시 매니저에게 알리는 방식
• 트랩 예시: 링크 다운, 장비 재시작, 인증 실패, MAC 주소 변화 등

SNMP 커뮤니티 문자열

 

SNMPv1, v2c에서는 Agent가 평문(plaintext) 비밀번호인 "커뮤니티 문자열"을 통해 Manager의 MIB 접근 권한 제어

• Read-only(ro): 조회만 가능
• Read-write(rw): 조회 및 변경 모두 가능

보안을 위해 기본 커뮤니티명(public, private)은 변경하거나 제거하고, 접근 제어 리스트로 IP 제한 권장

 

MIB (Management Information Base)

 

SNMP에서 관리되는 모든 장비 요소들을 트리 구조로 표현한 사전

각 데이터 항목은 OID (Object Identifier)라는 고유 번호로 구분됨

• 예: CPU 온도, 인터페이스 트래픽, 팬 속도 등

매니저가 get 요청 시 OID를 포함한 패킷을 보내고, 에이전트는 OID에 해당하는 값을 찾아 응답함

MIB를 컴파일하면 장비별 세부 항목을 확인할 수 있음

 

SNMP 메시지 종류

메시지 종류	설명
Get	특정 변수의 값 조회 요청
GetNext	다음 변수의 값 조회 요청
GetResponse	에이전트가 get 요청에 대한 응답 제공
Set	변수 값을 변경하거나 동작을 실행하는 요청
Trap	이벤트 발생 시 에이전트가 매니저에게 비동기 알림 전송

 

트랩은 다음 정보를 포함함:

• 이벤트 식별 OID
• 이벤트 심각도 (예: critical, major, minor 등)
• 타임스탬프

 

보안 참고사항

• SNMPv1/v2c는 인증 및 암호화가 없으므로, 중요한 환경에서는 SNMPv3를 사용하거나 접근 제어 필수
• 사용하지 않는 경우 SNMP를 비활성화하거나, ACL을 설정해 접근을 제한하는 것이 바람직함

5) NTP(Network Time Protocol)

NTP의 필요성

정확한 시간 동기화는 네트워크와 시스템 인프라의 원활한 운영에 필수적이다. 네트워크, 서버, 스토리지 등 모든 IT 인프라가 사업 성공의 핵심이 된 오늘날에는, 시간 불일치나 장애가 SLA 위반, 서비스 중단, 심하면 기업의 손실이나 도산으로 이어질 수 있다.

 

SLA 위반(SLA Violation)이란?

SLA에서 정의된 성능 지표가 충족되지 않았을 때 발생하는 문제.
예를 들어:

• 약속된 다운타임 허용 한도를 초과
• 응답 시간을 SLA 이하로 제공하지 못함
• 가용성 기준 불이행

시스템 클럭

• 시스템 클럭은 OS 부팅 시 작동하며, 장비의 날짜와 시간을 추적한다.
• 대부분의 장비는 배터리로 작동되는 하드웨어 클럭을 갖고 있어 재부팅 후에도 시간을 유지한다.
• 시스템 클럭은 UTC 기준이며, 로컬 시간대나 일광 절약 시간 설정도 가능하다.

UTC(협정 세계시, Coordinated Universal Time)는 전 세계에서 사용하는 표준 시간 기준. 우리가 흔히 쓰는 한국 표준시(KST), 일본 표준시(JST), 태평양 표준시(PST) 같은 것들은 전부 UTC를 기준으로 몇 시간 더하거나 빼서 결정.

 

NTP 개요

• NTP(Network Time Protocol)은 신뢰된 시간 소스로부터 장비가 시간을 받아 로컬 클럭의 드리프트를 보정하는 프로토콜
• UDP 포트 123 사용
• 최신 버전은 NTPv4 (RFC 5905)
• 동기화 네트워크를 형성하여 여러 장비가 정확한 시간에 접근 가능

NTP 계층 (Stratum)

0	GPS, 원자시계 등 물리적 시간원 (직접 연결 불가)
1	Stratum 0에 직접 연결된 서버 (Primary NTP Server)
2	Stratum 1 서버로부터 동기화된 서버
3~15	상위 Stratum 서버에서 연속적으로 동기화됨
16	동기화되지 않은 상태 (Unsynchronized)

• 장비는 기본적으로 가장 낮은 stratum 서버를 우선 선택합니다.
• 3개 이상의 NTP 서버와 동기화하여 정확성과 안정성을 판단합니다.

동작 방식

• 클라이언트는 여러 서버에 폴링하며, 지연시간/정확도 등을 고려해 최적의 서버를 선택
• 1분에 1회 정도의 트랜잭션만으로도 동기화 가능
• 일반적으로 WAN 환경에서는 10ms, LAN 환경에서는 1ms 수준의 정확도 도달

NTP 보안

방법	설명
ACL 제어	NTP 요청을 허용할 IP 주소를 ACL로 제한
Key 기반 인증	공유 비밀키를 설정하여 서버 진위 확인

R1(config)# ntp authenticate
R1(config)# ntp authentication-key 1 md5 cisco123
R1(config)# ntp trusted-key 1
R1(config)# ntp server 192.168.1.10 key 1

• 신뢰되지 않는 서버는 동기화하지 않음
• outlier(정상 범위 벗어난 시간)의 서버도 동기화 대상에서 제외
• 보안 기능
  • ACL을 통한 접근 제어
  • 암호화 인증 사용 권장

NTP 모드

 

1. Client/Server 모드

• 가장 일반적인 방식
• 클라이언트가 서버로부터 시간 요청, 서버는 응답
• 서버는 클라이언트에게 시간을 제공만 하며 요청하지 않음

2. Symmetric Active/Passive 모드

• 주로 동일 stratum의 서버 간 사용
• 상호 백업 기능 제공
• active로 설정된 장비가 passive 장비와 연결되며, 필요 시 시간 제공 가능

3. Broadcast/Multicast 모드

• 동일 서브넷 내에서 단방향으로 시간 전달
• 클라이언트는 브로드캐스트 메시지를 수신하여 동기화
• 정확도는 낮지만 구성 간단

NTP 설정 명령어

 

기본 설정

R1(config)# ntp server 192.168.1.10 prefer
R1(config)# ntp server 192.168.1.11
R1(config)# ntp server 192.168.1.12
R1(config)# ntp update-calendar
R1(config)# clock timezone KST 9

• prefer: 가장 우선적으로 사용할 서버 지정
• ntp update-calendar: 하드웨어 클럭(RTC)도 업데이트
• clock timezone: 지역 시간대 설정 (예: KST는 +9)

Broadcast 모드

R1(config)# ntp broadcast
R1(config)# interface GigabitEthernet0/1
R1(config-if)# ntp broadcast

 

Client 설정

• 별도 ntp client 명령어는 없으며, ntp server 명령어로 설정 시 자동으로 클라이언트 역할 수행

Peer (대칭 모드)

R1(config)# ntp peer 192.168.1.20

 

 

NTP 동기화 상태 확인 명령어

명령어	설명
show clock	현재 시각 확인 (로컬 시계 기준)
show ntp status	NTP 동기화 상태, stratum 등 확인
show ntp associations	연결된 NTP 서버 목록, 지연(latency), 신뢰도 확인
debug ntp events	실시간 NTP 동작 디버깅 (운용 시 주의 필요)

 

NTP 신뢰성 검증

클라이언트는 다음 기준으로 서버의 신뢰도를 판단함:

• 인증 여부
• 서버 시간의 범위 이상 여부
• 오래된 데이터 사용 방지
• 네트워크 지연에 따른 불안정성 판단

조건 중 하나라도 실패 시 해당 서버는 신뢰 불가(insane) 상태로 간주됨

 

구성 권장 사항

• 각 클라이언트는 3개 이상의 low-stratum 서버와 연동
• 일부 서버에 문제가 있어도 나머지 서버로 안정적인 시간 유지
• redundancy를 고려한 트리 구조 구성

 

6) NAT

1. NAT 개요

IPv4 주소는 2^32개(약 43억 개)로 한정되어 있음

이 주소 고갈 문제를 해결하기 위해 NAT(Network Address Translation) 사용

NAT는 내부의 다수 장비가 하나 혹은 소수의 공인 IPv4 주소를 공유하여 인터넷과 통신하게 해줌

주요 기능:

• 사설 IP와 공인 IP 간 주소 변환
• 외부에서 내부 네트워크 구조를 숨김으로써 간접적인 보안 효과
• RFC 1918 사설 주소(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)를 공인 IP로 변환하여 통신 가능하게 함

2. NAT 구성 요소 정의

• Inside: NAT 대상이 되는 내부 네트워크
• Outside: 외부 네트워크(인터넷)
• Local: 내부망에 존재하는 주소
• Global: 외부망에 나타나는 주소

3. NAT 주소 유형

• Inside Local: 내부 호스트가 사용하는 사설 IP 주소
• Inside Global: NAT 장비가 외부에 광고하는 공인 IP 주소
• Outside Local: NAT 장비 기준 외부 호스트의 로컬 주소 (거의 사용되지 않음)
• Outside Global: 외부 호스트의 실제 공인 IP 주소

4. NAT 동작 방식 - Inside Source Address Translation

내부 호스트(예: 10.1.1.1)가 외부 호스트(Host B)와 통신 요청

NAT 장비가 NAT 테이블 확인:

• static NAT 매핑 있으면 그대로 사용
• 없다면 dynamic NAT로 처리: 공인 IP 풀에서 주소 할당 후 매핑

• 외부 응답 시, NAT 장비가 Inside Global 주소를 Inside Local로 변환하여 전달

5. NAT 유형

1) Static NAT

• 1:1 매핑 (예: 10.1.1.1 <-> 203.0.113.10)
• 고정 IP가 필요한 서버 등에서 사용

R1(config)# interface g0/0
R1(config-if)# ip address 192.168.1.1 255.255.255.0
R1(config-if)# ip nat inside

R1(config)# interface g0/1
R1(config-if)# ip address 203.0.113.1 255.255.255.0
R1(config-if)# ip nat outside

R1(config)# ip nat inside source static 192.168.1.10 203.0.113.10

 

2) Dynamic NAT

• 사설 IP 풀과 공인 IP 풀을 동적으로 매핑
• 공인 IP 풀 소진 시 새로운 세션 불가

R1(config)# access-list 1 permit 192.168.1.0 0.0.0.255

R1(config)# ip nat pool MYPOOL 203.0.113.100 203.0.113.110 netmask 255.255.255.0

R1(config)# ip nat inside source list 1 pool MYPOOL

 

3) PAT (Port Address Translation, 오버로딩)

• 여러 사설 IP를 하나의 공인 IP에 포트 번호 기반으로 매핑
• TCP/UDP 포트 정보를 활용해 세션 구분
• 가장 일반적인 홈/소규모 네트워크 NAT 방식

R1(config)# access-list 1 permit 192.168.1.0 0.0.0.255

R1(config)# ip nat inside source list 1 interface g0/1 overload

 

4) NAT 동작 확인 및 모니터링 명령어

명령어	설명
show ip nat translations	현재 NAT 변환 테이블 확인
show ip nat statistics	NAT 통계 (히트 수, 변환 수, 사용된 풀 등) 확인
clear ip nat translation *	모든 변환 테이블 초기화 (필요 시)
debug ip nat	NAT 동작을 실시간으로 디버깅

 

6. PAT 동작 흐름 예시

• Host A(10.1.1.1)와 Host B가 모두 203.0.113.20을 통해 외부와 통신함
• NAT 장비는 포트 번호를 기준으로 내부 세션을 구분하여 NAT 테이블 관리
• 외부 서버는 같은 공인 IP로부터 온 요청으로 인식하지만, 실제 내부 호스트는 다름

7. IPv6에서의 NAT

• IPv6는 충분한 주소 공간 제공으로 NAT 필요성 감소
• 단, NAT64는 IPv6-only ↔ IPv4-only 네트워크 간 통신 위해 사용
• IPv6의 ULAs(Unique Local Addresses)는 내부 통신용으로 사용되며 보안 목적 아님

8. NAT의 장점 및 유의사항

• 공인 IP 절약
• ISP 변경이나 내부 구조 변경 시 유연성 확보
• 완전한 보안 솔루션은 아니며, 보안 강화는 방화벽 등 별도 구성 필요

요약: NAT는 IPv4 주소 부족 문제 해결을 위한 핵심 기술로, 내부 사설 IP를 외부 공인 IP로 매핑하여 인터넷과의 통신을 가능하게 하며, 그 방식은 Static, Dynamic, PAT 세 가지로 분류됨. IPv6에서는 기본적으로 NAT를 필요로 하지 않으나, IPv4와의 상호운용을 위한 NAT64는 예외적으로 사용됨.