IOS에서 ASA로의 VPN 이전: 명령이 아니라 합의를 번역하세요

ASA 이전의 참조 자료로 들어오는 IOS 구성은 한 플랫폼의 문법으로 포장된 합의를 설명합니다. 피어 주소, 식별 정보, 보호 범위가 바로 그 합의입니다. 키 링, 프로필, 암호화 맵 체인은 IOS가 그것을 표현하는 방식이며, ASA는 같은 의도를 터널 그룹과 그 속성으로 표현합니다. 뒤쪽 부분만 복사하면 절대 동작하지 않고, 앞쪽만 복사하면 작업이 절반만 끝납니다.

아래 다섯 단계를 순서대로 진행하고, 두 플랫폼이 다른 단어가 아니라 다른 대상을 설명하는 지점에서 멈추십시오.

1단계: 합의를 문법에서 분리합니다

두 관리자가 동의하는 요구 사항의 형태로 인수인계를 작성합니다. 네 개의 행은 피어가 어디에 있고 어느 쪽이 시작하는지, 각 쪽이 어떻게 자신의 식별 정보를 증명하는지, 어떤 보호가 허용되는지, 어떤 애플리케이션이 터널을 넘어 살아남아야 하는지를 거의 모두 담습니다. 이 행들 어디에도 명령은 나오지 않습니다.

원문은 지시가 아니라 증거로 보관합니다. 한 플랫폼에는 있고 다른 쪽에는 없는 행은, 같은 요구 사항을 다른 방식으로 충족할 수 있는지 확인할 때까지는 문법 차이입니다.

2단계: 각 플랫폼에서 객체의 이름을 정합니다

IOS XE에서는 IKEv2 키 링이 IKEv2 프로필을 공급하고, 그 프로필은 암호화 맵이나 IPsec 프로필을 통해 연결되며, ASA에서는 터널 그룹이 연결 프로필과 그 IPsec 속성을 보관하고 암호화 맵이 그것을 가리킵니다. 자세한 내용은 연결 프로필 안내서에서 설명합니다. 이는 상속 구조가 다른 별개의 객체 그래프이므로, 행 단위 매핑은 분석은 되지만 연결되지 않는 구성을 만들어 냅니다.

대상 객체는 원본 행이 아니라 요구 사항 행에서 구성합니다. 행이 완전하면 대상 구성은 설계 결정입니다. 그렇지 않으면 아무리 명령을 많이 번역해도 빠진 의도를 채울 수 없습니다.

3단계: 주소만이 아니라 식별 정보를 옮깁니다

식별 정보는 조용히 깨지는 부분입니다. 주소로 인증하는 피어는 인증서 주체나 FQDN으로 인증하는 피어와 다르게 동작하며, 두 플랫폼은 그 기대를 서로 다른 위치에 기록합니다. 테스트가 쉽다는 이유로 공유 비밀을 대체하지 말고 의도한 식별 정보와 신뢰 체인을 유지하십시오.

사전 공유 비밀은 비교 메모와 티켓에 남기지 마십시오. 누가 소유하고 승인된 경로로 어떻게 전달되는지 기록하고, 문서 예제의 자리 표시자는 고객의 자격 증명이 아니라는 점을 기억하십시오.

4단계: 전환 전에 보호 방식을 합의합니다

제공된 텍스트에 있다는 이유로 오래된 암호화 설정을 그대로 가져오지 마십시오. 두 배포된 피어가 현재 지원하는 스위트의 교집합을 합의하고, 변경 작업 전에 다른 관리자와 확인하십시오. 그 교집합이 기존 피어의 기대와 다르면 이는 국지적 편집이 아니라 조율된 변경입니다.

합의한 집합을 적어 두십시오. 전화 통화에 대한 기억이 서로 다른 두 관리자가 바로 전환에서 두 번째 단계 불일치를 만드는 원인입니다.

5단계: 문법이 아니라 서비스를 검증합니다

먼저 대상의 실효 객체를 확인하고, 다음으로 수락된 연결을, 다음으로 실제 애플리케이션 흐름과 그 응답을 확인하십시오. 명령을 오류 없이 입력한 것은 문법만 증명합니다. 터널이 올라오는데 트래픽이 흐르지 않는다면 보통 보호 범위나 반환 경로가 상대와 맞지 않는다는 뜻이며, 이는 명령의 문제가 아니라 요구 사항 행의 문제입니다. 암호화 맵을 다시 건드리기 전에 양쪽의 보호 범위를 비교하십시오.

무엇을 어떤 주소로 어느 쪽에서 검증했는지 기록하십시오. 그 기록은 VPN이 올라와 있다는 모호한 주장을 다른 관리자가 독립적으로 확인할 수 있는 것으로 바꿉니다.

무엇을 돌려줄지

요구 사항 매트릭스, 대상 구성 요약, 검증 결과를 보내십시오. 어떤 원본 설정을 가져오지 않았고 그 이유가 무엇인지 분명히 밝히십시오. 그 목록은 다음 이견이 바로 거기서 시작되므로 번역된 구성보다 유용합니다.

원문도 티켓과 함께 보관하십시오. 무엇이 요청되었는지를 기록하고, 매트릭스는 무엇이 합의되었는지를 기록합니다.