스플릿 터널은 공용 호스트를 ASA의 NAT 규칙에서 제외하지 않는다

스플릿 터널링은 보통 기업 트래픽은 터널 안에, 나머지 인터넷은 방화벽 밖에 두는 방법으로 설명된다. 그 설명의 양쪽 절반 모두 같은 방식으로 틀렸다. 스플릿 터널링은 클라이언트가 내리는 경로 결정이고, 경로 결정은 패킷이 헤드엔드에 도달한 뒤 무슨 일이 일어나는지에 대해 아무것도 말하지 않는다.

본사 주소를 보겠다고 고집하는 공용 주소의 파트너 서비스 하나만으로도 이 이야기는 무너진다.

신화: 스플릿 터널은 방화벽을 경로에서 빼낸다

사설 범위 밖의 어떤 목적지든 로컬 인터넷 연결에 남으므로 방화벽이 그것을 볼 일도, 규칙이 필요할 일도 없다는 믿음이다. 그것은 목적지가 터널 목록에 없을 때만 성립한다. 운영자가 공용 호스트를 split-include ACL에 추가하는 순간, 클라이언트는 그 트래픽을 터널로 보내고, ASA는 다른 복호화된 흐름과 마찬가지로 라우팅하고 필터링하고 변환해야 한다. 클라이언트에서는 목적지 목록 외에는 아무것도 바뀌지 않았다.

클라이언트가 라우터가 된 것은 아니다. 주어진 정책을 따른 것뿐이다.

split-include 경로가 실제로 하는 일

Cisco ASA 원격 액세스 구성에서 그룹 정책은 split-tunnel-policy tunnelspecified와 표준 ACL을 지정하는 split-tunnel-network-list를 포함한다. 그 ACL의 각 permit 줄은 클라이언트가 터널로 보내야 할 목적지이고, 나머지는 계속 로컬 기본 경로를 사용한다.

호스트 하나를 추가하는 것은 한 줄이며, 클라이언트가 볼 수 있는 변경의 유일한 부분이다: access-list RA-SPLIT standard permit host 203.0.113.20.

그다음 클라이언트를 다시 연결한다. 정책은 연결 시에 교환되므로 이미 설정된 세션은 이전 목록을 유지하고 변경이 아무것도 하지 않은 것처럼 보인다.

패킷은 같은 인터페이스로 들어오고 나간다

이제 복호화 후 흐름을 추적한다. 패킷은 VPN 터널을 통해 외부 인터페이스로 들어왔고, 목적지는 공용 주소이며, 라우팅 테이블은 같은 외부 인터페이스로 인터넷을 향해 다시 내보낸다. 한 인터페이스로 들어오고 나가는 트래픽은 ASA가 허용하지 않으면 버려지며, same-security-traffic permit intra-interface가 바로 그 일을 한다. 그것이 없으면 연결은 라우팅 문제처럼 보이지만 실제로는 아닌 방식으로 실패한다.

그 설정은 전역이다. 필요한 모든 흐름에 헤어핀을 허용하며 이 파트너 호스트에만 국한되지 않으므로, 빠른 테스트가 아니라 검토된 변경에 속한다.

목적지로 한정된 PAT가 선택 사항이 아닌 이유

복호화된 패킷의 소스 주소는 여전히 클라이언트의 VPN 주소이며, 보통 10.77.0.0/24 같은 풀에서 나온다. 그 주소는 공용 인터넷에 경로가 없다, 그래서 파트너는 응답하지 않거나 아무 데도 응답하지 않는다.

변환은 소스를 바로잡고 목적지는 그대로 둔다. 객체가 이미 다른 곳에 정의되어 있으므로, 이 목적지로 한정된 수동 규칙은 이런 형태다:

same-security-traffic permit intra-interface

object network RA_POOL
 subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
 host 203.0.113.20

nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOST

destination static 부분이 중요하다. 그것을 빼면 규칙은 의도보다 훨씬 많은 트래픽에 맞을 수 있는 넓은 변환이 되고, 순서상 앞선 넓은 identity 규칙이 이것을 완전히 이길 수 있다. 자신의 규칙이 일치한다고 가정하기 전에 show nat detail와 섹션 순서를 확인하라.

인터페이스 PAT는 파트너가 ASA의 인터페이스 주소를 본다는 뜻이며, 그 주소는 상류에서 다시 변환될 수 있다. 계약이 주소를 지정한다면 한 홉이 아니라 끝에서 끝까지 확인하라.

올바른 테스트 목적지로 증명하라

일반 what-is-my-ip 페이지가 아니라 파트너 호스트 자체를 사용하라. 그 페이지는 거의 확실히 split 목록 밖에 있으므로 로컬 인터넷 주소를 보고할 뿐 이 경로에 대해서는 아무것도 말하지 않는다. 파트너 서비스에 새 연결을 열고 그들이 어떤 소스를 보았는지 물어보거나, packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed를 실행해 NAT와 라우팅 단계를 줄 단위로 읽어라. 클라이언트에서의 traceroute는 이미 일어난 경로를 보여줄 뿐 그것을 선택한 정책은 보여주지 않으므로 더 약한 확인이다.

그다음 바뀌어서는 안 되는 것을 확인하라. 일반 웹사이트는 여전히 로컬 연결로 나가야 하고, 터널 목록 안의 사설 리소스는 여전히 접근 가능해야 한다. 파트너를 고치면서 둘 중 하나를 깨뜨리는 변경은 다른 버그다.

이 설계의 동작하는 버전은 split ACL에 호스트 하나, 헤어핀 허용, 목적지로 한정된 PAT 규칙 하나로 짧다. 이야기의 나머지는 모두 신화다.