VPN 트래픽에서 ASA identity NAT와 IOS NAT 제외의 차이

한 지사가 인터넷 PAT와 사이트 간 VPN을 같은 Cisco 게이트웨이에서 운영하는데, NAT를 추가하는 순간 VPN이 동작을 멈춥니다. 터널 내부 주소가 crypto ACL이 보호하는 것과 더 이상 일치하지 않거나, 상대 피어가 경로가 없는 변환된 주소를 보는 것입니다. Cisco는 이를 두 곳에서 해결합니다. ASA는 주소를 자기 자신으로 매핑하는 NAT 규칙을 선택하고, IOS는 ACL의 deny로 플로를 변환 규칙 밖에 둡니다. 둘 다 원래 주소를 유지하며, 어느 쪽도 NAT 처리를 우회하는 것이 아닙니다.

규칙을 고르기 전에 플로를 기록하세요

보호하려는 플로를 먼저 적으십시오. 로컬 LAN 출발지, 원격 목적지, 그리고 IPsec 정책이 보호하는 정확한 주소 쌍입니다. 규칙을 편집하기 전에 해야 하는데, 이 조합이 어떤 분류기나 NAT 규칙이 일치했어야 하는지를 보여주기 때문입니다.

그다음에는 의도한 규칙이 아니라 실제로 일치한 규칙을 찾으십시오. 두 플랫폼 모두 NAT를 순서대로 평가하며, 예외가 검토되기 전에 앞선 규칙이 이길 수 있습니다. 올바르게 보이는 예외라도 다른 규칙에 지면 기대한 패킷이 보호 정책에 전달되지 않습니다. 증상은 예외가 없는 경우와 같으므로, 구성을 바꾸기 전에 규칙 순서를 읽어야 합니다.

ASA identity NAT는 규칙이지 우회가 아닙니다

ASA에서 identity NAT는 변환된 주소가 원래 주소와 같은 NAT 규칙입니다. 다른 규칙과 똑같이 선택되며 변환 항목도 설치하므로, 패킷이 NAT 처리를 건너뛰지 않습니다. 달라지는 것은 네트워크상의 주소가 그대로 유지된다는 점이며, IPsec 정책이 필요로 하는 것이 바로 그것입니다.

nat (inside,outside) source static LAN-NET LAN-NET destination static REMOTE-NET REMOTE-NET

규칙의 인터페이스와 route-lookup 설정은 포워딩 설계와 일치해야 합니다. 주소를 올바르게 매핑하지만 잘못된 인터페이스 쌍에 적용된 규칙은 해당 플로에 선택되지 않습니다. route-lookup은 변환된 패킷을 라우팅할지 원래 목적지를 사용할지를 결정하고, 그것이 반환 트래픽이 터널로 되돌아오는지를 좌우합니다.

ASA 자체에 대한 관리 접근은 별개의 경우입니다. 관리 트래픽에 identity NAT를 사용하면 릴리스별 route-lookup 요구 사항이 적용되며, VPN 예시에서 복사한 광범위한 예외로는 SSH가 고쳐지지 않습니다.

IOS NAT ACL의 deny는 여기서 선택되지 않았다는 뜻입니다

IOS에서 인터넷 NAT는 출발지 목록으로 구동되며, 그 ACL은 필터가 아니라 분류기입니다. permit 줄은 변환 대상 트래픽을 선택하고, deny 줄은 패킷이 여기서 선택되지 않았음을 뜻합니다. 그 deny는 인터페이스 ACL의 deny처럼 패킷을 버리라는 지시가 아닙니다.

여기서 선택되지 않음은 어디에서도 변환되지 않음보다도 좁습니다. 다른 NAT 규칙, 다른 인터페이스, 또는 route-map이 여전히 플로를 변환할 수 있으므로 NAT 테이블 전체를 읽어야 합니다. 패킷에는 경로, 일치하는 crypto ACL, 그리고 실제 접근 제어 경계에서의 허용도 여전히 필요합니다.

최소 IOS 구성은 같은 목록에서 deny를 permit 위에 두고 overload 규칙을 그 목록으로 향하게 합니다. 그러면 crypto ACL은 deny가 변환에서 제외한 것과 같은 쌍을 보호합니다.

ip access-list extended NAT-ACL
 deny ip 10.10.0.0 0.0.0.255 192.0.2.0 0.0.0.255
 permit ip 10.10.0.0 0.0.0.255 any
ip nat inside source list NAT-ACL interface GigabitEthernet0/1 overload

두 모델 모두를 위한 검증 가능한 질문 하나

두 모델 모두 같은 질문에 답합니다. 어떤 규칙이 이 플로와 일치했고, 어떤 주소가 인터페이스를 떠났는가? 외부 인터페이스에서 캡처하고 게이트웨이 전후의 출발지 주소를 비교하십시오. 그다음 상대 피어가 보는 터널을 확인하십시오. SA가 살아 있어도 보호 대상 플로가 다른 곳에서 변환될 수 있기 때문입니다.

ASA에서는 nat detail과 변환 테이블을, IOS에서는 ip nat translations와 해당 ACL 카운터를 표시하십시오. 전혀 증가하지 않는 규칙은 선택된 적이 없으며, 이는 crypto 구성이 아니라 순서, 인터페이스, 방향을 가리킵니다.

구성이 보통 어디에서 틀어지는가

흔한 실패는 기계적입니다. deny가 permit 아래에 있어 절대 일치하지 않습니다. 분류기가 잘못된 방향으로 적용되어 반환 플로가 변환됩니다. identity 규칙이 올바른 주소를 다루지만 인터페이스 쌍이 틀립니다. crypto ACL이 NAT 규칙이 제시하는 것과 더 이상 일치하지 않는 서브넷을 보호합니다.

원래 주소 쌍과 제시되는 주소 쌍을 규칙 담당자 옆에 기록해, 다음 엔지니어가 왜 분류기는 변환을 거부하는데 방화벽은 애플리케이션을 허용하는지 볼 수 있게 하십시오. 개인 메모가 아니라 변경 티켓에 남기십시오. 그런 다음 NAT를 바꿀 때마다 플로를 다시 실행하십시오. 규칙 문구가 그대로여도 순서는 구성의 일부이기 때문입니다. 터널이 올라온 것은 주소가 살아남았다는 증거가 아닙니다. 캡처한 패킷과 상대 피어의 역캡슐화 이후 시점만이 증거입니다.