ASA hairpin: 인터넷 출구인가, 사이트 간 VPN 구간인가?

같은 ASA 뒤의 두 원격 접속 사용자가 같은 외부 인터페이스로 트래픽을 보내도 전혀 다른 처리를 받을 수 있습니다. 한 명은 공용 웹사이트로 가므로 패킷에 소스 변환과 인터넷 라우트가 필요합니다. 다른 한 명은 그 인터페이스에서 종료되는 사이트 간 터널 뒤의 서버로 가므로 패킷에 아이덴티티, 일치하는 터널 셀렉터, 클라이언트 풀로 돌아가는 경로가 필요합니다. 같은 인터페이스 허용은 둘 모두의 전제 조건이며 어느 쪽의 해결책도 아닙니다.

두 구간, 하나의 인터페이스

NAT 규칙을 입력하기 전에 어느 구간을 만드는지 정하세요. 규칙은 서로 바꿀 수 없습니다. 구간 A는 클라이언트에서 인터넷으로 갑니다. 풀 주소가 들어가고 변환된 공용 주소로 나가며 같은 인터페이스로 돌아옵니다. 구간 B는 클라이언트에서 다른 IPsec 피어 건너편의 사설 프리픽스로 갑니다. 풀 주소는 유지되고 다시 암호화되어, 풀에 응답하는 방법을 아는 피어로 전달됩니다.

둘 모두에게 먼저 필요한 것은 같은 인터페이스 허용입니다. 이것이 없으면 ASA는 패킷이 도착한 인터페이스로 그 패킷을 내보내지 않으며, 실패는 정책 문제가 아니라 라우팅 문제처럼 보입니다.

same-security-traffic permit intra-interface

그 한 줄은 전달 구성을 허용합니다. 다음 문서가 설명하는 대로입니다. ASA NAT 레퍼런스 같은 인터페이스 경로에 대해 설명합니다. 클라이언트 라우트를 추가하지도, 리소스를 허용하지도, 주소를 변환하지도, IPsec 셀렉터를 협상하지도 않으므로 그 뒤에 세 가지나 네 가지를 더 추가할 것으로 예상하고, 이것이 통과된 것을 진전으로 읽지 마세요.

구간 A: 클라이언트가 인터넷을 원하는 경우

인터넷 출구에서는 패킷이 장비를 떠나기 전에 풀 주소가 사설이기를 그쳐야 합니다. 일반적인 PAT 설계에서 규칙은 풀을 외부 인터페이스 주소로 변환하고, 응답 상태가 클라이언트 방향 흐름을 복원합니다.

object network VPN_POOL
 subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup

그런 다음 클라이언트가 실제로 그 트래픽을 ASA가 나르도록 요청했는지 확인하세요. 스플릿 터널 제외는 공용 목적지를 휴대폰 자체 연결로 보내므로 ASA에 전혀 도달하지 않으며, 보내지 않은 패킷은 어떤 NAT 규칙으로도 고칠 수 없습니다. 그룹 정책의 스플릿 터널 목록과 테스트하는 목적지를 맞춰 보세요.

구간의 나머지는 평범합니다. 외부 인터페이스에서 쓸 수 있는 기본 또는 특정 라우트, 흐름을 허용하는 접근 정책, 선택한 리졸버 정책에 따라 처리되는 DNS입니다. 여기에 route-lookup 를 아래와 같은 이유로 추가하세요. 입구와 출구 인터페이스가 동일하기 때문입니다.

구간 B: 클라이언트가 사설 사이트를 원하는 경우

이 구간은 더 많은 곳에서 실패하므로 순서대로 쓰세요. 먼저 클라이언트 라우트입니다. 목적지 프리픽스가 스플릿 터널 목록에 있어야 하며, 아니면 클라이언트가 그것을 터널에 넣지 않습니다. 다음은 터널 셀렉터입니다. 사이트 간 암호화 ACL은 로컬 LAN에서 원격 프리픽스뿐 아니라 풀 주소에서 원격 프리픽스까지 포함해야 합니다. 마지막은 아이덴티티입니다. 지나가는 길에 풀 주소가 인터넷 PAT로 변환되지 않아야 합니다.

nat (outside,outside) source static VPN_POOL VPN_POOL
    destination static SITE_PREFIX SITE_PREFIX route-lookup

먼 쪽은 사람들이 테스트를 잊는 부분입니다. 피어에는 풀로 돌아가는 라우트와 그것을 포함하는 셀렉터가 필요하고, 피어 자신의 정책이 피어가 보게 될 소스 주소를 허용해야 합니다. 사이트를 대신 변환된 뷰로 사용한다면 그것은 유효한 설계이지만, 그때는 두 피어, 두 셀렉터, 두 라우팅 테이블이 변환된 주소에 대해 합의해야 합니다.

규칙 순서도 확인하세요. 아이덴티티 규칙 위에 있는 넓은 PAT 규칙은 아이덴티티 규칙이 평가되기도 전에 사설 교환을 변환해 버리며, 증상은 NAT 오류가 아니라 일치하는 SA가 없는 사이트 터널입니다.

어느 구간을 만들었는지 알려 주는 테스트

설정을 읽고 기대하는 대신 ASA 자체의 경로 평가를 사용하세요. packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed 는 하나의 흐름에 대한 NAT 결정, 라우트, ACL 결과를 보여 줍니다. 사설 목적지로 반복하세요. NAT 단계가 사설 간 흐름을 다시 쓴다면 구간 B가 필요했던 패킷에 구간 A를 만든 것입니다.

두 명령이 더 격차를 메웁니다. show nat detail 는 packet-tracer가 따른 규칙 순서를 출력하고, show crypto ipsec sa 는 기대하는 쌍에 대한 셀렉터가 있는지 보여 줍니다. 없는 SA는 셀렉터나 피어 설정의 문제이며, NAT 규칙으로 고칠 수 있는 것이 아닙니다.

각 구간을 그것이 처리하는 트래픽으로 검증하세요

구간 A는 클라이언트의 평범한 공용 요청으로, 구간 B는 실제로 존재하는 사설 리소스에 대한 요청으로 받아들이세요. 그런 다음 각각을 거부된 리소스로 반복하세요. “허용됨”과 “접근 정책으로 승인됨”은 같은 증거가 아니며, 허브에서 시작한 ping은 두 클라이언트 경로 중 어느 것도 시험하지 않습니다.

티켓에서 두 테스트 기록을 따로 보관하세요. 소스 주소, 목적지, 일치한 NAT 규칙, 결과입니다. 다음 보고서가 “VPN이 망가졌다”고 하면 그 쌍이 일 분 안에 어느 구간이 퇴행했는지 알려 줍니다. 답은 대개 라우트나 셀렉터이며, 모두가 가장 먼저 의심하는 같은 인터페이스 한 줄이 아닙니다.