ASA VPN hairpin: 하나의 인터페이스로 두 터널 라우팅하기

원격 사용자가 ASA에 접속해 지사 뒤에 있는 호스트를 요청하면, ASA는 그 요청을 사용자가 들어온 바로 그 인터페이스로 내보냅니다. 그 때문에 두 번째 물리 포트가 필요한 것은 아닙니다. 필요한 것은 사람들이 하나로 뭉뚱그리기 쉬운 네 가지 독립적인 결정입니다. hairpin을 허용할 것인지, 올바른 주소를 보호하는 터널인지, 약속한 출발지를 유지하는 NAT 정책인지, 그리고 서비스를 승인하는 접근 정책인지입니다.

하나의 패킷, 두 개의 터널

흐름을 따라가면 동작 순서가 더 이상 불가사의하지 않습니다. 패킷은 원격 접속 터널 안으로 들어와 복호화되고, 클라이언트 풀을 출발지로 하는 평범한 IP 패킷이 됩니다. 그다음 ASA가 이를 라우팅하고, 사이트 간 crypto ACL과 대조하고, 다시 암호화해 외부 인터페이스에서 지사 쪽으로 보냅니다.

아래 주소는 예시일 뿐이지만 형태가 중요합니다. 출발지는 풀이지 ASA의 내부 LAN이 아닙니다.

remote client 10.77.0.20
  -> remote-access tunnel, terminated on ASA outside
  -> decrypted, routed, matched against site-to-site policy
  -> site-to-site tunnel, sent from ASA outside
  -> branch host 10.60.20.10

여기서 두 가지가 따라옵니다. 클라이언트는 자신의 원격 접속 연결을 통해 지사 프리픽스에 대한 경로가 필요하므로 split-tunnel이나 푸시되는 경로 목록에 그것이 포함되어야 합니다. 그리고 지사는 트래픽을 10.77.0.20이나 NAT 설계가 대체한 주소로 되돌리는 방법을 알아야 합니다.

hairpin 허용은 전역 설정이다

사람들이 흔히 손을 뻗는 명령은 same-security-traffic permit intra-interface 입니다. 이 명령은 트래픽이 같은 인터페이스로 들어오고 나갈 수 있게 하며, 이 경로에 필요한 것이 바로 그것입니다. 동시에 전역 설정이기도 합니다. 이를 켜면 같은 인터페이스를 두 번 지나가는 다른 흐름의 동작도 바뀝니다.

그래서 이것은 디버깅 세션이 아니라 변경 기록에 속합니다. 이 장비에서 같은 인터페이스 경로를 지금 택할 수 있는 다른 것이 무엇인지, 그리고 그중 무엇이 그래야 하는지 물어보십시오. 게스트 네트워크나 겹치는 파트너 터널이 있는 분주한 경계에서는 답이 자동으로 아니오가 아닙니다. 설정 옆에 이유를 적어 두십시오. 다음 엔지니어는 명령을 찾을 뿐 대화는 찾지 못합니다.

보호 범위와 NAT는 별개다

사이트 간 터널은 자신의 crypto ACL이 선택하는 것을 보호합니다. 그 ACL이 ASA의 내부 서브넷을 출발지로 지정하면 원격 접속 풀은 보호되지 않으며, 패킷은 플랫폼이 일치하지 않는 트래픽을 다루는 방식에 따라 폐기되거나 평문으로 전송됩니다. 설계가 풀 주소를 유지한다면 풀을 보호되는 흐름에 추가하십시오.

그다음 NAT가 풀 주소가 살아남을지 결정합니다. Identity NAT는 그것을 유지하며, 지사는 10.77.0.20을 출발지로 봅니다. 변환은 계약을 바꿉니다. 지사는 이제 변환된 주소로 트래픽을 되돌리며, 지사 자신의 정책이 그것을 받아들여야 합니다. 규칙 순서가 crypto ACL이 변환 전에 일치하는지 후에 일치하는지를 결정하므로, 어느 쪽이 이기는지 가정하지 말고 실제 흐름을 읽으십시오.

하나의 통과 사례를 살리기 위해 일반 인터넷 PAT 규칙을 삭제하지 마십시오. 표적 예외나 의도적인 identity 규칙이 아웃바운드 정책에 구멍을 내는 것보다 설명하기도 되돌리기도 쉽습니다.

암호화는 인가가 아니다

동작하는 터널은 두 피어가 키와 선택자에 합의했다는 것만 증명합니다. 이 사용자가 그 서비스에 도달할 수 있는지는 말해 주지 않습니다. 원격 접속 연결에 붙은 VPN 필터나 그룹 정책은 여전히 지사의 목적지와 포트를 허용해야 하고, 외부 경로의 인터페이스 ACL도 여전히 적용됩니다.

답을 양방향으로 시험하십시오. 옆 서비스는 실패해야 하는데 연결이 성공한다면, 성공한 ping 하나보다 정보가 많습니다. 정책이 활짝 열린 것이 아니라 선택적임을 보여 주기 때문입니다. 거부되어야 할 시험이 성공한다면 비난할 대상은 터널이 아니라 정책입니다. 두 결과를 모두 변경 기록에 남겨 다음 사람이 어떤 동작이 의도였는지 알 수 있게 하십시오.

hairpin 아니면 두 번째 인터페이스

hairpin 통과는 설계를 작게 유지하고 전역 설정 하나를 치릅니다. 별도 인터페이스나 자체 가상 인터페이스를 가진 경로 기반 터널은 통과 경로를 분리하고 인터페이스별 정책을 주지만, 주소 지정과 또 하나의 crypto map 또는 프로파일이라는 비용이 듭니다. 어느 쪽이 더 옳지는 않으며, 실패하는 방식이 다릅니다.

경로 기반 설계는 같은 구성의 체크박스가 아니라 다른 배치입니다. 그쪽으로 옮기면 위에서 논한 정책 기반 crypto ACL 논의는 적용되지 않고, 라우팅 테이블이 선택 작업을 하기 시작합니다.

실제 클라이언트에서 검증하라

ASA에서 시작한 검사는 출발지 주소가 다르고 풀에서 지사로 가는 경로를 실제로 지나지 않습니다. 다섯 항목을 확인하려면 packet-tracer 을 사용하고, 그다음 실제 원격 클라이언트에서 진짜 연결을 여십시오. 추적기는 시뮬레이션할 뿐 클라이언트 자체의 라우팅과 정책을 대체하지 않습니다.

계획된 변경 후에는 동작해야 하는 서비스에 연결하고, 다음으로 거부되어야 하는 서비스에 연결한 뒤, 지사의 반환 경로를 확인하십시오. Cisco의 VPN hairpin NAT 예 는 intra-interface 허용, NAT, ACL을 눈에 보이게 분리해 두며, 그것이 따라 배울 만한 사고 모델입니다.