OpenVPN data-ciphers가 데이터 채널 암호를 선택하는 방식
서버가 목록을 제시하고 클라이언트가 첫 번째 일치 항목을 고릅니다. 로그 두 줄을 읽고 목록을 비교하며, 상대가 정말 필요로 하는 곳에만 대체 옵션을 추가하십시오.
터널이 올라오고 로그에 암호가 표시되며 프로필 검토는 계속 진행됩니다. 그러다 한 피어에 업그레이드가 적용되고 같은 프로필이 공통 암호가 없다는 메시지와 함께 실패합니다. 그래서 사람들은 삭제할 지시문을 찾아 나서게 됩니다. 이해해야 할 핵심은 data-ciphers가 설정이 아니라 협상을 설명한다는 점입니다. 한쪽이 목록을 제시하고 다른 쪽이 그 안에서 고르며, 결과는 양쪽이 지원하는 단일 알고리즘입니다. 그 교환을 읽으면 한 줄을 바꾸기 전에 이런 실패의 대부분을 설명할 수 있습니다.
두 개의 채널, 두 개의 설정
하나의 OpenVPN 세션에는 제어 채널과 데이터 채널이 있습니다. 제어 채널은 피어를 인증하고 키를 협상하는 TLS 핸드셰이크를 실행합니다. 데이터 채널은 트래픽을 나르는 패킷을 암호화합니다.
data-ciphers가 설정하는 것은 두 번째입니다. 제어 채널에는 자체 옵션이 있고, 프로필의 신원 확인은 세 번째의 별개 사안입니다. 하나를 바꾼다고 다른 하나가 고쳐지지 않기 때문에, 프로필이 올바르게 보여도 특정 단계에서 실패할 수 있습니다.
설정 파일을 읽을 때는 이 세 가지를 각자의 상자에 담아 두십시오.
로그에서 협상을 읽으십시오
연결이 성공하면 클라이언트 로그는 두 결과를 모두 알려 줍니다. 한 줄은 제어 채널과 그 TLS 세부 정보를 보고하고, 다른 줄은 선택된 데이터 채널 암호를 보고합니다.
두 줄을 모두 읽으십시오. 서로 다른 질문에 답하기 때문입니다.제어 채널의 장애는 어떤 데이터 암호가 중요해지기 전에 연결을 멈춥니다. 데이터 채널의 불일치는 핸드셰이크가 성공한 뒤에 나타나며, 공통 암호가 없다는 메시지를 동반합니다.
그다음 양쪽이 제시한 목록을 비교하십시오. 한쪽 버전이나 그 암호 기반이 제공하지 않는 이름은, 다른 쪽 목록에서 아무리 일찍 나타나도 선택할 수 없습니다.
선택은 실제로 어떻게 일어나는가
서버는 핸드셰이크 동안 자신의 data-ciphers 목록을 클라이언트로 밀어 넣고, 클라이언트는 그 목록에서 자기도 지원하는 첫 항목을 고릅니다. 따라서 순서는 서버의 설정에 속하며 클라이언트의 것이 아닙니다.
이 세부 사항이 혼란스러운 결과 한 부류를 설명합니다. 서버 목록이 결정하는 동안에는 클라이언트 목록을 다시 정렬해도 아무것도 달라지지 않습니다. 클라이언트가 제공할 수 없는 암호를 더해도 마찬가지입니다. 클라이언트는 자신이 고른 항목을 사용할 수 있어야 하기 때문입니다.
새 릴리스에서는 기본 목록이 바뀌고 그것을 담던 옵션의 이름도 바뀌었습니다. 그래서 버전이 다른 두 피어는 누구도 프로필을 편집하지 않아도 서로 어긋날 수 있습니다. 오타라고 단정하기 전에 양쪽의 버전을 확인하십시오.
목록은 추상적인 의미의 강도 순위가 아닙니다. 후보의 집합이며, 선택된 것은 서버 순서에서 처음으로 양쪽이 지원하는 항목입니다. 그래서 서로 달라 보이는 두 목록이 같은 암호를 협상할 수 있습니다. 똑같아 보이는 두 목록이 실패할 수도 있는 이유도 같습니다.
오래된 피어에는 의도적인 대체 옵션이 필요합니다
그 메커니즘보다 오래되었거나 그것을 비활성화했기 때문에 전혀 협상할 수 없는 피어에는 문서화된 호환성 합의가 필요합니다. 대체 옵션은 바로 그 경우를 위해 존재하며 협상에 참여하지 않는 피어에 적용됩니다.
이것은 메시지를 없애기 위해 모든 구형 암호를 켜는 것과 다릅니다. 넓은 목록은 강한 것을 협상했을 피어까지 포함해 모든 피어의 세션을 약화합니다.
무관한 알고리즘 이름을 편집하는 대신 양쪽을 조정하십시오. 서버 업그레이드가 오래된 옵션을 제거했다면 수정은 버전 계획에 속하며, 클라이언트에서의 허둥대는 일이 아닙니다.
검증을 그대로 유지하십시오
데이터 채널의 불일치는 검증되지 않은 서버를 받아들일 이유가 아닙니다. 인증서 검증, 예상 서버 이름, 제어 채널의 보호 설정은 암호 선택과 별개이며 어떤 호환성 변경에도 견뎌야 합니다.
협상된 데이터 암호, 클라이언트 버전, 서버 버전을 함께 기록하십시오. 다음 비교가 프로필 파일이 아니라 사실에서 시작되도록 하기 위해서입니다.
지원되는 수정을 한 뒤에는 최초 연결과 재협상을 시험하십시오. 한 번 성립한 세션도 키가 갱신될 때 실패할 수 있기 때문입니다.
터널이 성립하는데 사이트가 계속 실패한다면 암호는 더 이상 용의자가 아닙니다. 라우팅과 DNS 점검으로 넘어가십시오. 작업 순서는 로그 두 줄을 읽고, 두 목록을 비교하고, 버전을 확인하고, 정말 필요한 피어에만 대체 옵션을 추가한 뒤 갱신 경로를 다시 시험하는 것입니다.