L2TP/IPsec 오류 789, 720 또는 691: 먼저 올바른 단계를 고치십시오

Windows 11은 L2TP/IPsec의 각 단계마다 다른 번호를 보고하며, 그 번호는 실패를 평가하는 것이 아니라 단계를 표시합니다. 789는 PPP 링크가 존재하기 전에 실패하고, 720은 링크가 올라오는 동안 실패하며, 691은 링크가 올라간 뒤 자격 증명이 거부되면 실패합니다. 유용한 결정은 어떤 수정이 가장 인기 있는지가 아니라, 코드가 어느 단계에 도달했음을 증명하는지입니다. 먼저 그것을 읽고, 다음 시도마다 한 계층만 바꾸어 다음 코드가 여전히 무언가를 알려 주게 하십시오.

코드를 결함 목록이 아니라 단계로 읽으십시오

L2TP 연결은 정해진 순서로 세 경계를 넘습니다. IKE는 UDP 500에서 보안 연결을 협상하고, NAT 통과가 그 트래픽을 UDP 4500으로 옮기며, 그다음에야 L2TP 터널이 사용자를 인증하고 주소를 할당하는 PPP 세션을 전달합니다.

이 순서가 바뀌는 오류 코드를 유용한 증거로 만듭니다. 789에서 720으로 가는 것은 IPsec이 이제 협상하고 실패가 링크 설정으로 옮겨졌다는 뜻입니다. 720에서 691로 가는 것은 링크가 올라왔고 게이트웨이가 신원을 거부했다는 뜻입니다. 다섯 가지 수정을 한꺼번에 적용하면 그 신호를 잃고 어느 변경이 효과가 있었는지 알 수 없습니다.

789: 경로와 로컬 정책 중에서 선택하십시오

코드 789는 초기 보안 협상 중의 처리 오류입니다. IPsec은 사용 가능한 연결을 한 번도 만들지 못했습니다, 따라서 계정은 아직 시험되지 않았습니다. 계정이 아니라 경로와 공유 키부터 시작하십시오.

UDP 500과 UDP 4500이 서버에 도달하는지, 미리 공유한 키가 대소문자와 끝의 공백까지 바이트 단위로 일치하는지 확인하십시오. 서버가 NAT 뒤에 있으면 Windows에 문서화된 레지스트리 값도 필요할 수 있습니다. 서버가 NAT 뒤에 있으면 1, 양쪽 끝이 모두 그러면 2를 사용하고, 정책 에이전트가 시작할 때 값을 읽으므로 다시 시작하십시오:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent" /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 1 /f

더 무거운 어댑터 복구는 다른 분기에 속합니다. Wi-Fi 장치와 WAN 미니포트를 제거한 뒤 하드웨어를 다시 검색하는 것은 로컬 IPsec 스택 자체가 손상되어 다른 VPN 유형도 같은 방식으로 실패할 때 정당화됩니다. 하나의 L2TP 서버만 실패하고 다른 모든 네트워크 경로가 작동할 때는 헛된 노력입니다.

720: 이 어댑터와 서버 풀 중에서 선택하십시오

오류 720은 원격 컴퓨터에 연결할 수 없었다고 보고하며, IPsec이 성공한 뒤 나타납니다. 터널은 인터페이스를 올리거나 주소를 얻는 지점에 도달한 뒤 멈췄습니다. 그래서 이것은 로컬 어댑터 문제이거나 서버 용량 문제가 됩니다.

결정에는 영향 범위를 사용하십시오. Windows 컴퓨터 한 대의 실패는 불량 WAN 미니포트, 중지된 Remote Access 서비스 또는 손상된 연결 프로필을 가리킵니다. 여러 클라이언트가 동시에 실패하면 주소 풀 고갈, 중지된 RRAS 서비스 또는 더 이상 클라이언트 서브넷과 맞지 않는 풀이라는 서버 문제를 가리킵니다. 패턴이 가리키는 쪽을 다른 쪽을 바꾸기 전에 고치십시오.

단일 클라이언트 분기에서는 WAN 미니포트를 한 번 제거하고 하드웨어 변경을 검색한 뒤 다시 시작하고 재시도하십시오. 서버 분기에서는 작동하는 어댑터를 다시 설치해도 서버에 없는 주소를 만들 수는 없으므로 클라이언트 대신 풀과 서비스 상태를 확인하십시오.

691: 자격 증명과 중지된 도우미 중에서 선택하십시오

코드 691은 인증 거부이며, 잘못된 비밀번호로 가장 자주 오해되는 코드입니다. 터널은 올라가 있고, 게이트웨이는 신원을 보았고 그것을 거부했습니다. 원인은 여전히 비밀번호 필드 밖에 있을 수 있습니다.

먼저 도메인 필드를 확인하고, 다음으로 비밀번호의 정확한 문자를 확인하십시오. 공백, 따옴표 또는 셸 특수 문자를 포함한 비밀번호는 서버에 도달하기 전에 손상될 수 있으며, Linux에서는, pppd는 E=691과 동일한 거부를 인용 부호 없는 값이나 누락된 도메인에 대해 보고합니다. 붙여넣지 말고 암호를 다시 입력하고, 이전 값을 보유할 수 있는 저장된 자격 증명을 지우십시오.

사람들이 놓치는 분기는 중지된 도우미 서비스입니다. 공급업체 클라이언트가 자격 증명을 게이트웨이로 전달하기 위해 자체 서비스에 의존할 때, 비활성화되었거나 충돌한 서비스는 비밀번호가 맞더라도 691을 생성합니다. 계정을 재설정하기 전에, 특히 다시 시작하거나 업데이트한 뒤에 공급업체 서비스 상태를 확인하십시오.

분기를 구분하려면 같은 사용자 이름을 다른 작동하는 VPN 프로필이나 RADIUS 테스트 계정에서 시험하십시오. 그것이 성공하면 자격 증명은 정상이고 로컬 클라이언트 경로가 의심스럽습니다. 같은 방식으로 실패하면 계정이나 게이트웨이 정책이 문제입니다.

시도마다 한 계층만 바꾸십시오

바깥에서 안으로 작업하십시오: 도달 가능성과 NAT 통과, 다음으로 미리 공유한 키, 다음으로 로컬 어댑터 스택, 다음으로 자격 증명, 다음으로 서버 풀과 서비스입니다. 이 순서는 코드가 설명하는 단계를 따르며 각 결과를 하나의 변경에 귀속시킬 수 있게 유지합니다.

각 시도 전후의 코드, 클라이언트 빌드, 서버와 클라이언트 중 무엇을 바꿨는지에 대한 짧은 기록을 남기십시오. 789, 다음 720, 다음 691 같은 순서는 진행 지도이며, 같은 코드가 두 번 나오면 마지막 변경이 그 단계를 다루지 않았다는 뜻입니다. Windows를 다시 설치하면 이 지도가 지워지고 게이트웨이에 사는 실패를 거의 고치지 못합니다.

코드가 더 이상 바뀌지 않으면 일을 바꾸는 것을 멈추십시오. 현재 코드, 서버 주소, 인증 방법, 시도 시각을 기록한 뒤 그 기록을 작동하는 클라이언트와 비교하십시오. 두 기록의 차이는 보통 사람들이 기본적으로 시도하는 수정 목록보다 작습니다.