본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.
Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.
이 문서에서는 NAT 환경에서 IP 연결 문제를 해결하는 방법을 설명합니다.
이 문서에 대한 특정 요건이 없습니다.
이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.
이 문서에서는 다음 문제를 해결합니다.
문제가 NAT 작업에 있는지 확인하려면
컨피그레이션을 기반으로 NAT가 달성해야 할 사항을 명확하게 정의합니다. 컨피그레이션에 문제가 있음을 확인할 수 있습니다. NAT 컨피그레이션에 대한 자세한 내용은 Configuring Network Address Translation을 참조하십시오. 시작하기.
변환 테이블에 올바른 변환이 있는지 확인합니다.
show 및 debug 명령을 사용하여 변환이 발생하는지 확인합니다.
패킷에 발생한 상황을 자세히 검토하고 라우터에 패킷을 이동할 올바른 라우팅 정보가 있는지 확인합니다.
이 네트워크 다이어그램에서 라우터 4는 라우터 5(172.16.6.5)를 ping할 수 있지만 라우터 7(172.16.11.7)은 ping할 수 없습니다.
라우터 4에서 라우터 7을 ping할 수 없습니다.
라우팅 프로토콜은 라우터를 실행하지 않습니다. 라우터 4의 기본 게이트웨이는 라우터 6입니다. 라우터 6은 NAT로 구성됩니다.
interface Ethernet0
ip address 172.16.6.6 255.255.255.0
ip directed-broadcast
ip nat outside
!
interface Ethernet1
ip address 10.10.10.6 255.255.255.0
ip nat inside
!
interface Serial2.7 point-to-point
ip address 172.16.11.6 255.255.255.0
ip nat outside
frame-relay interface-dlci 101
!
ip nat pool test 172.16.11.70 172.16.11.71 prefix-length 24
ip nat inside source list 7 pool test
ip nat inside source static 10.10.10.4 172.16.6.14
!
access-list 7 permit 10.10.50.4
access-list 7 permit 10.10.60.4
access-list 7 permit 10.10.70.4
문제 해결 방법:
1. NAT가 올바르게 작동하는지 확인해야 합니다. 컨피그레이션에서 라우터 4 IP 주소(10.10.10.4)가 172.16.6.14로 정적으로 변환됨을 알 수 있습니다. 라우터 6에서 show ip nat translation 명령을 사용하여 변환 테이블에 변환이 존재하는지 확인할 수 있습니다.
router-6#show ip nat translation
Pro Inside global Inside local Outside local Outside global
--- 172.16.6.14 10.10.10.4 --- ---
2. 라우터 4가 IP 트래픽을 소싱할 때 이 변환이 발생하는지 확인합니다. 이 작업은 라우터 6에서 두 가지 방법으로 수행할 수 있으며, NAT 디버그를 실행하거나 show ip nat statistics 명령을 사용하여 NAT 통계를 모니터링할 수 있습니다. debug 명령은 최후의 수단이므로 show 명령으로 시작합니다.
3. 라우터 4에서 트래픽을 수신할 때 증가하도록 카운터를 모니터링합니다. 변환 테이블을 사용하여 주소를 변환할 때마다 카운터가 증가합니다.
4. 통계를 지우고 통계를 표시한 다음 라우터 4에서 라우터 7을 ping한 다음 통계를 다시 표시합니다.
router-6#clear ip nat statistics
router-6#
router-6# show ip nat statistics
Total active translations: 1 (1 static, 0 dynamic; 0 extended)
Outside interfaces:
Ethernet0, Serial2.7
Inside interfaces:
Ethernet1
Hits: 0 Misses: 0
Expired translations: 0
Dynamic mappings:
-- Inside Source
access-list 7 pool test refcount 0
pool test: netmask 255.255.255.0
start 172.16.11.70 end 172.16.11.71
type generic, total addresses 2, allocated 0 (0%), misses 0
router-6#
라우터 4에서 ping 172.16.11.7 명령을 사용하면 라우터 6의 NAT 통계는 다음과 같습니다.
router-6#show ip nat statistics
Total active translations: 1 (1 static, 0 dynamic; 0 extended)
Outside interfaces:
Ethernet0, Serial2.7
Inside interfaces:
Ethernet1
Hits: 5 Misses: 0
Expired translations: 0
Dynamic mappings:
-- Inside Source
access-list 7 pool test refcount 0
pool test: netmask 255.255.255.0
start 172.16.11.70 end 172.16.11.71
type generic, total addresses 2, allocated 0 (0%), misses 0
show 명령을 통해 적중 수가 5만큼 증가했음을 확인할 수 있습니다. Cisco 라우터에서 ping을 성공하면 적중 횟수가 10회 증가합니다. 소스 라우터(라우터 4)가 전송한 5개의 ICMP(Internet Control Message Protocol) 에코가 변환되며, 총 10개의 히트를 위해 목적지 라우터(라우터 7)의 패킷에 대한 5개의 에코 응답을 변환해야 합니다. 에코 응답이 변환되지 않거나 라우터 7에서 전송되지 않으므로 5개의 적중 횟수가 손실됩니다.
라우터 7이 에코 응답 패킷을 라우터 4로 보내지 않는 이유를 찾을 수 있는지 확인하십시오. NAT가 패킷에 대해 수행하는 작업을 검토하십시오. 라우터 4는 소스 주소가 10.10.10.4이고 목적지 주소가 172.16.11.7인 ICMP 에코 패킷을 전송합니다. NAT가 발생한 후 라우터 7에서 수신한 패킷의 소스 주소는 172.16.6.14이고 목적지 주소는 172.16.11.7입니다. 라우터 7은 172.16.6.14에 응답해야 하며, 172.16.6.14는 라우터 7에 직접 연결되지 않으므로 응답하려면 이 네트워크에 대한 경로가 필요합니다. 라우터 7의 라우팅 테이블을 확인하여 경로가 존재하는지 확인합니다.
router-7#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 4 subnets
C 172.16.12.0 is directly connected, Serial0.8
C 172.16.9.0 is directly connected, Serial0.5
C 172.16.11.0 is directly connected, Serial0.6
C 172.16.5.0 is directly connected, Ethernet0
라우터 7 라우팅 테이블에 172.16.6.14에 대한 경로가 없음을 확인할 수 있습니다. 이 경로를 추가하면 ping이 작동합니다. show ip nat statistics 명령을 사용하여 NAT 통계를 모니터링하는 데 유용합니다. 여러 변환이 있는 좀 더 복잡한 NAT 환경에서는 이 show 명령이 더 이상 유용하지 않습니다. 그런 다음 라우터에서 디버그를 실행할 수 있습니다.
이 문제에서 라우터 4는 라우터 5와 라우터 7을 모두 ping할 수 있지만 10.10.50.0 네트워크의 디바이스는 라우터 5나 라우터 7과 통신할 수 없습니다. 네트워크 다이어그램은 다음과 같습니다.
네트워크가 라우터와 통신할 수 없음
interface Ethernet0
ip address 172.16.6.6 255.255.255.0
ip directed-broadcast
ip nat outside
media-type 10BaseT
!
interface Ethernet1
ip address 10.10.10.6 255.255.255.0
ip nat inside
media-type 10BaseT
!
interface Serial2.7 point-to-point
ip address 172.16.11.6 255.255.255.0
ip nat outside
frame-relay interface-dlci 101
!
ip nat pool test 172.16.11.70 172.16.11.71 prefix-length 24
ip nat inside source list 7 pool test
ip nat inside source static 10.10.10.4 172.16.6.14
!
access-list 7 permit 10.10.50.4
access-list 7 permit 10.10.60.4
access-list 7 permit 10.10.70.4
NAT의 예상 동작을 설명합니다. 라우터 6의 컨피그레이션에서 NAT는 10.10.50.4를 NAT 풀 "test"의 첫 번째 사용 가능한 주소로 동적으로 변환해야 합니다. 풀은 주소 172.16.11.70과 172.16.11.71로 구성됩니다. 이 문제에서 라우터 5와 7이 수신하는 패킷의 소스 주소는 172.16.11.70 또는 172.16.11.71입니다. 이러한 주소는 라우터 7과 동일한 서브넷에 있으므로 라우터 7에 직접 연결된 경로가 있어야 하지만 아직 경로가 없는 경우 라우터 5에 서브넷에 대한 경로가 필요합니다.
show ip route 명령을 사용하여 라우터 5 라우팅 테이블에 172.16.11.0이 나열되는지 확인할 수 있습니다.
router-5#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 4 subnets
C 172.16.9.0 is directly connected, Serial1
S 172.16.11.0 [1/0] via 172.16.6.6
C 172.16.6.0 is directly connected, Ethernet0
C 172.16.2.0 is directly connected, Serial0
show ip route 명령을 사용하여 라우터 7 라우팅 테이블에 직접 연결된 서브넷으로 172.16.11.0이 나열되는지 확인할 수 있습니다.
router-6#show ip nat translation
Pro Inside global Inside local Outside local Outside global
--- 172.16.6.14 10.10.10.4 --- ---
--- 172.16.11.70 10.10.50.4 --- ---
NAT 변환 테이블을 확인하고 필요한 변환이 존재하는지 확인합니다. 원하는 변환이 동적으로 생성되므로 먼저 적절한 주소에서 제공된 IP 트래픽을 전송해야 합니다. 10.10.50.4에서 172.16.11.7로 전송되는 보낸 ping 후 라우터 6의 변환 테이블은 다음과 같습니다.
router-6#show ip nat translation
Pro Inside global Inside local Outside local Outside global
--- 172.16.6.14 10.10.10.4 --- ---
--- 172.16.11.70 10.10.50.4 --- ---
예상 변환은 변환 테이블에 있으므로 ICMP 에코 패킷이 적절하게 변환된다는 것을 알 수 있습니다. 한 가지 옵션은 NAT 통계를 모니터링할 수 있지만 복잡한 환경에서는 유용하지 않다는 것입니다. 또 다른 옵션은 NAT 라우터(라우터 6)에서 NAT 디버깅을 실행하는 것입니다. 10.10.50.4에서 172.16.11.7로 향하는 ping 소스를 보내는 동안 라우터 6에서 디버그 ip nat를 실행할 수 있습니다. 디버그 결과는 다음 코드 예에 나와 있습니다.
참고: 라우터에서 debug 명령을 사용할 때 라우터를 오버로드하여 작동 불가능하게 만들 수 있습니다. 항상 각별한 주의를 기울여야 하며, 가능하면 Cisco 기술 지원 엔지니어의 감독 없이 중요한 생산 라우터에서 디버그를 실행하지 마십시오.
:
router-6# show log
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: level debugging, 39 messages logged
Monitor logging: level debugging, 0 messages logged
Buffer logging: level debugging, 39 messages logged
Trap logging: level informational, 33 message lines logged
Log Buffer (4096 bytes):
05:32:23: NAT: s=10.10.50.4->172.16.11.70, d=172.16.11.7 [70]
05:32:23: NAT*: s=172.16.11.7, d=172.16.11.70->10.10.50.4 [70]
05:32:25: NAT*: s=10.10.50.4->172.16.11.70, d=172.16.11.7 [71]
05:32:25: NAT*: s=172.16.11.7, d=172.16.11.70->10.10.50.4 [71]
05:32:27: NAT*: s=10.10.50.4->172.16.11.70, d=172.16.11.7 [72]
05:32:27: NAT*: s=172.16.11.7, d=172.16.11.70->10.10.50.4 [72]
05:32:29: NAT*: s=10.10.50.4->172.16.11.70, d=172.16.11.7 [73]
05:32:29: NAT*: s=172.16.11.7, d=172.16.11.70->10.10.50.4 [73]
05:32:31: NAT*: s=10.10.50.4->172.16.11.70, d=172.16.11.7 [74]
05:32:31: NAT*: s=172.16.11.7, d=172.16.11.70->10.10.50.4 [74]
이전 디버그 출력에서 볼 수 있듯이, 첫 번째 줄은 172.16.11.70으로 변환된 소스 주소 10.10.50.4를 표시합니다. 두 번째 줄은 172.16.11.70의 대상 주소가 10.10.50.4로 다시 변환됨을 표시합니다. 이 패턴은 나머지 디버그에서 반복됩니다. 이는 라우터 6이 패킷을 양방향으로 변환함을 의미합니다.
검토:
1. 라우터 4는 10.10.50.4에서 소싱하여 172.16.11.7로 향하는 패킷을 전송합니다.
2. 라우터 6은 패킷에 대해 NAT를 수행하고 패킷이 172.16.11.70의 소스와 172.16.11.7의 대상으로 전달됩니다.
3. 라우터 7은 172.16.11.7의 소스와 172.16.11.70의 대상으로 응답을 보냅니다.
4. 라우터 6은 패킷에 NAT를 수행하여 소스 주소 172.16.11.7 및 목적지 주소 10.10.50.4의 패킷을 생성합니다.
5. 라우터 6은 라우터 6 라우팅 테이블의 정보를 기반으로 패킷을 10.10.50.4로 라우팅합니다. 라우터 6의 라우팅 테이블에 필요한 경로가 있는지 확인하려면 show ip route 명령을 사용해야 합니다.
router-6#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 5 subnets
C 172.16.8.0 is directly connected, Serial1
C 172.16.10.0 is directly connected, Serial2.8
C 172.16.11.0 is directly connected, Serial2.7
C 172.16.6.0 is directly connected, Ethernet0
C 172.16.7.0 is directly connected, Serial0
10.0.0.0/24 is subnetted, 1 subnets
C 10.10.10.0 is directly connected, Ethernet1
이 체크리스트를 사용하여 일반적인 문제를 해결하십시오.
변환 테이블에 적절한 변환이 설치되지 않은 경우 다음을 확인합니다.
올바른 변환 항목이 변환 테이블에 설치되어 있지만 사용되지 않는 경우 다음을 확인합니다.
연결 문제 해결:
즉, 포트 80에 대한 NAT 변환이 작동하지 않지만 다른 포트에 대한 변환은 정상적으로 작동합니다.
이 문제를 해결하려면
try later 오류 메시지는 NAT와 관련된 show 명령 또는 show running-config 또는 write memory 명령이 실행될 때 나타납니다. 이는 NAT 테이블의 크기 증가로 인해 발생합니다. NAT 테이블의 크기가 커지면 라우터의 메모리가 부족합니다.
호스트는 수백 개의 변환을 전송할 수 있으며, 이는 높은 CPU 사용량을 초래합니다. 즉, 테이블을 너무 크게 만들어서 CPU가 100%로 실행되도록 할 수 있습니다. ip nat translation max-entries 300 명령은 호스트당 300개 제한 또는 라우터의 총 변환 양을 생성합니다. 해결 방법은 ip nat translation max-entries all-hosts 300 명령을 사용하는 것입니다.
이 메시지는 동일한 포트에서 수신 대기하는 하나의 공용 IP 주소에 대해 두 개의 내부 IP 주소를 구성하려고 할 때 나타납니다.
% X.X.X.X already mapped (172.30.62.101 -> X.X.X.X)
이를 수정하려면 공용 IP 주소가 2개의 내부 IP 주소를 갖도록 구성하고 DNS에서 2개의 공용 IP 주소를 사용합니다.
이는 no-alias
옵션을 제공합니다. 이 no-alias
옵션은 라우터가 주소에 응답하지 않으며 ARP 항목을 설치하지 않음을 의미합니다. 다른 라우터가 NAT 풀을 연결된 서브넷의 주소로 구성된 내부 전역 풀로 사용하는 경우 라우터가 해당 주소에 대한 ARP(Address Resolution Protocol) 요청에 응답할 수 있도록 해당 주소에 대한 별칭이 생성됩니다. 그러면 라우터에 위조된 주소에 대한 ARP 항목이 생성됩니다.
이 오류 메시지는 정보 메시지일 뿐이며 디바이스의 정상적인 동작에는 영향을 주지 않습니다.
Bad token 0, wanted TOK_NUMBER|TOK_PUNCT
이 오류는 NAT가 FTP가 열려 있는 주소의 레이어 4 수정을 시도하고 패킷에서 변환해야 하는 IP 주소를 찾을 수 없음을 의미합니다. 메시지에 토큰이 포함된 이유는 변환에 필요한 세부 정보를 찾기 위해 IP 패킷에서 토큰 또는 기호 집합을 검색하면 패킷의 IP 주소가 검색되기 때문입니다.
FTP 세션이 시작되면 명령 채널과 데이터 채널의 두 채널을 협상합니다. 둘 다 포트 번호가 다른 IP 주소입니다. FTP 클라이언트와 서버는 파일을 전송할 두 번째 데이터 채널을 협상합니다. 제어 채널을 통해 교환되는 패킷은 "PORT,i,i,i,i,p,p" 형식을 갖습니다. 여기서 i,i,i,i는 IP 주소의 4바이트이며 p,p는 포트를 지정합니다. NAT는 이 패턴과 일치하고 필요한 경우 주소/포트를 변환하려고 시도합니다. NAT는 두 채널 체계를 모두 변환해야 합니다. NAT는 변환이 필요한 포트 명령을 찾을 때까지 명령 스트림에서 번호를 검사합니다. 그런 다음 변환을 구문 분석하여 동일한 형식으로 계산합니다.
패킷이 손상되었거나 FTP 서버 또는 클라이언트에 잘못된 형식의 명령이 있는 경우 NAT는 변환을 제대로 계산할 수 없으며 해당 오류를 생성합니다. 두 채널을 모두 시작하도록 FTP 클라이언트를 "passive"로 설정할 수 있습니다.
관련 정보
개정 | 게시 날짜 | 의견 |
---|---|---|
2.0 |
05-Jul-2022 |
재인증 |
1.0 |
14-Nov-2001 |
최초 릴리스 |