NAT 작업 확인 및 기본 NAT 트러블슈팅

소개

NAT 환경에서 IP 연결 문제가 있는 경우 문제의 원인을 확인하기 어려운 경우가 많습니다. 실제로 근본적인 문제가 있는 경우 NAT가 잘못 비난을 받는 경우가 많습니다. 이 문서에서는 Cisco 라우터에서 사용 가능한 툴을 사용하여 NAT 작업을 확인하는 방법을 보여 줍니다. 이 문서에서는 기본 NAT 트러블슈팅을 수행하는 방법과 NAT 트러블슈팅을 수행할 때 일반적인 실수를 방지하는 방법을 보여줍니다.

사전 요구 사항

요구 사항

이 문서에 대한 특정 요건이 없습니다.

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.

NAT를 제외하는 방법

IP 연결 문제의 원인을 확인하려고 시도하면 NAT를 제외하는 데 도움이 됩니다. NAT가 예상대로 작동하는지 확인하려면 다음 단계를 수행하십시오.

1. 컨피그레이션에 따라 NAT가 달성해야 할 사항을 명확하게 정의합니다. 이 시점에서 구성에 문제가 있음을 확인할 수 있습니다. NAT 구성에 대한 도움말은 Configuring Network Address Translation(네트워크 주소 변환 구성)을 참조하십시오. 시작하기.

2. 변환 테이블에 올바른 변환이 있는지 확인합니다.

3. show 및 debug 명령을 사용하여 변환이 발생하는지 확인합니다.

4. 패킷에 발생하는 상황을 자세히 검토하고 라우터에 패킷을 이동할 올바른 라우팅 정보가 있는지 확인합니다.

다음은 문제의 원인을 파악하는 데 도움이 되는 몇 가지 샘플 문제입니다.

샘플 문제: 한 라우터를 다른 라우터는 ping할 수 없음

이 네트워크 다이어그램에서 라우터 4는 라우터 5(172.16.6.5)을 ping할 수 있지만 라우터 7(172.16.11.7)은 ping할 수 없습니다.

어떤 라우터에서도 라우팅 프로토콜이 실행되고 있지 않으며, 라우터 4에는 기본 게이트웨이로 라우터 6이 있습니다. 라우터 6은 다음과 같은 방법으로 NAT로 구성됩니다.

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가 올바르게 작동하는지 확인합니다. 컨피그레이션에서 라우터 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         ---                ---

이제 라우터 4가 IP 트래픽을 소싱할 때 이 변환이 발생하는지 확인합니다. 라우터 6에서 두 가지 방법으로 이 작업을 수행할 수 있습니다. NAT 디버그를 실행하거나 show ip nat statistics 명령을 사용하여 NAT 통계를 모니터링하여 제공합니다. debug 명령은 항상 마지막 수단으로 사용해야 하므로 show 명령으로 시작합니다.

여기서는 적중 카운터를 모니터링하여 라우터 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개의 에코 응답 패킷도 변환해야 합니다. 5개의 누락된 적중 수는 에코 응답이 변환되지 않거나 라우터 7에서 전송되지 않기 때문일 가능성이 높습니다.

라우터 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이 정상적으로 작동합니다.

문제 요약

먼저 NAT가 무엇을 이루어야 하는지 정의했습니다. 다음으로, 변환 테이블에 고정 NAT 항목이 있고 정확한지 확인했습니다. NAT 통계를 모니터링하여 변환이 실제로 발생했음을 확인했습니다. 문제가 발견되어 라우터 7의 라우팅 정보를 확인하게 되었는데, 라우터 7에서 라우터 4의 내부 전역 주소로 가는 경로가 필요하다는 것을 알게 되었습니다.

이 간단한 랩 환경에서 show ip nat statistics 명령을 사용하여 NAT 통계를 모니터링하는 것이 좋습니다. 그러나 여러 번역이 수행되는 보다 복잡한 NAT 환경에서는 이 show 명령은 더 이상 유용하지 않습니다. 이 경우 라우터에서 디버그를 실행해야 할 수 있습니다. 다음 문제 시나리오에서는 debug 명령을 사용하는 방법을 보여 줍니다.

샘플 문제: 외부 네트워크 장치가 내부 라우터와 통신할 수 없음

