OpenVPN 패킷 HMAC 인증 실패: 어느 계층인가

같은 용어로 보고되는 두 가지 실패이지만 공통점은 거의 없다. 하나는 인증 태그가 검증되지 않은 패킷이고, 다른 하나는 자격 증명이 거부된 사람이다. 전자를 후자로 취급하면 결코 문제가 아니었던 암호를 찾아 나서게 된다.

메시지는 계층을 지목하며, 유용한 작업은 어떤 자료를 교체하기 전에 어느 계층인지 결정하는 것이다. 후보들을 나란히 비교하는 것이 차이를 보는 가장 빠른 방법이다.

한 단어를 공유하는 두 가지 실패

패킷 인증 오류는 트래픽을 처리하는 중, 수신한 패킷의 태그나 다이제스트가 수신 측 계산값과 일치하지 않을 때 발생한다. 계정 거부는 로그인 교환이 분석된 뒤에 일어나며, 패킷이 아니라 사용자를 지목한다. 세 번째 메시지는 들어오는 패킷에서 HMAC을 찾을 수 없다는 것으로, 그 패킷이 기대한 인증 요소 없이 도착했기 때문에 또 다르다. 전체 로그 접두사가 세 가지 중 어느 것인지 알려 주지만, 티켓에 오류를 붙여 넣을 때 그 접두사는 대개 가장 먼저 지워진다.

이 구분이 수리를 바꾼다. 하나는 채널 설정의 일치를, 다른 하나는 계정 상태를, 세 번째는 도달한 리스너와 맞지 않는 프로필을 요구한다.

실행 중인 프로세스가 실제로 로드한 것을 비교한다

디스크에 있는 올바른 파일은 그것이 편집되기 전에 시작된 프로세스에 대해 아무것도 증명하지 못한다. 선택된 프로필, 접속한 엔드포인트, 변경 후 서비스가 다시 로드되었는지 확인한다. 다른 인스턴스나 다른 서비스가 옛 파일이 기대하는 것과 다른 방식으로 대기하고 있을 수 있으므로, 엔드포인트가 그 프로필의 것인지도 확인한다.

같은 소스에서 지원되는 프로필을 다시 내보내는 것은, 설정되었다고 믿는 것과 클라이언트가 실제로 보내는 것 사이의 표류가 없어지므로 값싼 비교다. 새 키 자료를 생성하는 것은 훨씬 큰 단계이며, 양쪽이 함께 받아들일 때만 도움이 된다. 한쪽만 로컬에서 교체하면 없애려던 불일치를 다시 만든다.

제어 채널과 데이터 채널을 비교한다

두 가지 메커니즘은 연결의 서로 다른 부분을 인증하며 별도로 구성된다.2.6 옵션 참조에 설명된 대로이며,tls-auth는 제어 채널 패킷에 HMAC을 더하고, 두 피어에서 반대여야 하는 방향 인수를 받는다.tls-crypt는 대신 공유 키로 제어 채널을 보호한다. 둘 다 데이터 채널 자체의 무결성 검사는 아니지만, AEAD 데이터 암호에서는 그 검사가 암호에 내장되어 있으므로, 별도의auth다이제스트는 비 AEAD 암호에서처럼 쓰이지 않는다.

즉, 동작하는 비 AEAD 배포에서 복사한auth줄은 AEAD 배포에서 무관할 수 있고, AEAD 배포에서도tls-auth키나 그 방향이 틀렸다면 제어 채널에서 실패할 수 있다. 각 설정은 기억 속 구성이 아니라 피어와 비교한다.

포기하는 속성과 수리를 비교한다

패킷 인증을 비활성화하면 경고가 조용해지고 불일치를 찾아낸 검사가 사라지지만, 그것은 프로필을 수리하는 것과 같지 않다. 어떤 속성을 포기하는지, 그리고 그것 없이도 설계가 성립하는지 물어야 한다.

무엇이든 바꾸기 전에 양쪽 끝에서 첫 번째 관련 이벤트를 읽고, 그다음에는 그것이 지목하는 불일치만 바꾼다.

다음 시도가 인증서나 로그인 오류까지 진행된다면 패킷 계층이 합의되어 연결이 앞으로 나아간 것이며, 후퇴가 아니라 진전이다. 변화를 만든 설정을 기록해 두면 다음 사람은 수수께끼 대신 설명을 물려받는다.