VPN 피어에 도달하는 VRF와 패킷을 운반하는 VRF는 무엇인가
터널은 피어에 도달하기 위해 하나의 라우팅 컨텍스트를, 보호된 패킷을 전달하기 위해 다른 컨텍스트를 사용할 수 있습니다. 경로를 추가하기 전에 두 조회를 따로 확인하십시오.
고객 라우팅 컨텍스트 내부의 모든 터널은 여전히 원격 피어에 도달해야 하며, 그 조회는 전혀 다른 테이블에서 일어날 수 있습니다. 이 부분을 잘못하면 터널은 올라오고 경로는 있는 것처럼 보이지만 두 조회 중 하나가 잘못된 컨텍스트를 사용해 트래픽이 죽는, VRF 인식 IPsec에서 가장 혼란스러운 장애 중 하나가 발생합니다. 아래 네 단계를 순서대로 실행하고 두 목적지를 따로 적어 두십시오.
두 조회, 하나의 터널
바깥쪽 캡슐화된 패킷은 피어의 전송 주소로 향하며 어떤 보호도 존재하기 전에 라우팅됩니다. 안쪽 패킷은 고객 서버로 향하며 캡슐 해제 후 고객 컨텍스트 안에서 라우팅됩니다. 이는 두 목적지, 두 조회, 그리고 흔히 두 개의 다른 테이블입니다.
VRF 인식 IPsec에 관한 Cisco 문서는 이들을 전면 도어 VRF와 내부 VRF라고 부릅니다. 전면 도어는 암호화된 전송을 운반하고 내부 컨텍스트는 보호된 트래픽을 운반합니다. 터널에 고객 이름을 붙인다고 해서 두 경로 중 어느 것도 나타나지 않습니다.
따라서 구성을 변경하기 전에 네 가지 사실을 나열하십시오: 피어의 전송 주소와 그것에 도달하는 컨텍스트, 그다음 서버 프리픽스와 그것에 도달하는 컨텍스트입니다. 네 가지를 모두 채울 수 없다면 지금 추측하려는 것입니다. 이 영역에서 추측은 비쌉니다, 잘못된 테이블에 추가한 경로가 한 흐름을 동작시키면서 다른 흐름을 조용히 깨뜨릴 수 있기 때문입니다. 네 가지 사실을 모으는 데는 십 분이 걸리고 캡처 분석 하루를 아낍니다.
피어에 대한 전송 조회를 확인하십시오
전면 도어부터 시작하십시오, 피어에 도달하지 못하는 터널은 보호된 패킷을 하나도 통과시키지 못하기 때문입니다. IOS에서는 전역 테이블이 아니라 전송 VRF 내부에서 피어로 가는 경로를 물으십시오.
show ip route vrf wan-blue 203.0.113.20 show ip vrf brief show crypto ikev2 sa
첫 번째 명령은 그 컨텍스트에서 피어 주소에 도달할 수 있는지 답하고, 두 번째는 실제로 존재하는 VRF를 나열하며, 세 번째는 보안 연관이 형성되었는지 보여 줍니다. 전역 테이블에서만 확인되는 피어 주소가 전형적인 전면 도어 실수이며, 이는 결코 시작되지 않는 IKE 협상으로 나타납니다.
인터페이스 할당도 확인하십시오. 문서화된 동작은 터널의 전면 도어 VRF와 WAN 인터페이스의 VRF가 일치할 것을 요구합니다; 불일치는 패킷이 나가도록 하면서도 응답이 올바른 컨텍스트에서 처리되지 못하게 할 수 있습니다.
서버에 대한 내부 조회를 확인하십시오
전면 도어가 증명되면 고객 컨텍스트로 전환하여 서버 프리픽스에 대해 같은 질문을 하십시오. 이 조회가 캡슐 해제된 패킷을 앞으로 전달할 수 있는지 결정합니다.
show ip route vrf customer-blue 10.60.4.0 show crypto session detail
첫 번째 명령은 내부 경로를 보여 주고, 두 번째는 플랫폼이 세션에 연결한 컨텍스트와 함께 세션 상태를 보여 줍니다. 경로는 있는데 세션 세부 정보가 잘못된 내부 컨텍스트를 가리킨다면, 터널은 고객 프리픽스를 모르는 테이블로 전달하고 있는 것입니다.
전역 테이블의 경로는 두 조회 중 어느 것의 증거도 아닙니다. 전역 경로는 패킷이 VRF에 연결되지 않았을 때 사용되며, 고객 컨텍스트에 할당된 터널 인터페이스는 그 연결을 바꿉니다. 내부 경로가 없으면 패킷은 캡슐 해제된 뒤 전달 항목이 없어 버려지며, 이는 라우팅 실수가 아니라 패킷 손실처럼 보입니다.
설정을 모델이 기대하는 위치에 두십시오
같은 문서는 구성 모델을 구분하며, 한쪽에 속하는 설정이 다른 쪽에도 반드시 속하지는 않습니다. 터널 보호를 사용하는 터널 인터페이스에서는 내부 VRF가 터널 인터페이스에 정의됩니다. crypto map 기반 설계에서는 내부 VRF가 crypto map 항목의 일부입니다. 역할을 확인하지 않고 비슷한 이름의 명령을 모델 사이에서 옮기는 것이 동작하는 설계를 간헐적으로 만드는 길입니다.
라우팅과 정체성은 별개의 문제입니다. 도달 가능성은 장치가 받아들일 피어 프로필을 결코 대체하지 못하며, VRF 이름 변경은 제시하는 자격 증명을 바꾸어서는 안 됩니다. 변경 후에는 둘 다 확인하십시오, 잘못된 프로필과 협상하는 터널도 연관을 형성하고 아무것도 전달하지 않을 수 있기 때문입니다.
마지막으로 네 가지 사실과 그것을 증명한 명령을 변경 기록에 남기십시오. 다음 엔지니어는 터널을 물려받지 추론을 물려받지 않으며, 두 컨텍스트를 밝히는 짧은 메모는 아무도 갱신하지 않는 다이어그램보다 값어치가 큽니다.