MSCHAPv2는 VPN 프로토콜이 아닙니다: 먼저 터널을 물으십시오
비밀번호와 MSCHAPv2라는 단어만으로는 연결이 되지 않습니다. 어떤 터널이 이 교환을 나르는지 먼저 묻고, 그에 맞춰 클라이언트 프로필을 맞추십시오.
사용자 이름과 비밀번호는 운반체 안에서 이동하고, 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 for | If it is wrong, the symptom shows up as |
|---|---|
| Tunnel protocol | No profile can be built at all |
| Method inside the tunnel | Credentials typed, then rejected |
| Gateway identity | The client refuses the server certificate |
| Account format | Authentication fails only for some staff |
| Routes and DNS | The tunnel is up and nothing resolves |
게이트웨이 검증을 느슨하게 하지 마십시오
서버는 클라이언트에게도 자기 신원을 증명하며, 교환의 그 절반은 장식이 아닙니다. 고집 센 프로필을 연결시키려고 인증서 검증을 끄는 것은 응답하는 모든 끝점을 받아들이는 일이며, 아무도 도달하려 하지 않은 곳까지 포함합니다. 그것은 또한 실제 불일치를 해결하지 않고 숨기므로, 실패를 더 늦고 덜 분명한 시점으로 밀어냅니다. 검증을 꺼야 하는 프로필은 자기가 검증할 수 없는 무언가를 가리키는 프로필입니다.
불일치는 보통 이름이며, 하나의 호스트 이름에 발급된 인증서는 프로필이 주소를 호출할 때 실패하기 때문입니다. 검증을 끄는 대신 이름을 호출하십시오. 사설 인증 기관은 기기에 루트가 한 번도 주어지지 않았을 때 실패하며, 해결책은 그 루트를 승인된 경로로 배포하는 것입니다. 관리 환경은 운영자가 신원과 신뢰 앵커를 제공하고 프로필이 둘 다를 참조하기를 기대합니다. 항목이 없을 때는 검증을 포기하는 대신 산출물을 요청하십시오.
프로필을 맞추고, 그다음 각 단계를 증명하십시오
운반체를 알게 되면 그 클라이언트의 문서화된 절차를 따르고 그것이 요구하는 항목만 입력하십시오. 존재하기 때문에 채우는 추가 항목도 여전히 잘못된 값이며, 필수 항목보다 늦게 실패합니다. 첫 연결에 성공한 뒤에는 나중의 편집을 동작한다고 알려진 것과 비교할 수 있도록 프로필을 변경하지 않고 저장하십시오.
그다음, 터널이 설정되고 사용자가 인증되고 할당된 주소와 경로가 나타나고 허용된 서비스 하나가 응답하는지를 단계별로 검증하십시오. 각 단계는 서버에 자기 로그 줄을 남기며, 그것을 순서대로 읽으면 모호한 불만이 구체적인 발견으로 바뀝니다. 플랫폼이 운영자가 설명한 구성을 더 이상 지원하지 않는다면 그것은 이전에 관한 대화이지, 기기에서 모든 레거시 옵션을 켤 이유가 아닙니다. 운반체, 방식, 프로필은 세 가지 별개의 답이며, 동작하는 연결에서는 셋이 모두 일치합니다.