OpenVPN auth-nocache: 다음 로그인에서 무슨 일이 일어나는가
OpenVPN의 메모리 내 자격 증명을 지우면 다음 인증이 달라집니다. 대화형 클라이언트, 자격 증명 파일, 서비스는 각각 다른 처리가 필요합니다.
auth-nocache를 켜면 비밀번호 캐싱 경고가 사라지고, OpenVPN이 다음 재협상을 위해 보관하던 자격 증명 사본도 함께 사라집니다. 그것이 프롬프트가 될지, 조용한 재시도가 될지, 끊긴 터널이 될지는 두 번째로 자격 증명이 어디서 오느냐에 달려 있습니다. 따라서 이것은 배포 형태 간의 비교이지 이 옵션에 대한 판결이 아닙니다. 어떤 프로필을 편집하기 전에 실제로 운영하는 형태를 읽으십시오.
두 번째 자격 증명 집합은 어디서 와야 하는가
OpenVPN은 auth-user-pass와 askpass가 수집한 비밀에 auth-nocache를 적용하며, 한 번 사용되면 프로세스는 다음 핸드셰이크를 위해 보관하지 않고 버립니다. 재협상은 타이머로, 기본적으로 한 시간에 한 번 도착하므로 두 번째 요청은 비밀번호를 입력한 사람이 떠난 훨씬 뒤에 도착합니다. 그 간격이 전부입니다. 캐시를 켜 두면 클라이언트는 아무에게도 묻지 않고 저장된 사본을 재생하고, 캐시를 끄면 비밀을 다른 곳에서 찾거나 실패해야 합니다.
그러므로 그 순간 비밀이 올 수 있는 모든 곳을 나열하고, 그중 어디가 호스트에 실제로 있는지 솔직하게 보십시오. 터미널 앞의 사람, auth-user-pass나 askpass가 읽을 수 있는 파일, 서버가 발급한 세션 토큰, 이 세 가지가 여기서 중요합니다. 어느 것도 없으면 재협상은 변경 후 한 시간 뒤에 실패하며, 변경한 그 순간에 실패하지는 않습니다.
세 가지 형태, 세 가지 실패 지점
앞에 사람이 있는 데스크톱 클라이언트는 가벼운 경우로, 프롬프트가 돌아오고 누군가 비밀번호를 다시 입력하며 비용은 주의력입니다. 터미널 없이 OpenVPN을 실행하는 서비스, 컨테이너, 라우터는 가혹한 경우로, 응답할 사람이 없고 한때 조용했던 재연결이 이제 터널을 끝냅니다. 하이브리드는 둘 사이에 있으며, 프롬프트에 응답할 수 있던 세션이 사라질 때까지 데스크톱 경우처럼 행동합니다. 이들을 가르는 것은 GUI 설치 여부가 아니라 재협상 시점에 자격 증명 공급원이 있는지입니다.
무엇이든 바꾸기 전에, 온라인에서 찾는 조언은 거의 항상 첫 번째를 위한 것이므로 배포를 이 세 가지 중 하나에 대응시키십시오. 데스크톱의 답을 터미널 없는 서비스에 적용하는 것이, 몇 달 동안 작동하던 터널이 매시간 끊기기 시작하는 방식입니다.
지시문인가 플래그인가: 하나를 고르고 어느 것을 썼는지 아십시오
프로필 안에서 auth-nocache는 별도의 줄이며, 프로필을 명시적으로 지정하는 호출에서는 그 명령줄의 플래그이고, OpenVPN 설명서는 두 형태를 모두 나열합니다. 둘 다 자격 증명 보존에 같은 일을 하고, 어느 것도 인터페이스 유형을 건드리지 않으며 같은 로그에 있는 무관한 경고를 고치지 않습니다. 차이는 지속성으로, 플래그는 그 실행만 덮으므로 unit 파일이나 래퍼 스크립트에서 다시 시작한 서비스는 래퍼가 그것도 전달하지 않는 한 갖지 못합니다.
auth-nocache
openvpn --config /path/client.ovpn --auth-nocache어떤 산출물이 설정을 소유하는지 정하고, 거기서만 바꾸고 다른 곳에서는 바꾸지 마십시오. 노트북에서 편집한 프로필과 플래그로 그것을 덮어쓰는 systemd unit이 재부팅 후 모순된 동작을 만드는 조합입니다.
자격 증명 파일은 비밀을 삭제하지 않고 옮긴다
auth-user-pass를 파일로 지정하면 이후의 모든 재협상에 공급원이 생기고, 비밀번호를 재부팅을 견디는 곳에 두게 됩니다. 그 파일을 누가 읽을 수 있는지, 권한을 내려놓은 뒤에도 데몬이 읽을 수 있는지, 파일 시스템이 읽기 전용으로 마운트되거나 컨테이너 뷰가 경로를 숨기면 어떻게 되는지 물으십시오. 디스크의 비밀과 메모리의 비밀은 다른 문제이며, 한쪽을 해결해도 다른 쪽은 그대로 남습니다. 건너뛰는 단계가 바로 로테이션으로, 서버에서 바꾸고 파일에서는 바꾸지 않은 비밀번호는 네트워크 장애처럼 읽히는 실패를 만듭니다.
파일은 데몬을 실행하는 계정의 소유로 두고, 다른 누구도 읽지 못하게 하며, 호스트를 떠나는 백업 밖에 두십시오. OpenVPN의 서버 측 auth-gen-token 옵션은 로그인 성공 후 클라이언트에 세션 토큰을 주는데, 이는 계정 비밀번호보다 주변에 두기 작은 물건입니다. 어떤 경우든, 파일은 보통 만든 사람보다 오래 살기 때문에 로테이션 단계를 파일 옆에 적어 두십시오.
재협상을 늘리는 것은 비용을 옮길 뿐 없애지 않는다
다른 제안은 프롬프트가 무시할 만큼 드물어질 때까지 reneg-sec를 올리는 것입니다. 그것은 세션의 키 로테이션 일정을 다시 쓰고 같은 자격 증명 문제를 더 늦고 덜 예측 가능한 시점으로 밀어낼 뿐이며, 자격 증명 공급원을 만들지 않습니다. 이유가 있어 일정대로 키를 갱신하는 정책을 비밀번호 입력을 피하려고 완화해서는 안 됩니다.
살아 있는 세션은 아무것도 증명하지 않으므로, 지금 앉아 있는 세션이 아니라 재연결을 시험하십시오. 서버 쪽에서 터널을 떨어뜨리거나 클라이언트 서비스를 다시 시작하고, 키보드 앞에 아무도 없을 때 다음 재협상이 무엇을 하는지 보십시오. 다시 연결되면 비밀을 공급한 메커니즘을 지목하고, 연결되지 않으면 이 호스트에서 이 옵션의 실제 비용을 찾은 것입니다. 어느 결과든 시험 중에 통했던 답이 아니라 장애 중에도 통하는 답을 줍니다.
관리되는 플리트에서는 배포를 소유한 사람이, 자격 증명이 어디서 오는지, 어디에 저장되는지, 누가 로테이션하는지 세 가지를 말할 수 있어야 합니다. 그 답 중 하나라도 호스트를 설정한 사람이라면, 그곳에서는 아직 이 옵션이 안전하지 않습니다.