사용자 이름과 비밀번호는 운반체 안에서 이동하고, MSCHAPv2는 이동하는 방식을 지칭할 뿐입니다. 같은 계정 문자열이 코드 한 줄도 공유하지 않는 구성에도 나타나기 때문에, 클라이언트 프로필을 고르기 전에 어떤 터널이 그것을 나르는지 물으십시오. 건네받는 모든 프로필은 두 결정을 함께 부호화하며, 안내서가 그중 하나만 인쇄하는 경우에도 마찬가지입니다. 아래의 순서는 운영자가 추측 없이 답할 수 있는 것이며, 당신이 패킷을 잡지 않고 확인할 수 있는 것입니다.

인증은 터널 안에서 이동한다

VPN은 하나처럼 보이는 두 가지 결정, 즉 양측이 보호된 채널을 어떻게 세우는지와 사람이 그 안에서 신원을 어떻게 증명하는지를 내립니다. 두 번째는 사람이 입력하는 것이므로 안내서에 인쇄됩니다. 첫 번째는 어떤 클라이언트가 과연 동작할지를 정하며, 사람들이 건너뛰는 쪽이 바로 이것입니다. 운영자에게 먼저 운반체를, 다음으로 방식을 말해 달라고 순서대로 요청하십시오. 두 연결이 같은 계정 이름과 같은 비밀번호를 요구하면서도 로그인 상자 아래에서는 어떤 구현도 공유하지 않을 수 있습니다.

그래서 동료의 작동하는 휴대전화에서 복사한 설정이 서버가 두 자격 증명을 모두 받아들이는 경우에도 당신의 기기에서 실패할 수 있습니다. 차이는 자격 증명이 아니라 그것을 감싼 프로필이었습니다. 양쪽 모두 옳은데 아무것도 연결되지 않는다 는 대개 바로 이 혼동이며, 운반체의 이름이 불리면 곧 풀립니다.

같은 방식이 나타나는 세 곳

PPP에서 인증 단계는 링크가 존재할 때까지 기다리고, RFC 2759 는 MS-CHAPv2를 바로 그 단계로 정의하므로 이 방식은 L2TP 와 더 오래된 PPTP 구축에도 나타납니다. 터널이 먼저 종료되고 PPP 협상은 그 안에서 일어나므로, 실패한 PPP 단계는 서버 로그에서 터널이 설정된 것처럼 보이게 남길 수 있습니다. 자격 증명이 거부되었다고 결론 내리기 전에 그 두 단계를 따로 읽으십시오. 따라서 L2TP용으로 구성된 클라이언트는 완전히 올바르면서도 IKEv2만 말하는 게이트웨이에는 잘못된 클라이언트일 수 있습니다.

IKEv2는 대신 EAP-MSCHAPv2를 키 교환 안에 넣으므로, 같은 자격 증명이 다른 시점에 실패하고 세션 오류가 아니라 인증 오류로 드러납니다. Android의 플랫폼 IKEv2 프로필이 일상적인 예이며, PPP 옵션이 아니라 서버 인증서나 식별자를 요구합니다. 계정 이름은 두 구성에서 동일하므로 어느 쪽을 가졌는지 알려 줄 수 없습니다. 그것을 정하는 것은 운영자의 지원 프로토콜 목록뿐입니다.

TLS 기반 VPN은 자체적인 사용자 이름과 비밀번호 필드를 가지며 교환 어디에도 MS-CHAPv2가 없는 세 번째 구성을 더합니다. 따라서 화면이 익숙해 보이도록 만들어졌기 때문에, 비밀번호 상자가 보인다고 해서 그 뒤의 프로토콜에 대한 증거가 되지는 않습니다. 프로토콜은 클라이언트 창의 모양이 아니라 서버 문서로 확인하십시오.

당신에게 실제로 필요한 답들

요청은 절반만 답하기 어려운 목록으로 보내십시오. 터널 프로토콜, 그 안의 방식, 그리고 운영자가 당신의 플랫폼에서 지원하는 클라이언트를 물으십시오. 이어서 게이트웨이의 신원과 신뢰 설정, 계정 형식, 연결이 올라온 뒤 무엇에 도달할 수 있어야 하는지를 물으십시오.

처음 세 가지는 동작하는 프로필을 얻을 수 있는지를 정합니다. 마지막 세 가지는 그 프로필이 업무에 필요한 일을 하는지를 정합니다. 다음 사람도 같은 여섯 가지를 물을 것이므로 답변을 티켓에 붙여 두십시오. 답이 없는 곳에서는 그 공백을 운영자가 아직 내리지 않은 결정으로 다루고, 당신이 추론할 수 있는 것으로 다루지 마십시오.

What you ask forIf it is wrong, the symptom shows up as
Tunnel protocolNo profile can be built at all
Method inside the tunnelCredentials typed, then rejected
Gateway identityThe client refuses the server certificate
Account formatAuthentication fails only for some staff
Routes and DNSThe tunnel is up and nothing resolves

게이트웨이 검증을 느슨하게 하지 마십시오

서버는 클라이언트에게도 자기 신원을 증명하며, 교환의 그 절반은 장식이 아닙니다. 고집 센 프로필을 연결시키려고 인증서 검증을 끄는 것은 응답하는 모든 끝점을 받아들이는 일이며, 아무도 도달하려 하지 않은 곳까지 포함합니다. 그것은 또한 실제 불일치를 해결하지 않고 숨기므로, 실패를 더 늦고 덜 분명한 시점으로 밀어냅니다. 검증을 꺼야 하는 프로필은 자기가 검증할 수 없는 무언가를 가리키는 프로필입니다.

불일치는 보통 이름이며, 하나의 호스트 이름에 발급된 인증서는 프로필이 주소를 호출할 때 실패하기 때문입니다. 검증을 끄는 대신 이름을 호출하십시오. 사설 인증 기관은 기기에 루트가 한 번도 주어지지 않았을 때 실패하며, 해결책은 그 루트를 승인된 경로로 배포하는 것입니다. 관리 환경은 운영자가 신원과 신뢰 앵커를 제공하고 프로필이 둘 다를 참조하기를 기대합니다. 항목이 없을 때는 검증을 포기하는 대신 산출물을 요청하십시오.

프로필을 맞추고, 그다음 각 단계를 증명하십시오

운반체를 알게 되면 그 클라이언트의 문서화된 절차를 따르고 그것이 요구하는 항목만 입력하십시오. 존재하기 때문에 채우는 추가 항목도 여전히 잘못된 값이며, 필수 항목보다 늦게 실패합니다. 첫 연결에 성공한 뒤에는 나중의 편집을 동작한다고 알려진 것과 비교할 수 있도록 프로필을 변경하지 않고 저장하십시오.

그다음, 터널이 설정되고 사용자가 인증되고 할당된 주소와 경로가 나타나고 허용된 서비스 하나가 응답하는지를 단계별로 검증하십시오. 각 단계는 서버에 자기 로그 줄을 남기며, 그것을 순서대로 읽으면 모호한 불만이 구체적인 발견으로 바뀝니다. 플랫폼이 운영자가 설명한 구성을 더 이상 지원하지 않는다면 그것은 이전에 관한 대화이지, 기기에서 모든 레거시 옵션을 켤 이유가 아닙니다. 운반체, 방식, 프로필은 세 가지 별개의 답이며, 동작하는 연결에서는 셋이 모두 일치합니다.

관련 글