OpenVPN 프로필에서 key-method를 지워도 달라지는 것은 없습니다

수년 동안 잘 동작하던 프로필이 갑자기 시작을 거부하고, 메시지는 누구도 추가한 기억이 없는 지시문의 이름을 댑니다. 바로 key-method 입니다. 다음 검색 결과는 호환성을 위해 key-method 2 를 추가하라고 권하지만, 그것은 다른 시대의 조언입니다. 이 줄을 거부한 파서는 현재의 것이며 그런 옵션 자체가 없습니다. 줄을 지우면 시작은 고쳐지고, 두 피어가 세션을 보호하는 방식은 아무것도 달라지지 않습니다.

프로필이 담고 있는 것과 프로토콜이 실제로 하는 일 사이의 이 간극이 여기서 다루는 주제 전체이며, 사람들이 동시에 하는 다른 여러 편집도 설명합니다. 그 편집들이 대개 한 묶음으로 오는 이유도 설명합니다.

증상은 핸드셰이크 실패가 아니라 파싱 오류입니다

옵션은 어떤 패킷을 보내기 전에 읽힙니다. 알 수 없는 지시문이 있는 프로필은 그 단계에서 실패하므로 프로세스는 네트워크에 이르지 못하고 핸드셰이크 오류도 만들지 않습니다. 문구는 보통 옵션과 파일을 지목하므로 원인을 붙이기 쉬운 실패 중 하나입니다. 패킷도 경로도 방화벽도 관여하지 않습니다.

openvpn --config /etc/openvpn/client/office.ovpn --verb 3 --log /tmp/parse.log
grep -n 'Options error' /tmp/parse.log

메시지가 지시문을 지목하면 진단은 끝입니다. 이 빌드가 받아들이지 않는 것이 파일에 들어 있다는 뜻입니다. 반대로 파일 경로를 지목하면 문제는 빠진 include나 키이며, 같은 시작 단계의 다른 부분입니다.

여기서 클라이언트나 서버에 더 오래된 프로토콜 모드가 필요하다고 결론 내려서는 안 됩니다. 파싱 실패는 당신의 파일과 바이너리 사이의 어휘 문제이고, 이 경우 바이너리는 자기 어휘에서 한 단어를 떨어뜨렸을 뿐입니다.

지시문과 전송 형식은 서로 다른 것입니다

예전 key-method 옵션은 TLS 키 교환을 어떻게 프레이밍할지 고르는 것이었고, 현대의 교환은 그 옵션이 한때 요구하던 다중 패킷 방식입니다. 옵션이 사라진 것은 더 이상 아무것도 고르지 않기 때문이며, 그것이 가리키던 형식이 유일한 것이 되었습니다. 따라서 줄을 지워도 세션은 이전과 같은 프레이밍을 그대로 씁니다. 텍스트 편집으로는 어느 방향으로도 바꿀 수 없습니다.

그래서 “방식 2”를 “복원”하려고 옛 바이너리를 다시 들여오는 것은 잘못된 수리입니다. 옛 기본값을 가진 옛 파서 말고는 아무것도 되살리지 못하고, 그 뒤에 온 수정들을 잃게 만듭니다. 인증서 검사나 암호 목록을 약화시켜 연결이 돌아오기를 바라는 것도 같은 논리입니다.

쓸모 있는 확인은 버전과 파싱된 설정이지, 파일에 그 단어가 있는지가 아닙니다.

openvpn --version | head -n 1
grep -rn 'key-method' /etc/openvpn/ 2>/dev/null

무엇을, 어느 파일에서 지울 것인가

실행 중인 프로세스가 실제로 읽는 파일만 편집하십시오. 패키지된 시스템에서는 보통 유닛이 지정한 클라이언트 또는 서버 디렉터리의 프로필이며, 참고용으로 홈 디렉터리에 둔 사본이 아닙니다. 생성된 프로필은 템플릿에서 다시 만들어질 수 있으므로 배포된 사본만 고치면 다음 프로비저닝 실행 뒤에 원래대로 돌아옵니다.

폐기된 줄을 지우고 엔드포인트, 인증서, 암호 정책, 제어 채널 설정은 그대로 두십시오. 이것들은 프로세스가 필요로 하는 지원되는 옵션이며 파싱 오류와 무관합니다. 같은 프로필에 잘 모르는 다른 지시문이 있으면, 프로세스가 시작될 때까지 묶어서 지우지 말고 하나씩 실행 중인 버전과 대조하십시오.

그다음 의도한 인스턴스를 시작하고 그 시작 출력을 읽으십시오. 리스너가 있는 상태의 깨끗한 시작이 이 단계가 끝났다는 확인이며, 그 뒤의 클라이언트 시험은 다른 질문에 답합니다.

거부된 프로필과 거부된 클라이언트는 비슷해 보입니다

두 실패는 비슷한 지원 스레드를 만들지만 필요한 증거는 다릅니다. 자기 설정을 거부하는 서버는 결코 시작하지 않으므로 어떤 클라이언트도 접속할 수 없습니다. 잘 시작하면서 한 클라이언트를 거부하는 서버는 돌아가고 있고, 그 로그에 이유가 있습니다. 인증서 문제, 클라이언트가 받아들이지 않는 푸시된 옵션, 암호 불일치입니다.

지운 옵션은 두 번째 경우의 진단이 아니며, 그것에 기대면 같은 한 시간을 두 번 버립니다. 클라이언트 로그가 서버의 거부를 보여 주면 그 거부를 읽고, 로컬 오류를 보여 주면 살펴볼 파일은 클라이언트 프로필입니다. 더 이상 존재하지 않는 지시문에 기대는 것은 두 조사 모두를 같은 만큼 늦춥니다.

그 줄이 끝내 답하지 못한 호환성 질문들

이 지시문과 함께 도는 프로필은 대개 특정 플랫폼에 관한 이야기를 달고 다니며, 그 이야기는 기술적 이유보다 오래 살아남습니다. 모바일이나 데스크톱 클라이언트에는 여전히 완전히 지원되는 프로필 이 필요합니다. 신뢰할 수 있는 인증서 체인, 양쪽이 받아들이는 데이터 암호, 양쪽이 구현하는 제어 채널 모드, 그리고 클라이언트 빌드가 거부하지 않는 지시문입니다. 어느 것도 옛 key-method 줄의 유무로 결정되지 않습니다.

압축은 같은 모양의 별도 정책 질문입니다. key-method 줄을 지우는 것은 압축 지시문이 당신의 배포에서 지원되거나 허용되는지에 대해 아무것도 말해 주지 않으며, 두 결정은 독립적으로 내려야 합니다. 무언가 연결될 때까지 보안과 관련된 설정을 한꺼번에 지우는 것이 동작하던 프로필을 설명되지 않는 프로필로 만드는 길입니다.

무엇을 왜 지웠는지 짧게 기록해 두십시오. 옵션, 그것을 거부한 버전, 오류를 보여 준 명령 세 가지입니다. 프로필을 이어받을 다음 사람에게는 바로 그 세 가지 사실이 필요하고, 나중에 재구성하는 것보다 지금 적는 편이 쌉니다.