PPP 기반 VPN에서 그 가정을 복사하지 않고 이전하기

VPN 이전은 사용자, 목적지, 이름 확인, 장애 시 동작이 모두 여전히 올바를 때 끝나며, 새 클라이언트가 초록색 아이콘을 보여줄 때 끝나는 것이 아니다. 오래된 PPP 기반 구축은 유일한 신원 확인을 겸한 공유 비밀, 방화벽이 허용 목록에 넣어 둔 고정 주소 풀, 서버가 밀어 넣는 DNS 접미사 같은, 기록된 적 없는 가정을 안고 있다. 이런 가정을 목록화하지 않고 프로토콜을 바꾸면 핸드셰이크는 되지만 경계가 존재하지 않는 터널이 만들어진다. 아래 순서는 내가 쓰는 순서이고, 마지막 단계가 팀들이 건너뛰는 단계다.

1단계: 기존 연결이 무엇을 제공하는지 목록화하십시오

목록은 기억하는 것이 아니라 적는 것이다. 지원 클라이언트, 인증 역할, 주소 풀, 보호 네트워크, DNS 요구 사항, 그리고 각 사용자 집단이 필요로 하는 서비스 권한을 기록하십시오.

L2TP/IPsec의 경우 두 계층을 명시적으로 분리하십시오. IPsec 피어 ID는 장비를 인증하고, PPP는 사용자를 인증하며 보통 CHAP 또는 MSCHAPv2를 씁니다.

오래된 구축이 가정을 숨기는 곳이 바로 이 분리 지점이다. 모든 클라이언트가 공유하는 사전 공유 키는 장비가 아니라 그룹을 인증한다, 그리고 대개 그것이 유일하게 한 번이라도 교체된 대상이다. PPP 계정이 실제 사용자별 통제라면 그렇게 말하십시오, 대체안은 공유 문자열이 아닌 무언가로 그 통제를 재현해야 하기 때문이다. 고정 원본 주소와 로컬 네트워크 예외도 기록하십시오, 그것들은 끊어지기 전까지 아무도 문서화하지 않는 의존성이기 때문이다.

2단계: 대체안을 의도적으로 설계하십시오

대체안 선택은 요구 사항 대 요구 사항 매핑이며, 조직이 지원하는 프로토콜과 유지 관리되는 클라이언트를 고르고 각 신원 및 접근 요구를 실제 메커니즘에 넣는 일이다. 공유 비밀이 자동으로 장비별 키나 인증서와 같지 않고, 사용자별 PPP 계정이 장비 인증서와 같지 않다.

가정이나 사무실 LAN과 겹치는 대체 풀은 암호 강도와 무관한 장애를 만들기 때문에 주소 범위를 무엇보다 먼저 조정하십시오. 풀을 기존 서비스용으로 만든 같은 목록과, 새 클라이언트가 기본으로 가정하는 것에 대고 확인하십시오. 보호 네트워크의 반환 경로를 확인하고, 새 클라이언트가 기존 클라이언트가 밀어 넣던 DNS 접미사를 밀어 넣거나 문서화할 수 있는지 확인하십시오. 이 두 항목이 프로토콜 변경 자체보다 이전 티켓을 더 많이 만든다.

3단계: 단계적으로 적용하고 허용과 거부를 모두 검증하십시오

대표 사용자 한 명과 대표 응용 프로그램 하나로 적용하십시오. 시험에 사설 DNS 확인을 포함하십시오, 주소에는 도달하지만 내부 이름을 확인하지 못하는 터널은 절반만 이전된 것이기 때문이다. 터널이 끊기면 무슨 일이 일어나야 하는지, 클라이언트가 그것을 강제하는지 같은 예상 사용 불가 상태도 포함하십시오.

다음으로 거부된 채로 남아야 하는 목적지를 시험하십시오. 넓은 임시 허용 규칙은 새 터널을 건강해 보이게 하면서 기존 서비스가 적용하던 권한 경계를 조용히 제거할 수 있고, 감사 전까지 아무도 알아차리지 못한다. 같은 클라이언트에서, 같은 세션에서 허용과 거부 결과를 나란히 비교하십시오. 두 열이 설계와 일치할 때까지 기존 서비스를 계속 돌리십시오.

관리자 접근을 옮기기 전에, 변경 중인 터널에 의존하지 않는 승인된 복구 경로가 있는지 확인하십시오.

4단계: 기존 ID를 폐기하십시오

기존 ID를 제대로 폐기한다는 것은 더 이상 필요 없는 사용자와 장비 자격 증명을 그것을 소유한 서비스에서 폐기하고, 의존성이 남지 않으면 기존 프로필과 리스너를 제거하는 것이다. 로컬 파일 삭제는 다른 곳의 사본을 폐기하지 않으며, 기존 공유 비밀을 여전히 받아들이는 기존 리스너는 감시되지 않는 문이다.

이 지점에서는 속도를 늦출 가치가 있다. 노트북에서 해제한 클라이언트 프로필은 폐기된 자격 증명이 아니며, 자격 증명은 서버에 살아 있고 서버가 받아들이기를 멈출 때까지 유효하다. 기존 구성의 다른 사본을 찾으십시오, 시험 장비, 잊힌 휴대폰, 누군가 보관한 설치 프로그램이다. 그리고 리스너 종료를 기존 서비스가 실제로 끝나는 순간으로 보십시오, 그때까지 이전에는 정문이 두 개다.

수용 기록은 첫 단계 목록에 열을 하나 더한 것으로, 새 설계가 각 행에 무엇을 하는지, 그것을 어떻게 검증했는지 적는다. 그러면 프로토콜 업그레이드가 근거를 갖춘 서비스 요구 사항이 된다.

결과를 프로토콜 이름이 아니라 서비스가 필요로 하는 것에 묶어 두십시오, 기존 가정을 복사해 넣은 현대적 프로토콜은 틀이 더 좋아졌을 뿐 같은 위험이다. RFC 3193은 L2TP가 IPsec 위로 어떻게 운반되는지 설명하는데, 두 계층이 항상 별개의 결정이었다는 유용한 알림이다. 목록에 설명할 수 없는 행이 있으면 멈추고 무엇이 그것에 의존하는지 알아내십시오. 목록이 지루해지면 이전은 끝난 것이다.