이 시나리오에서는 라우터 4가 라우터 5 및 라우터 7을 모두 ping할 수 있지만, 10.10.50.0 네트워크의 디바이스는 라우터 5 또는 라우터 7과 통신할 수 없습니다(테스트 랩에서는 루프백 인터페이스에서 IP 주소 10.10.50.4을 사용하여 ping을 소싱하여 이를 에뮬레이트했습니다.) 네트워크 다이어그램을 참조하십시오.

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 명령을 사용하여 Router 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 명령을 사용하여 Router 7 라우팅 테이블에 직접 연결된 서브넷으로 172.16.11.0이 나열되는지 확인할 수 있습니다.

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, 5 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
S       172.16.6.0 [1/0] via 172.16.11.6

이제 NAT가 무엇을 해야 하는지 명확하게 표시했으므로 올바르게 작동하는지 확인해야 합니다. 먼저 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의 출처 주소를 표시합니다. 두 번째 라인은 10.10.50.4으로 다시 변환되는 172.16.11.70의 목적지 주소를 표시합니다. 이 패턴은 디버그의 나머지 부분 전체에서 반복됩니다. 이렇게 하면 라우터 6에서 패킷을 양방향으로 변환하고 있음을 알 수 있습니다.

이제 무엇이 일어나고 있는지 정확하게 자세히 검토합니다. 라우터 4는 172.16.11.7으로 향하는 10.10.50.4에서 소싱된 패킷을 전송합니다. 라우터 6은 패킷에 NAT를 수행하고 172.16.11.70의 소스와 172.16.11.7의 대상으로 패킷을 전달합니다. 라우터 7은 172.16.11.7의 소스와 172.16.11.70의 대상으로 응답을 전송합니다. 라우터 6은 패킷에 NAT를 수행하므로 소스 주소 172.16.11.7 및 대상 주소 10.10.50.4의 패킷이 생성됩니다. 이 경우 라우터 6은 라우팅 테이블에 있는 정보를 기반으로 패킷을 10.10.50.4으로 라우팅해야 합니다. show ip route 명령을 사용하여 라우터 6에 라우팅 테이블에 필요한 경로가 있는지 확인해야 합니다.

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

문제 요약

먼저 NAT가 무엇을 이루어야 하는지 명확하게 정의했습니다. 둘째, 변환 테이블에 필요한 번역이 존재함을 확인했습니다. 셋째, debug 또는 show 명령을 사용하여 변환이 실제로 수행되고 있음을 확인했습니다. 마지막으로, 패킷에 발생한 상황과 라우터가 패킷을 전달하거나 응답하기 위해 필요로 하는 사항을 자세히 검토했습니다.

체크리스트 문제 해결

이제 연결 문제의 원인을 찾는 기본 절차를 거쳤으므로 일반적인 문제를 해결하기 위한 몇 가지 체크리스트를 확인할 수 있습니다.

변환 테이블에 설치되지 않은 변환

변환 테이블에 적절한 번역이 설치되지 않은 경우 다음을 확인합니다.

• 구성이 올바릅니다. NAT를 통해 원하는 작업을 수행하는 것은 때때로 까다로울 수 있습니다. 일부 컨피그레이션 도움말은 네트워크 주소 변환 구성을 참조하십시오. 시작하기.

• 패킷이 NAT 라우터에 들어가는 것을 거부하는 인바운드 액세스 목록은 없습니다.

• 패킷이 내부에서 외부로 이동하는 경우 NAT 라우터에는 라우팅 테이블에 적절한 경로가 있습니다. 자세한 내용은 NAT Order of Operation을 참조하십시오.

• NAT 명령에서 참조하는 액세스 목록은 필요한 모든 네트워크를 허용합니다.

• NAT 풀에 충분한 주소가 있습니다. NAT가 오버로딩하도록 구성되지 않은 경우에만 문제가 됩니다.

• 라우터 인터페이스가 NAT inside 또는 NAT outside로 적절하게 정의되어야 합니다.

• DNS(Domain Name System) 패킷의 페이로드를 변환하는 경우 패킷의 IP 헤더의 주소에서 변환이 발생하는지 확인합니다. 이 문제가 발생하지 않으면 NAT는 패킷의 페이로드를 조사하지 않습니다.

올바른 번역 항목이 사용되지 않음

변환 테이블에 올바른 변환 항목이 설치되어 있지만 사용되지 않는 경우 다음 항목을 확인하십시오.

• 패킷이 NAT 라우터에 들어가는 것을 거부하는 인바운드 액세스 목록이 없는지 확인합니다.

• 내부에서 외부로 이동하는 패킷의 경우 변환하기 전에 이 옵션이 확인되므로 목적지로 가는 경로가 있는지 확인합니다. 자세한 내용은 NAT Order of Operation을 참조하십시오.

NAT가 올바르게 작동하지만 여전히 연결 문제가 있습니다.

