GET VPN 멤버를 위한 안정적인 등록 소스 선택

누군가 그룹 멤버의 등록을 루프백 주소로 돌리고 GET VPN의 불안정이 해결되었다고 선언합니다. 때로는 사실입니다. 그러나 흔히 루프백은 멤버 자신의 라우팅 테이블에서만 도달할 수 있고 다른 곳에서는 닿지 않으므로, 그것을 실어 나르던 업링크가 다음에 흔들리면 등록은 다시 깨집니다. 등록 주소는 제어 평면의 식별자이며, 양방향에 실제 경로가 있을 때만 도움이 됩니다. 그것을 의도적으로 고르는 일은 가치가 있고, 통설이 말하는 것보다 작은 변경입니다.

등록 주소가 식별하는 것

GDOI 배포에서 그룹 멤버는 키 서버에 등록하고 그로부터 그룹 정책을 받습니다. 키 서버가 기록하는 주소가 그 대화에서 멤버의 식별자입니다.

이 식별자는 제어 대화를 포괄합니다. 등록, 키 갱신, 정책 다운로드가 포함됩니다. 그것은 고객 트래픽의 소스가 되지 않습니다그리고 어떤 인터페이스가 어떤 흐름을 보호하는지도 바꾸지 않습니다.

이 둘을 분리하는 것이 첫 단계입니다. 이 설정을 둘러싼 혼란의 대부분은 제어 평면의 변경이 데이터 평면의 증상을 고쳐 주리라는 기대에서 나옵니다.

루프백은 경로만큼만 쓸모가 있습니다

루프백은 물리 업링크 하나가 실패해도 사라지지 않는 논리 주소를 멤버에게 줍니다. 키 서버로 가는 경로가 여러 개인 라우터에서는 실제 이점입니다.

하지만 그것도 그저 주소일 뿐입니다. 키 서버에 되돌아갈 경로가 없으면 등록은 이전과 똑같이 실패합니다. 멤버의 라우팅 테이블이 하나의 업링크로만 키 서버에 도달한다면 루프백은 안정적이지만 경로는 그렇지 않습니다.

살려 두려는 각 업링크를 통해 양방향 도달성을 확인하세요. 관리적으로 살아 있는 루프백은 전달에 대해 아무것도 증명하지 못하며, 장애는 인터페이스 문제가 아니라 도달할 수 없는 키 서버로 나타납니다. 확인은 가정이 아니라 업링크별 명령으로 적으세요. 그러면 다음 변경 창은 다이어그램이 아니라 증거에서 시작됩니다.

제어와 보호 트래픽을 분리하기

Cisco의 GDOI 바이패스 안내서는 등록 인터페이스와 등록 및 바이패스 처리의 관계를 설명합니다. 하나의 표현을 보편적인 명령으로 다루지 말고 실제로 운영하는 릴리스의 동작을 읽으세요.

제어 경로에서 필터링과 변환을 검토하고, 키 관리 트래픽이 가져오려는 바로 그 그룹 정책에 의존하는 보호 정책으로 실수로 휩쓸려 들어가지 않았는지 확인하세요. 이런 순환 의존은 동작하던 배포가 정책 변경 후 실패하게 만드는 전형적인 방법입니다.

데이터 평면 정책은 별개의 설계입니다. 등록이 어디서 오는지 바꾸어도 보호되는 흐름, 선택자, 바이패스 규칙은 있던 자리에 그대로 남습니다.

전환 과정에서 식별자 확인하기

변경 전에 그룹, 선택한 등록 주소, 키 서버 목적지, 라우팅 컨텍스트, 허용된 제어 경로를 기록하세요. 승인된 업링크 변경 후에 키 서버의 등록 멤버 보기와 멤버의 제어 상태를 다시 확인하세요.

보고 싶은 것은 의도한 논리적 종단점이 여전히 도달 가능하고 설계한 대로 표현되는 모습입니다. 보고 싶지 않은 것은 의도하지 않은 주소에서 생기는 두 번째 등록이며, 멤버 항목의 중복은 바로 그렇게 생깁니다.

그다음 보호되는 애플리케이션 트래픽을 따로 시험하세요. 전송이 성공해도 다음 키 갱신이 갈 곳이 없을 수 있고, 등록 성공은 특정 흐름이 올바르게 선택되고 라우팅되는지에 대해 아무것도 말해 주지 않습니다.

안정적인 소스가 고치지 못하는 것

이전의 잘못된 구성으로 생긴 멤버 항목 중복을 제거하지 못합니다. 멤버와 키 서버 사이의 정책 불일치로 생긴 키 갱신 실패를 복구하지 못합니다. 키 서버로 가는 유일한 경로를 없앤 물리 경로 장애를 견디지 못합니다.

그것이 하는 일은 변수 하나를 없애는 것입니다. 업링크 주소가 바뀌어도 식별자가 더는 바뀌지 않습니다. 그것은 가질 만한 가치가 있고, 설계 전체가 아니라 설계의 한 줄입니다.

작업 순서는 제어 경로를 이름 붙이고, 양방향 경로가 있는 주소를 고르고, 키 서버의 보기를 확인한 뒤, 보호 트래픽을 따로 시험하는 것입니다. 그래도 등록이 실패한다면 루프백이 문제였던 적은 없습니다.