WAN 인터페이스 하나로 사이트 간 VPN과 원격 VPN을 함께 처리할 수 있을까?

공인 주소 하나로 지사 터널과 이동 사용자 풀을 동시에 처리할 수 있습니다. 하지만 하나의 공통 허용 규칙을 처리할 수는 없습니다. 지사의 피어와 이동 사용자는 다릅니다 자신이 누구라고 주장하는지, 그 증명을 어떻게 검사하는지, 어떤 주소를 받는지, 어떤 프리픽스가 응답할 수 있는지가 다릅니다. 외부 주소를 신원이 아니라 전송 세부 사항으로 다루면 설계가 훨씬 단순해집니다.

빠른 상식 점검: 라우터를 건드리기 전에 두 허용 레코드를 모두 써 보십시오. 하나의 매칭 조건이 둘을 모두 덮어야 한다면 정책은 이미 모호하고, 첫 증상은 라우팅이나 방화벽 결함처럼 보이지만 실제로는 신원 결함입니다.

어떤 구성보다 먼저 두 레코드

지사 레코드는 짧고 안정적입니다. 피어 주소나 인증서 이름, 미리 공유한 키나 인증서 트러스트포인트, 양쪽의 보호 서브넷, 터널 인터페이스, 그리고 지사로 향하는 트래픽을 그 터널로 보내는 정적 경로를 나열합니다. 각 필드는 하나의 알려진 피어와 고정된 프리픽스 집합에 관한 것입니다.

이동 레코드는 더 넓고 더 개인적입니다. 클라이언트 프로토콜과 포트, 사용자나 장치가 인증하는 방식, 연결 시 부여되는 주소 풀, 그 풀이 도달할 수 있는 자원, 분할 터널 프리픽스, 클라이언트로 밀어 넣는 DNS 서버, 그리고 모든 두 번째 요소를 나열합니다. 각 필드는 하나의 게이트웨이가 아니라 알 수 없는 수의 사용자에 대한 질문에 답합니다.

이 세분성 차이가 두 역할이 갈라지는 이유 전부입니다. 지사 프로필은 키가 한 사이트의 한 장치에 속하므로 하나의 키를 안전하게 신뢰할 수 있습니다. 모두를 위해 하나의 그룹 키를 신뢰하는 이동 프로필은 사용자별 책임을 무너뜨리며, 이는 보통 배포 중이 아니라 사고 리뷰에서 나중에 발견됩니다.

피어 매칭과 인증이 갈라지는 지점

IOS XE에서 IKEv2 프로필은 협상할 수 없는 매개변수와 피어를 선택하는 조건을 담습니다. 즉 지사 측과 이동 측은 같은 인터페이스에서 종료되더라도, 같은 암호 PKI를 공유하더라도 각자의 프로필이 필요합니다. Cisco는 프로필, 인증, 매칭의 역할을 자사의 IOS XE 17용 IKEv2 구성 가이드에서 설명합니다.

지사 프로필은 보통 원격 주소, FQDN, 또는 인증서 주체 같은 좁은 신원과 매칭됩니다. match identity remote address 198.51.100.10 255.255.255.255 같은 줄은 피어 하나를 고정하고, 사이트별로 저장한 키를 쓰는 authentication remote pre-share 이면 충분합니다. 선택 순서에서 더 위에 있는 중복 와일드카드가 지사 트래픽을 잘못된 프로필로 끌어갈 수 있으므로, 피어 목록이 허용하는 만큼 매칭을 구체적으로 유지하십시오.

이동 프로필은 주소를 고정할 수 없으므로 그룹, key-id, 또는 인증서 필드와 매칭한 뒤 실제 사용자 검사를 AAA나 프로필에 붙은 인가 정책에 넘깁니다. 이 분리가 중요한 이유는 피어 인증이 클라이언트가 터널을 만들 수 있는지 답하고 사용자별 인가가 어떤 풀과 어떤 자원을 받는지 답하기 때문입니다. 지사 키를 범용 로그인으로 쓰면 두 번째 답을 버리게 됩니다.

전달과 변환에도 같은 분리가 필요합니다

허용과 도달 가능성은 별개의 문제입니다. IKE와 IPsec 교환이 성공해도 양측이 키에 합의했다는 것만 증명할 뿐, 클라이언트가 받은 풀에 대한 경로를 만들지는 않습니다. 따라서 원격 액세스 풀에는 터널 인터페이스를 가리키는 정적 경로이거나 풀 요약을 주입하는 라우팅 프로토콜인 반환 경로가 필요합니다. 지사 프리픽스는 보통 사이트의 나머지를 담당하는 같은 라우팅 프로세스로 들어옵니다.

변환은 두 역할이 가장 자주 충돌하는 지점입니다. 사설 주소를 유지해야 하는 사이트 간 트래픽에는 그 두 프리픽스로 한정된 NAT 예외가 양방향으로 필요합니다. 이동 클라이언트도 보통 터널 내부 트래픽에 대한 예외가 필요하지만, 인터넷으로 가는 트래픽은 분할 터널로 터널을 우회하거나 NAT 후 허브에서 나갑니다. 터널에서 오는 모든 것을 예외로 두는 것은, 정말 필요한 트래픽에서도 변환을 빼앗기 때문에 전형적인 실수입니다.

예외 규칙은 허용 규칙만큼 좁게 유지하십시오. 풀 요약과 지사 프리픽스가 겹치면 패킷이 하나도 버려지기 전에 반환 경로가 모호해지고, 증상은 깔끔한 터널 장애가 아니라 한 사이트가 간헐적으로 서브넷을 잃는 모습으로 나타납니다.

교차된 정책을 드러내는 수용 사례

네 가지 사례를 만들고 순서대로 실행합니다. 지사 호스트가 지사 전용 자원에 도달합니다. 이동 클라이언트가 자기 풀 주소로 같은 자원에 도달합니다. 이동 클라이언트가 건드리면 안 되는 지사 프리픽스를 시도합니다. 지사 피어가 원격 액세스 풀에서 주소를 얻으려 합니다. 마지막 두 가지가, 일반 모니터링에서는 조용히 실패하기 때문에, 공유 프로필을 잡아냅니다.

그다음 구성이 아니라 데이터 플레인을 확인하십시오. show crypto ikev2 sa 과 show crypto ipsec sa 은 어느 프로필과 어떤 셀렉터가 각 흐름을 실었는지 알려 주고, show ip nat translations 과 터널 카운터는 반환 경로와 예외가 실제로 맞았는지 보여 줍니다. 터널 인터페이스에서의 tracer나 패킷 캡처가 고리를 닫습니다.

관찰된 신원, 풀 주소, 선택된 정책을 각 결과 옆에 적으십시오. 모든 사례가 정확히 하나의 레코드에 대응하고 어떤 사례도 통과를 위해 임시 예외가 필요 없을 때 실행이 끝납니다.