NAT가 올바르게 작동하는 경우 다음과 같이 연결 문제 해결을 시작합니다.

• 레이어 2 연결을 확인합니다.

• 레이어 3 라우팅 정보를 확인합니다.

• 문제를 일으킬 수 있는 패킷 필터를 검색합니다.

포트 80에 대한 NAT 변환이 작동하지 않음

포트 80에 대한 NAT 변환은 작동하지 않지만 다른 포트에 대한 변환은 정상적으로 작동합니다.

이 문제를 해결하려면 다음 단계를 완료하십시오.

1. 변환 테이블에 올바른 변환 항목이 설치되어 있는지 확인하려면 debug ip nat translations 및 debug ip packet 명령을 실행합니다.

2. 서버가 응답하는지 확인합니다.

3. HTTP 서버를 비활성화합니다.

4. NAT 및 ARP 테이블을 지웁니다.

%NAT: 시스템이 사용 중입니다. 나중에 시도

%NAT: 시스템이 사용 중입니다. NAT와 관련된 show 명령 또는 show running-config 또는 write memory 명령이 실행될 때 나중에 오류 메시지를 시도합니다. 이 문제는 NAT 테이블의 크기가 증가했기 때문입니다. NAT 테이블의 크기가 커지면 라우터의 메모리가 부족합니다.

이 문제를 해결하려면 라우터를 다시 로드합니다. HSRP SNAT를 구성할 때 오류 메시지가 나타나면 문제를 해결하기 위해 다음 명령을 구성합니다.

Router(config)#standby delay minimum 20 reload 20
Router(config)#standby 2 preempt delay minimum 20 reload 20 sync 10

큰 변환 테이블이 CPU를 증가시킵니다.

호스트는 수백 개의 변환을 전송할 수 있으며, 그 결과 CPU 사용량이 증가합니다. 즉, 테이블이 너무 커서 CPU가 100%로 실행될 수 있습니다. ip nat translation max-entries 300 명령은 호스트당 300개의 제한 또는 라우터에 있는 변환 양의 집계 제한을 만듭니다. 해결 방법은 ip nat translation max-entries all-hosts 300 명령을 사용하는 것입니다.

% 공용 ip 주소가 이미 매핑되었습니다(내부 ip 주소 -> 공용 ip 주소).

이 메시지는 동일한 포트에서 수신 대기하는 하나의 공용 IP 주소에 두 개의 내부 IP 주소를 구성하려고 할 때 나타납니다.

% X.X.X.X already mapped (172.30.62.101 -> X.X.X.X)

공용 IP 주소를 두 개의 내부 IP 주소에 NAT하려면 DNS에서 두 개의 공용 IP 주소를 사용합니다.

ARP 테이블에 항목 없음

이는 NAT 항목에 사용되는 no-alias 옵션의 결과입니다. no-alias 옵션은 라우터가 주소에 응답하지 않고 ARP 항목을 설치하지 않음을 의미합니다. 다른 라우터가 NAT 풀을 연결된 서브넷의 주소로 구성된 내부 글로벌 풀로 사용하는 경우 해당 주소에 대한 별칭이 생성되어 라우터가 해당 주소에 대한 ARP(Address Resolution Protocol) 요청에 응답할 수 있습니다. 이렇게 하면 라우터가 위조 주소에 대한 ARP 항목을 갖게 됩니다.

결론

위의 문제는 NAT가 항상 IP 연결 문제의 원인은 아니라는 것을 보여줍니다. 대부분의 경우, 원인은 NAT 이외의 것이며 추가 조사가 필요합니다. 이 문서에서는 트러블슈팅 및 NAT 작업 확인 시 수행하는 기본 단계에 대해 설명합니다. 이러한 단계는 다음과 같습니다.

• NAT가 달성해야 할 사항을 명확하게 정의합니다.

• 변환 테이블에 올바른 변환이 있는지 확인합니다.

• show 및 debug 명령을 사용하여 변환이 진행 중인지 확인합니다.

• 패킷에 발생하는 상황을 자세히 검토하고 라우터에 패킷을 이동할 올바른 라우팅 정보가 있는지 확인합니다.

토큰 0이 잘못되었습니다. TOK_NUMBER|TOK_FST

이 오류 메시지는 정보 제공용일 뿐이며 디바이스의 정상적인 동작에 영향을 미치지 않습니다.

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 클라이언트를 "패시브"로 설정하여 두 채널을 모두 시작하는 것이 좋습니다. 이는 NAT를 통한 FTP에 도움이 될 수 있습니다.

관련 정보

• NAT 지원 페이지
• Technical Support - Cisco Systems

Revision History