RADIUS Access-Challenge 후 VPN 로그인이 멈춥니다

비밀번호는 맞는데 VPN 로그인이 실패하고, RADIUS 서버는 시킨 대로 정확히 했을 수 있습니다. 게이트웨이는 아마 Access-Challenge를 받고 유용한 것을 아무것도 보여주지 않은 뒤 시간 초과가 되었거나 그 응답을 거부로 처리했습니다. 클라이언트 쪽에서는 잘못된 자격 증명이나 끊어진 터널처럼 보입니다. 원인은 대개 아무도 캡처하지 않은 대화의 한가운데에 있습니다.

한 번의 로그인, 두 번의 RADIUS 교환

백엔드가 두 번째 요소를 요구할 때 첫 요청에 수락이나 거부로 답하지 않습니다. 코드 11로 응답하고 사용자의 다음 응답을 기다리며, 게이트웨이는 그것을 후속 요청으로 되돌려 보내야 합니다. 그 후속 요청은 같은 인증 대화에 속하며 새로운 로그인 시도가 아닙니다.

정상 구성에서는 사용자에게 두 번째 프롬프트가 표시됩니다. 먼저 비밀번호, 다음으로 일회용 코드, 또는 운영자가 문서화했다면 하나의 통합 프롬프트입니다. 고장 난 구성에서는 두 번째 프롬프트가 나타나지 않고 로그인이 그냥 실패합니다.

추적해야 할 증상은 이것이며 클라이언트 쪽만으로도 쉽게 확인할 수 있습니다. VPN 클라이언트가 정확히 하나의 비밀만 요구한 뒤 유효한 줄 아는 비밀번호를 거부한다면 교환은 챌린지에서 끝났을 가능성이 큽니다.

챌린지가 실제로 나르는 것

RADIUS 사양은 4.4절에서 코드 11을 설명하고 여기서 중요한 두 속성을 허용합니다. Reply-Message는 사용자에게 보낼 텍스트를 담고, State는 서버가 그대로 돌려받고자 하는 불투명한 값을 담습니다. NAS는 State를 해석해서는 안 되고 변경 없이 반환해야 합니다.

후속 요청은 새 Identifier와 새 Request Authenticator를 사용하며 같은 State 값과 사용자의 응답을 함께 실어야 합니다. 서버는 그 State를 통해 대기 중인 챌린지와 연결하므로, 속성을 다시 만들거나 버리는 게이트웨이는 이 절차를 완료할 수 없습니다. 각 응답의 response authenticator도 검증되어야 하며, 그렇지 않으면 NAS는 패킷을 버려야 합니다.

4.4절은 대부분의 조용한 실패를 설명하는 세부 사항을 덧붙입니다. 챌린지를 지원할 수 없는 NAS는 Access-Challenge를 거부로 취급합니다. 게이트웨이의 VPN 서비스가 그 지원보다 오래되었거나 이를 생략한다면, 백엔드의 두 번째 요소 요청은 프롬프트 없이 즉시 «인증 실패»가 됩니다.

연쇄 요청이 사라지는 곳

첫 번째 용의자는 자격 증명이 아니라 프롬프트 경로입니다. 웹 로그인에 OTP 필드를 표시하는 포털이 VPN 서비스에도 자동으로 그렇게 하지는 않으며, 일부 게이트웨이는 그 기능을 알리는 클라이언트에만 챌린지를 전달합니다. 같은 계정을 두 진입점에서 시험해 보십시오. 포털은 되고 VPN이 안 된다면 전달을 보고 있는 것이지 토큰이 아닙니다.

두 번째 용의자는 입력 형식입니다. 공급업체가 문서화한 구분자 없이 비밀번호와 코드를 이어 붙이거나 저장된 자격 증명이 오래된 코드를 재생하도록 두면 잘못된 비밀번호와 똑같이 보이는 실패가 됩니다. 운영자가 문서화한 별도 프롬프트나 통합 형식을 사용하고 구분자를 임의로 만들지 마십시오.

릴리스별 결함은 존재하지만 몇 년 전 수정된 버전 목록은 오늘의 배포에 대한 진단이 아닙니다. 실제로 실행하는 소프트웨어의 릴리스 노트를 읽고 관찰한 교환 단계를 증거로 남기십시오.

한 번의 시도를 처음부터 끝까지 추적하십시오

서버 쪽 디버깅을 켠 채 한 번 재현하고 다른 모든 세션은 캡처 구간 밖에 두십시오:

$ sudo radsniff -i eth0 -x -f 'udp port 1812'
$ sudo freeradius -X
$ radtest alice 'password' 127.0.0.1 0 testing123

출력에서 한 줄이 아니라 대화의 모양을 찾으십시오. Identifier 3이 있는 첫 Access-Request, State를 나르는 Access-Challenge, 그다음 그 State를 반복하고 사용자의 응답을 포함하는 Identifier 4의 두 번째 Access-Request입니다. 두 번째 요청이 없으면 게이트웨이는 후속 조치를 하지 않은 것입니다. State 없이 도착하면 서버는 대기 중인 챌린지와 연결할 수 없어 보통 거부합니다.

추적을 공유할 때 자격 증명, 토큰, 불필요한 신원 데이터를 가리고, 여러 브라우저 탭의 재시도를 섞는 대신 한 번의 시도에서 나온 이벤트를 연관 지으십시오. 여기서는 타임스탬프가 여러분의 친구입니다. 클라이언트가 포기한 뒤 도착한 챌린지는 사용자에게 거부로, 로그에는 느린 응답으로 보입니다.

원하는 최종 상태는 완료되고 승인된 대화와 그에 이은 의도된 서비스 접근입니다. RADIUS 서버에서 응답이 도착했다는 사실은 그보다 훨씬 적은 것을 증명합니다.