두 피어 사이의 OpenVPN 링크에는 정적 키와 TLS 중 무엇을 써야 할까?
OpenVPN의 정적 키 모드는 트래픽 키를 회전할 수 없다. 두 피어에 자동 갱신이 필요하다면 TLS 모드로 전환하고 점대점 배치는 그대로 두어라.
서로에게만 통신하는 두 머신도 그 토폴로지를 유지한 채 협상된 트래픽 키를 얻을 수 있다. 네트워크 형태와 보호 모드는 독립적인 선택이며, 이 둘을 혼동하기 때문에 사람들은 두 데몬이 계속 실행되는 동안 파일을 교체하여 정적 비밀을 회전하려 한다. 실행 중인 쌍 아래에서 키 파일을 교체해도 아무것도 회전되지 않는다. OpenVPN 2.6이 사용 중단으로 표시하는 정적 키 모드는 터널의 수명 동안 하나의 키를 유지하므로, 디스크의 파일과 메모리의 키는 양쪽 끝이 재시작된 뒤에야 다시 일치한다. 자동 갱신이 요구 사항이라면 보호 모드를 바꿔야 한다.
정적 키 모드가 할 수 없는 일
비밀 모드에서는 두 피어가 터널을 직접 암호화하고 인증하는 사전 공유 키를 공유한다. 핸드셰이크가 없으므로 어느 쪽도 새 키 자료를 제안하거나, 신원을 증명하거나, 운영자 개입 없이 불일치에서 복구할 메커니즘이 없다. 두 속성 모두 빠진 옵션이 아니라 제어 채널의 부재에서 비롯되며, 어떤 구성 플래그도 이 모드에 제어 채널을 추가하지 않는다.
OpenVPN 2.6 설명서는 새 키가 생성될 때까지 키가 유지된다고 명시한다. 이는 실험실 링크나 문서화된 교체 절차가 있는 고정 장비 쌍에는 허용되지만, 장기 비밀이 실제 위험인 곳에서는 허용되지 않는다. 파일 교체는 실행 중인 쌍에 새 키를 만들지 않고, 서로 어긋나는 두 피어를 만들 뿐이다. 따라서 파일 교체는 회전을 추가하지 않고 중단만 추가한다.
파일 소유 외에 피어 신원이라는 개념도 없다. 키를 가진 사람은 누구나 피어이며, 터널 안의 어떤 것도 어느 쪽이 어느 쪽인지 기록하지 않으므로 폐기는 전부 아니면 전무다.
링크를 다시 설계하지 않고 TLS로 이동
TLS 모드는 제어 채널을 추가하고, 그와 함께 데이터 채널 키를 협상하는 능력을 추가한다. 점대점 배포에서는 한쪽이 서버 역할을, 다른 쪽이 클라이언트 역할을 맡지만 토폴로지는 두 피어 사이의 링크로 남고, 각 측은 상대의 엔드포인트를 알며 어떤 풀이나 다중 사용자 서비스도 나타나지 않는다. 역할은 핸드셰이크의 세부 사항이며 새로운 아키텍처가 아니다.
각 머신에 고유한 신원을 부여하라. 각 측에는 인증서와 개인 키, 상대를 검증하는 신뢰 앵커, 그리고 누가 예상되는지 지정하는 피어 검증 규칙이 필요하다. 시간을 아끼려고 한 피어의 개인 키를 다른 쪽에서 재사용하지 마라 — 그것은 두 신원을 하나로 만들고 어느 쪽이든 별도로 폐기할 능력을 없앤다. 등록 단계에서 이를 올바르게 해야 하며, 나중에 고치는 것은 인증서를 재발급하는 일이다.
보호가 바뀌는 동안 네트워크 계약은 그대로 유지하라. 동일한 터널 주소, 경로, 허용된 서비스가 변경 전후에 적용되어야 하며, 그래야 마이그레이션 중 실패가 위장된 라우팅 문제가 아니라 보호 문제로 다뤄진다. 변경 전에 주소와 경로를 적어 두어라 — 나중에 비교하는 것이 기억에서 재구성하는 것보다 빠르다.
일부 배포는 데이터 채널과 함께 회전하지 않는 자체 정적 키로 제어 채널도 보호한다. 그 키는 페이로드가 아니라 핸드셰이크를 지키므로, 유출되면 트래픽이 아니라 협상이 드러난다. 데이터 채널 자재와 분리해 보관하고, 이름이 지정된 사람이 소유하는 교체 날짜를 부여하라. 키를 회전하려면 조정된 시간 창에서 두 피어를 재시작해야 하므로, 기억이 아니라 일정 항목으로 관리할 가치가 있다.
누가 무엇을, 언제 갱신하는가
TLS 모드에서는 구성된 한도, 즉 시간 간격·바이트 수·패킷 수가 갱신을 주도한다. 문서화된 시간 제어가 대부분의 배포가 의존하는 것이며, 두 피어 중 더 낮은 유효 값이 교체를 시작할 수 있으므로 한쪽만 올려서는 이벤트를 미룰 수 없다. 볼륨 기반 한도가 있는 이유는 바쁜 링크가 시계보다 훨씬 먼저 키를 소진할 수 있기 때문이다. 어느 한도도 상태 점검이 아니며, 어느 것도 갱신이 성공했다고 알려 주지 않는다.
그래서 단일 구성 파일로 반복되는 재협상을 진단하는 것은 오해를 부른다. 두 피어의 설정을 읽고, 결함을 가정하는 대신 로그의 전환을 보라. 깨끗하게 완료되는 갱신은 연결 끊김이 아니라 제어 채널 트래픽의 짧은 폭주처럼 보인다.
객체를 머릿속에서 분리해 두라. 인증서는 장기 신원을 증명하며 당신이 통제하는 일정에 따라 교체된다. 데이터 채널 키는 자동으로 갱신되며, 배포가 요구한다면 별도의 인증 교환은 계정 정책을 따르고 이후 교환을 위해 자체적인 준비가 필요할 수 있다.
간격을 영으로 설정해 갱신을 완전히 비활성화하는 것은 시끄러운 로그의 해결책이 아니다. 그것은 건강한 수명 주기 이벤트를 영구 키로 바꾸며, 당신이 벗어나려 했던 속성으로 되돌린다.
변경을 받아들이기
새 구성은 설치된 릴리스의 지원되는 예제에서 만들어라 — 알고리즘과 파일 경로가 다른 곳에서 물려받은 낡은 최소 조각이 아니라. 두 피어가 함께 바뀌도록 전환을 조정하고, 한쪽이 올라오지 못할 경우를 위해 승인된 복구 경로를 유지하라. 롤백을 시험하려고 장애를 기다리는 대신 의도적으로 링크를 내려라. 연습한 롤백이 설명만 한 롤백보다 값지다.
초기 신원 검증이 성공하고, 의도한 애플리케이션 흐름이 작동하며, 통제된 갱신이 트래픽 손실 없이 일어나는지 세 가지를 시험하라. 그다음 로그의 전환을 그것이 실제로 무엇을 증명하는지의 관점에서 읽어라 — 새 키 식별자는 피어가 교체를 완료했다는 뜻이지 터널이 다시 연결되었다는 뜻이 아니다. 한 단계의 증거로 다루고, 마이그레이션을 완료라고 부르기 전에 트래픽 카운터를 확인하라.
무중단 약속이 감추는 것은 아직 보지 못한 실패다. 실패한 갱신, 만료되는 인증서, 경로 결함은 여전히 링크를 방해할 수 있으며, 깨끗한 시험 실행으로 어느 것도 배제되지 않는다. 설계할 가치가 있는 속성은 더 좁고 더 유용하다 — 일상적인 키 교체가 수동 파일 교체가 아니게 되는 것이다.