Cisco ASA 터널 기본 경로: 실제로 언제 적용되는가

원격 접속 사용자는 ASA 너머로 아무것도 도달하지 못하는데, 같은 서버는 내부 LAN에서 오는 ping에는 응답한다. 터널은 올라오고 클라이언트는 풀에서 주소를 받지만, 패킷은 여전히 인터넷 기본 경로로 나가거나 사라진다. 이런 패턴은 보통 복호화된 트래픽이 자체 경로를 찾지 못해 일반 기본 경로로 떨어졌다는 뜻이다. 해결책은 또 하나의 NAT 규칙이 아니라 터널 기본 경로다.

설정이 아니라 증상에서 시작하라

패킷이 어디로 가는지 보라. 어디로 갈 것이라고 기대했는지가 아니라. 실패한 세션 동안 외부 인터페이스에서 캡처하면, 풀 주소가 그대로인 복호화된 패킷이 ISP 게이트웨이로 향하는 모습이 보이거나, 조회가 실패해 아무것도 보이지 않는다. 어느 쪽이든 터널이 문제는 아니다.

show vpn-sessiondb에서는 터널이 건강해 보인다. 바로 그래서 사람들이 계속 IKE를 디버깅한다.

이것을 ACL 드롭과 구분하는 것은 방향이다. ACL 드롭은 로그에 남고 카운트되지만, 경로가 없으면 일치하는 항목 없이 조회 실패가 발생한다. 클라이언트 목적지에 대해 show route를 실행하고 ASA가 실제로 무엇을 선택했는지 읽어 보라. 기본 경로가 선택되었는지, 선택되었다면 어느 것인지도 포함해서.

터널 조회는 어떻게 다른가

Cisco의 ASA 9.23 정적 라우팅 가이드에는 정적 경로도 학습된 경로도 없는 복호화된 VPN 트래픽을 위한 별도의 기본 경로가 문서화되어 있다. tunneled 키워드가 그 경로를 표시하므로, 복호화된 패킷은 ASA가 자체 전송에 사용하는 다음 홉과 다른 다음 홉으로 폴백할 수 있다. 더 구체적인 경로가 여전히 우선하므로, 클라이언트가 내부 게이트웨이를 통해 10.0.0.0/8에는 도달하고 나머지는 모두 잃을 수 있다.

최소 구성은 다음 홉이 다른 두 개의 기본 경로를 유지한다. 하나는 ASA 자체 트래픽을, 다른 하나는 더 나은 경로가 없는 복호화된 트래픽을 나른다. 두 다음 홉 모두 연결하는 인터페이스에서 도달 가능해야 한다.

route outside 0.0.0.0 0.0.0.0 198.51.100.1
route outside 0.0.0.0 0.0.0.0 10.20.30.1 tunneled

두 기본 경로가 같은 다음 홉을 가리키면 키워드는 아무것도 바꾸지 않고 증상도 움직이지 않는다.

작동 여부를 결정하는 제약

같은 가이드는 터널 기본 경로를 하나만 허용하며 이에 대한 ECMP는 지원되지 않는다고 명시하므로, 그 경로에서 부하 분산은 할 수 없다. 또한 경로 추적, 역방향 경로 검증, 일부 인스펙션 및 관리 흐름과 관련된 제약도 나열한다. 기능을 중심으로 설계하기 전에 설치된 릴리스에 비추어 읽어 보라. 이를 무시한 설계는 보통 모든 곳이 아니라 한 특정 지점에서 실패하며, 증상이 간헐적으로 보이는 이유가 여기에 있다.

비대칭 설계에서 문제가 되는 것은 역방향 경로 검증이다. 응답이 ASA가 기대하는 인터페이스와 다른 인터페이스로 도착한다면, 라우팅이 중요해지기 전에 패킷이 드롭된다. 검증을 꺼서 다음 홉을 강제하는 대신 토폴로지나 반환 경로를 고쳐라.

경로 추적은 별도의 함정이다. 추적되는 객체는 보통 일반 기본 경로를 지키지, 터널 기본 경로를 지키지 않는다.

키워드가 하지 않는 일

ASA가 IKE를 구성할 때 쓰는 소스 주소를 선택하지 않는다. 바깥 터널 끝점은 플랫폼 자체의 인터페이스와 소스 선택을 따르며, 터널 기본 경로는 그 결정에 관여하지 않는다. 이것을 바꿔도 잘못된 주소에서 시작하는 phase 1은 고쳐지지 않는다.

다음 홉을 프록시로 바꿔 주지도 않는다. 목적지가 HTTP CONNECT 교환을 기대한다면, 프록시 호스트로 원시 IP 패킷을 보내는 것은 그 패킷을 라우팅하지 않는 호스트를 얻을 뿐이다. 대신 클라이언트가 지원하는 프록시 방식을 설정하라.

그리고 하위 포워딩을 만들어 주지도 않는다. 가리키는 게이트웨이에는 여전히 VPN 풀로 돌아가는 경로가 필요하고, 설계가 요구하는 곳에는 소스 변환도 필요하다.

경로를 처음부터 끝까지 검증하라

경로를 넣은 뒤에는 네 가지를 순서대로 확인한다. 풀이 필요로 하는 목적지에 대한 show route, 새 다음 홉 방향 인터페이스의 캡처, 게이트웨이 자체의 캡처, 그리고 그 게이트웨이에서 풀 주소로 돌아오는 반환 경로다. 처음 두 가지는 ASA가 그 경로를 선택했음을, 마지막 두 가지는 그 경로에서 누군가 응답함을 증명한다.

게이트웨이는 응답하는데 클라이언트가 응답을 전혀 보지 못한다면, 라우팅 테이블을 다시 건드리기 전에 소스 변환과 반환 경로를 확인하라.

검증한 릴리스를 기록해 두라. 제약 목록은 버전에 따라 다르고, 한 트레인에서 동작하는 설계가 다른 트레인에서는 다른 경로를 필요로 할 수 있다. 그 메모는 설정 스니펫보다 오래 살아남는다.