하나의 오류, 세 가지 비밀: 어떤 VPN 자격 증명이 실패했는가?
클라이언트는 모든 단계에서 같은 오류를 보여 줍니다. 아무도 확인하지 않은 비밀번호를 재설정하기 전에 연결, 사용자 교환, 방식을 읽어 보십시오.
«인증 실패»는 서버 인증서, 머신의 사전 공유 키 또는 사용자 비밀번호를 가리킬 수 있습니다. 어느 것인지는 프로토콜에 따라 다르며, 프로토콜마다 서로 다른 비밀 집합을 정의하기 때문입니다. 잘못된 쪽을 재설정하면 오류는 그대로 남습니다. 출구는 무엇이든 편집하기 전에 프로토콜이 몇 가지 증명을 요구하는지 먼저 확정하는 것입니다.
반대 방향을 가리키는 두 가지 증명
터널은 올바른 게이트웨이에 도달했는지와 별개로 사용자가 누구인지에 답해야 합니다. 게이트웨이 증명은 머신 수준으로, 서버 인증서, 사전 공유 키 또는 정적 공개 키입니다. 사용자 증명은 사람 수준으로, 비밀번호, 토큰, 클라이언트 인증서 또는 아무것도 아닙니다. 이 둘은 신뢰의 반대 방향이며 서로 다른 재료를 소비합니다.
IKEv2는 게이트웨이 증명을 IKE_AUTH 안에서 수행하고, EAP를 사용할 때는 그 뒤에 사용자 증명을 별도 교환에서 실행합니다. IKEv2 사양은 이 둘을 별개의 절로 유지하며, 하나의 메시지가 두 라운드를 모두 다룰 때 어디를 봐야 하는지 보여 주는 강한 단서입니다.
메시지가 아니라 단계를 읽으십시오
클라이언트는 어느 단계에서 실패했든 하나의 오류 문자열만 보여 줍니다, 따라서 문자열 자체는 거의 아무 정보도 담지 않습니다. 정보를 담는 것은 각 단계에서 확인할 수 있는 상태, 즉 연결이 존재하는지, 사용자 교환이 시작되었는지, 클라이언트가 게이트웨이가 원한 방식을 제시했는지입니다. 표는 단계를 프로토콜 이름이 아니라 그런 방식으로 정렬합니다.
| Stage that failed | Evidence you can inspect | What a password change cannot fix |
|---|---|---|
| The machine proof | no security association in the state list | a mismatched pre-shared key or an untrusted chain |
| The user proof | an association is up while PPP or EAP reports failure | an expired token, a locked account, a missing client key |
| The client's method support | the client offers no method the gateway accepts | a client without the required EAP or key material |
| The server's policy | the gateway rejects before any user exchange starts | a policy that requires a certificate the profile lacks |
사용자가 다시 입력할 수 있는 자격 증명에 관한 것은 둘째 줄뿐입니다. 나머지 셋은 구성 사실이며, 이 불일치가 이런 보고서가 아무것도 바꾸지 않는 비밀번호 재설정으로 끝나는 이유입니다. 어떤 필드든 건드리기 전에 증거와 맞는 줄을 읽으십시오.
두 비밀을 가진 프로토콜은 패를 드러냅니다
L2TP을 IPsec 위에서 쓰면 두 검사가 서로 다른 프로세스에서 일어나기 때문에 개수가 보입니다. IPsec 계층이 사전 공유 키나 인증서로 먼저 올라와야 하고, 그다음에야 그 안의 PPP가 사용자 로그인을 시도합니다.
머신 비밀이 틀리면 연결이 만들어지지 않고 사용자 자격 증명은 시도조차 되지 않습니다. 머신 비밀이 맞고 사용자 비밀이 틀리면 연결은 존재하고, 터널이 이미 올라온 뒤에 PPP가 로그인을 거부합니다. 둘 다 서로 다른 두 사건에서 화면에 같은 메시지를 냅니다.
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pager비어 있는 연결 목록은 사용자 계층을 즉시 배제하므로 비밀번호보다 먼저 확인하십시오. PPP 실패가 반복되는 확립된 연결은 반대 방향, 즉 사용자 계층이나 그 안의 인증 프로토콜을 가리킵니다. 두 결론 모두 클라이언트의 오류 문구에서는 얻을 수 없습니다.
비밀번호만 쓰는 접속이 실제로 무엇에 달려 있는가
비밀번호만 쓰는 접속은 L2TP, PPTP, SSTP, EAP를 쓰는 IKEv2에서 흔합니다. WireGuard에는 상대가 사용자가 아니라 키이기 때문에 그러한 선택지가 아예 없습니다. OpenVPN에서는 답이 서버의 클라이언트 인증서 요구에서 나오는데, 인증서와 비밀번호를 모두 요구하는 게이트웨이는 필드에 무엇을 입력하든 비밀번호만 쓰는 클라이언트를 계속 거부합니다.
필요한 구성 요소는 같은 답에서 나옵니다. IKEv2에서 비밀번호 로그인은 EAP를 말하는 클라이언트를 요구하고, 인증서 로그인은 클라이언트의 개인 키와 서버의 체인이 필요합니다. 잘못된 쪽을 설치하면 인증 방식 자체가 빠졌는데도 자격 증명 오류처럼 읽힙니다.
한 가지만 바꾸고 다시 시험하십시오
먼저 어떤 프로토콜이 돌고 있는지, 비밀을 몇 개 정의하는지, 그중 어느 것이 사용자가 아니라 머신에 속하는지라는 세 가지 사실을 확정하십시오. 머신은 첫 단계에서 실패하고 사람은 둘째 단계에서 실패하며, 이 둘을 혼동하는 것이 이 문제의 전부입니다.
그다음 정확히 한 가지만 바꾸고 같은 클라이언트에서 다시 시험하십시오. 그 규율이 혼란스러운 실패를 다음 사람에게 설명할 수 있는 수정으로 바꿔 주며, 그것은 아무도 설명하지 못하는 잘 돌아가는 연결보다 유용합니다.