L2TP 프로필의 어느 계층이 실제로 끊겼는가
IPsec 협상, L2TP 제어, PPP 인증, 주소 할당은 각각 다르게 실패합니다. 모든 레거시 옵션을 켜기 전에 계층을 특정하십시오.
설정 페이지를 가로지르지 말고 스택을 따라 내려가십시오: IPsec 협상, 다음 L2TP 제어, 다음 PPP 인증, 마지막으로 주소와 DNS 할당입니다. 각 계층에는 고유한 오류 서명과 고유한 추정 원인이 있습니다. 사용자 인증에서 실패하는 프로필은 더 일찍 시간 초과된 프로필이 결코 도달하지 못한 세 가지 검사를 이미 통과한 것입니다. 가장 먼저 확정할 것은 이 순서입니다.
같은 프로토콜 이름이 네 가지 다른 대화를 감추고 있습니다.
설정을 바꾸기 전에 계층을 이름 붙이십시오
IPsec 설정이 실패하면 공유 비밀, 알고리즘 또는 상대방 신원을 가리킵니다. 그 뒤에 L2TP 제어가 실패하면 터널 계층 자체를 시사하며, 이는 더 좁은 문제입니다. PPP 인증 실패는 계정이나 인증 방식을 지목합니다. 인증 후 주소나 DNS가 실패하면 전송은 동작했고 구성 교환은 동작하지 않았다는 뜻입니다.
클라이언트 버전, 운영 체제 버전, 사업자가 문서화한 설정을 기록하십시오. 이 세 가지가 없으면 모든 변경은 우연히 다른 것을 고칠 수도 있는 추측입니다.
프로필을 현재 클라이언트와 비교하십시오
저장된 프로필에는 현재 클라이언트가 더 이상 받아들이지 않는 공유 비밀, 인증 옵션 또는 엔드포인트가 들어 있을 수 있습니다. 일부 플랫폼은 L2TP/IPsec 지원을 완전히 폐기하거나 제거했고, 업데이트된 클라이언트는 서버 쪽 변경 없이 예전 IKE 동작을 버릴 수 있습니다. 저장된 값을 일 년 전에 동작하던 것과 비교하지 말고, 사업자의 현재 문서화된 요구 사항과 비교하십시오. 그 두 문서 사이의 간격이 보통 답이 있는 곳입니다.
캐시된 비밀이나 이름이 바뀐 계정은 보통 일반적인 프로필 업데이트 이상을 요구하지 않으며, 무엇이든 다시 설계하기 전에 둘 다 확인할 가치가 있습니다. 이것들은 저렴한 수정이며, 어떤 아키텍처 작업보다 먼저 배제해야 합니다.
레거시 옵션은 켠다고 돌아오지 않습니다
검증을 끄는 것은 신뢰 체인의 문제를 고치지 못하며, 어떤 포럼 스레드가 언급한다는 이유만으로 알고리즘을 켜는 것은 서버가 무엇을 받아들이는지에 대해 아무것도 증명하지 않습니다. 약한 IKE 제안은 대개 타당한 이유로 클라이언트에서 제거되며, 그중 하나를 다시 켜면 끊어진 것보다 더 나쁜 연결이 만들어집니다. 더 약한 터널은 수리가 아니라 같은 증상을 가진 새로운 문제입니다. 올바른 질문은 사업자가 지금 무엇을 지원하는가입니다.
모두 켜는 수리는 실제 고장보다 훨씬 많은 것을 바꾸고, 무엇이 그것을 고쳤는지 말할 수 없게 만듭니다.
마이그레이션을 프로젝트로 제시하십시오
배포가 더 이상 필요한 클라이언트를 지원하지 않으면 문서화되지 않은 예외를 보존하는 대신 사업자와 함께 교체를 계획하십시오. 접근 요구 사항, 신원, DNS 항목, 경로를 함께 옮기십시오. 새로운 핸드셰이크만으로는 그 권한 중 어느 것도 다시 만들어지지 않기 때문입니다. 그것들이 바로 동작하는 연결이 조용히 의존하던 부분입니다. 복구가 확인될 때까지 이전 프로필을 안전하게 보관하고, 그다음 오래된 자격 증명이 실제로 관리되는 곳에서 폐기하십시오. 그것을 그대로 두는 것이 모든 사람이 닫혔다고 믿은 훨씬 뒤까지 오래된 경로가 사용 가능하게 남는 방식입니다.
마이그레이션은 그 프로필이 무엇을 위한 것이었는지 적어 둘 시점이기도 합니다. 그렇지 않으면 다음 사람은 아무 설명 없이 동작하는 연결을 물려받습니다.
계층, 클라이언트 버전, 사업자의 현재 요구 사항을 확인하십시오. 그런 다음 이것이 수리인지 교체인지 결정하십시오.