OpenVPN이 나중에 OTP 세션을 끊는 이유: 재인증에 필요한 것

클라이언트 쪽에서 보면 작업 세션이 한 시간쯤 지나 갑자기 끊긴 것처럼 보입니다. 트레이 아이콘이 사라지고 터널이 다시 만들어지며, 로그에는 네트워크 오류가 아니라 인증 실패가 남습니다. 실제로 일어난 일은 세션이 재협상을 했고 두 번째 핸드셰이크가 클라이언트에 더 이상 유효한 사본이 없는 자격 증명을 요구한 것입니다. 로그인에서 통한 일회용 코드는 두 번째로 통하지 않으므로 재키는 설계대로 실패합니다.

해결책은 두 번째 핸드셰이크가 무엇을 제시해야 하는지에 대한 결정이지, 더 긴 재시도 타이머가 아닙니다.

클라이언트 관점에서 교환 과정을 따라가기

로그인할 때 클라이언트는 사용자 이름, 비밀번호, 토큰 장치의 코드를 보내고 서버가 그 조합을 받아들입니다. 그다음 세션은 재협상 트리거가 발생할 때까지 이어지며, 트리거는 기존 터널 안에서 새 TLS 핸드셰이크를 시작합니다. 그 핸드셰이크는 다시 인증을 요구합니다. 서버의 인증 경로가 비밀번호와 현재 일회용 코드를 기대한다면, 사용자가 직접 입력하지 않는 한 클라이언트에는 제시할 새 코드가 없습니다.

대부분의 클라이언트는 세션 중간에 프롬프트를 열지 않으므로 핸드셰이크가 시간 초과되고 터널이 끊깁니다. 사용자는 인증 프롬프트가 아니라 재연결을 보게 되고, 그래서 첫 보고가 보통 네트워크를 탓합니다.

auth-gen-token은 두 번째 질문에 누가 답하는지를 바꾼다

auth-gen-token 옵션을 쓰면 서버가 로그인 성공 후 토큰을 발급할 수 있고, 이후 재협상은 비밀번호와 코드를 반복하는 대신 그 토큰을 제시합니다. 설명서에는 토큰의 수명과 갱신 동작 이 문서화되어 있으며, 토큰은 자체 만료 시각을 가진 자격 증명으로 취급해야 합니다. 기본 경로에서는 서버가 외부 비밀번호 인증기를 다시 호출하지 않고 토큰을 직접 검증합니다.

외부 인증 연동이 있으면 그 분담이 달라집니다. 플러그인이 토큰 상태를 이해하고 자체 검사를 적용해야 합니다. 세션을 계속할지 결정하는 유일한 구성 요소가 더 이상 서버가 아니기 때문입니다. 토큰을 또 하나의 숫자 일회용 코드로 취급하는 것은 이 기능의 구현이 아닙니다.

계정 상태를 어떻게 다룰지 정하기

계정의 접근 권한보다 오래 사는 토큰은 정책의 구멍입니다. 비활성화된 계정, 제거된 그룹 구성원 자격, 폐기된 장치가 토큰이 아직 유효한 동안 어떻게 효력을 내는지 정하십시오. 토큰 수명을 짧게 하면 창이 좁아집니다. 명시적인 폐기 경로가 있으면 그 창은 의도된 것이 됩니다. 옵션을 켜기 전에 답을 적어 두십시오. 기본 경로는 재협상마다 외부 인증기를 참조하지 않기 때문입니다.

다중 서버 배포에서는 토큰 서명 비밀이 공유되어야 하며, 그렇지 않으면 클라이언트가 자기 토큰을 검증할 수 없는 노드로 보내질 수 있습니다.

로그인만이 아니라 만료와 재연결을 시험하기

테스트 프로필에서 재협상 간격을 줄여 두 번째 핸드셰이크가 눈앞에서 일어나게 한 다음 두 로그를 모두 따라가십시오. 토큰이 로그인 시 발급되고 재키 시 제시되며 설정된 수명에 따라 갱신되거나 재발급되는지 확인하십시오. 그다음 토큰 만료와 완전한 재연결을 강제하십시오. 깔끔하게 재연결하는 클라이언트도 재키 경로에서는 실패할 수 있기 때문입니다.

계정 제거 시험은 마지막에 하십시오. 그 사례가 작성한 정책이 실제로 강제되는지 아니면 문서로만 남았는지를 알려줍니다.

갱신을 꺼서 고치지 말기

양쪽 피어에서 재협상 간격을 영으로 두면 증상이 사라지고 키 순환도 함께 사라집니다. 그것은 아무도 검토하지 않은 정책 변경 뒤에 자격 증명 재생 문제를 숨기는 일입니다. 갱신은 유지하고, 사용자가 있는지에 따라 서버 발급 토큰과 새 대화형 챌린지 중에서 고르십시오.

재시도 타이머를 늘려도 이미 쓴 코드가 다시 유효해지지는 않습니다. 끊김을 늦추고 로그를 읽기 어렵게 만들 뿐입니다.