opt-verify를 추가해도 OpenVPN 암호 오류가 해결되지 않는 이유

opt-verify를 추가하라는 제안을 찾아 그 줄을 넣어도 암호 오류는 원래 있던 자리에 그대로 남습니다. 이 결과는 예측 가능한데, 그 옵션은 암호를 협상한 적이 없기 때문입니다. 이것은 옵션 일관성 검사였고 2.6에서 폐기되어 2.7에서 제거되었으며, 이를 함께 두고도 파싱되는 프로필이 그로 인해 무엇인가를 강제한 것은 아닙니다.

그것이 빠진 조각이라고 결론짓기 전에, 그 줄이 예전에 무엇을 했는지 아는 것이 도움이 됩니다. 그 이력은 지금 왜 도움이 되지 않는지도 설명합니다.

그 옵션이 예전에 강제하던 것

2.6 설명서는 opt-verify를 폐기된 것으로 표시하고, 이전 동작으로 서버가 선언된 옵션이 자기 것과 맞지 않는 클라이언트를 끊으며 장치 유형과 MTU 같은 것을 비교한다고 설명합니다. 그 검사는 옵션 일관성 검사가 켜져 있어야 하므로 disable-occ로 실행되는 서버에는 처음부터 없었습니다. 비교의 재료가 상대방의 구성을 설명하는 텍스트라는 점을 보십시오. 데이터 채널이 어떤 암호를 쓸지에 대해서는 아무 말도 하지 않습니다.

이것이 그 플래그로 암호 오류를 고칠 수 없는 첫 번째 이유입니다. 암호 선택은 data-ciphers 정책과 양쪽이 지원하는 것에 의해 결정되며, 텍스트 일관성 검사는 그 목록을 늘리지도 않고 협상을 수행하지도 않습니다. 두 번째 이유는 범위로, 검사는 선언된 옵션이 호환되어 보이는지에 관한 것이지 그 결과로 생기는 경로의 품질에 관한 것이 아닙니다.

2.7이 그 줄을 보면 하는 일

2.7에서는 그 옵션이 없습니다. 파서는 여전히 이름을 인식하므로 오래된 프로필이 구문 오류 없이 로드되며, 조용히 넘어가는 대신 옵션이 제거되었다고 보고합니다. 이름을 인식하는 것과 동작을 강제하는 것은 다른 일이며, 지금도 전자만 일어납니다. 제거 노트는 매개변수를 협상할 수 있게 되면 두 피어가 연결에 합의하면서도 정당하게 서로 다른 옵션 문자열을 가질 수 있기 때문이라고 설명합니다.

따라서 파싱되는 프로필은 어떤 수락 검사가 실행되었다는 증거가 아닙니다. 유일한 신호가 클라이언트가 연결되었다는 것이라면, 구문이 받아들여졌다는 것만 알게 된 것입니다.

실패가 실제로 있는 곳

이후 메시지는 보통 그 결과이므로 무엇이든 바꾸기 전에 첫 번째 구체적인 오류를 보존하십시오. 데이터 채널 협상 실패는 승인된 암호 정책과 양쪽이 실제로 광고하는 기능에 속합니다. TLS 버전 또는 스위트 실패는 제어 채널에 속합니다. 인증서 거부에는 신원과 신뢰 체인이 필요하며, 호환성 플래그가 아닙니다.

양쪽 끝의 엔진도 확인하십시오. 데스크톱 애플리케이션은 테스트한 명령줄 바이너리와 다른 빌드를 포함할 수 있고, 옵션 지원도 둘 사이에서 다릅니다. 프로필을 가져오는 모든 프로그램이 같게 동작한다고 가정하지 말고 그 엔진의 문서를 확인하십시오.

줄만이 아니라 의도를 바꾸십시오

오래된 관리형 서버가 정말로 일관성 검사에 의존했다면, 업그레이드 전에 어떤 제약을 강제했는지 기록하십시오. 더 새로운 프로필에 무시되는 옵션을 남겨 두는 것으로는 그 정책을 보존할 수 없고, 줄을 마구 삭제하는 것으로도 안 됩니다.

모든 암호가 비활성화되어 있다는 오래된 제안에 모든 역사적 알고리즘을 활성화하여 답하지 마십시오.

승인된 수정 후 새 연결에서 협상된 결과를 확인하고 사용자가 실제로 필요로 하는 애플리케이션을 테스트하십시오. 서버 버전과 유효 정책을 그 결과 옆에 두어, 다음 사람이 단지 수락된 것이 아니라 무엇이 합의되었는지 볼 수 있게 하십시오.

목표는 지원되는 제약과 작동하는 인증된 경로이며, 아직 파싱되는 레거시 플래그가 아닙니다.