duplicate-cn은 두 기기에 하나의 정체성을 줄 뿐, 둘을 주지 않는다

프로필을 태블릿에 복사하고 연결하면 노트북이 끊긴다. duplicate-cn을 추가하면 둘 다 연결된 채로 남고, 문제는 해결된 것처럼 보인다. 두 기기가 같은 터널 주소를 두고 다투거나 잃어버린 태블릿 하나가 계정 전체를 오프라인으로 만들기 전까지는. 이 옵션이 바꾸는 것은 단 하나다. 서버가 이미 본 이름 아래에서 두 번째 세션을 허용하는지 여부다. 기기 독립성에서 기기별 주소 지정, 선택적 폐기까지 사람들이 기대하는 모든 것은 여전히 정체성으로 처리되며, 여기서 정체성은 인증서다.

신화: 두 번째 세션은 두 번째 정체성이다

직관적으로 두 연결은 두 클라이언트이고, 두 클라이언트는 각자의 권리를 가진 두 기기여야 한다. 서버는 그렇게 모델링하지 않는다. 서버는 공통 이름 하나를 보며, duplicate-cn이 켜져 있으면 그 이름을 가진 세션을 하나 이상 동시에 받아들인다. 각 세션은 데몬 안에서 자기 세션 상태를 갖는다.

그 수용은 인증서 검증을 전혀 건드리지 않는다. 같은 인증서가 여전히 자격 증명이고, 같은 키가 여전히 개인 키이며, 인증서 주체를 기준으로 하는 정책은 여전히 두 번 모두 같은 값으로 귀결된다. 두 번째 세션은 두 번째 소켓이지 두 번째 정체성이 아니다.

그 구분은 모든 것이 잘 돌아가는 동안에는 보이지 않는다. 두 기기를 구별해야 하는 순간에 아주 선명해지는데, 대개 그중 하나를 잃어버린 날이다.

두 세션이 이름을 공유할 때 실제로 달라지는 것

이 옵션이 없으면 이미 연결된 공통 이름으로 들어오는 새 연결이 앞선 세션을 밀어낸다. 태블릿이 연결될 때 노트북이 끊기는 이유가 그것이며, 이는 버그가 아니라 의도된 모호성 방지 장치다. 옵션이 있으면 두 세션이 모두 살아 있고 서버는 기기 단위가 아니라 세션 단위로 따로 추적한다.

각 세션은 여전히 자신의 외부 연결과 자신의 협상된 키를 받으므로 동시 처리량은 정말로 동시적이다. 둘이 공유하는 것은 자격 증명에서 파생되는 모든 것이다. 정책 조회, 클라이언트별 구성, 로그상의 정체성, 폐기. 세션 상태는 연결에 속하고 연결과 함께 사라지지만, 자격 증명 수준의 사실은 둘 모두에 남는다. 그래서 상태 출력이 같은 이름을 두 번 나열해도 카운터는 따로 유지된다.

그 위에 설계하기 전에 자신의 빌드가 실제로 무엇을 하는지 확인하라. 옵션의 효과는 옵션 자체가 정하지, 전해 내려오는 이야기가 정하지 않는다:

grep -n 'duplicate-cn\|client-config-dir\|username-as-common-name' /etc/openvpn/server.conf

할당했다고 생각한 고정 주소

클라이언트별 구성은 이름으로 조회되며, 바로 거기에 함정이 있다. 공통 이름을 따서 지은client-config-dir 파일은 그 이름을 쓰는 모든 기기에 적용되므로, 그 안의 ifconfig-push는 두 기기에 같은 터널 주소를 준다. 두 번째 세션은 아예 성립하지 않거나, 라우팅 장애처럼 보이는 방식으로 충돌한다.

동적 풀은 우연히 더 나은 동작을 보인다. 각 세션에 풀에서 독립적으로 주소가 할당되기 때문이다. 그래도 기기별 고정 주소가 되지 않고, 그 주소에 묶인 기기별 정책은 더더욱 되지 않는다.

배포가 username-as-common-name을 쓰면 조회 키가 인증서 주체 대신 인증된 사용자 이름이 되고, 두 번 로그인하는 누구에게나 같은 충돌이 따라온다. 구성을 좌우하는 이름이 기기별로 고유해야 기기별 구성이 의미를 갖는다.

공유된 정체성이 제거 시점에 할 수 없는 일

폐기는 인증서에 작용하며, 표시 이름에도 세션에도 작용하지 않는다. 그 인증서를 폐기하면 사본을 가진 모든 기기가 한꺼번에 접근을 잃는다. 아무도 방해하고 싶지 않은 사무실의 그 기기도 포함해서. 그대로 두면 잃어버린 기기가 계속 동작한다. 프로토콜 안에 승인된 사본과 그것을 구별하는 것이 없기 때문이다.

로그도 같은 모호성을 물려받는다. 상태 출력은 공통 이름과 실제 주소를 보여 주는데, 둘 다 두 기기 중 어느 것에도 속할 수 있다. 어느 머신이 무엇을 했는지 알아야 하는 사고 검토는 VPN 자체의 기록으로는 그 질문에 답할 수 없다. 로그 수준이 아무리 자세해도 마찬가지다.

여기에는 암호학적 우회로가 없다. 같은 인증서를 제시하는 두 기기는 서버 입장에서 같은 참가자가 두 번 있는 것이며, 그 반대를 주장하는 어떤 방식도 통제가 아니라 명명 관례일 뿐이다.

공유가 옳을 때, 그리고 어떻게 경계를 그을 것인가

공유에는 정당한 용도가 있다. 여러 시험 장비가 쓰는 실험실 계정, 또는 기기를 함께 관리하고 폐기 세분성이 중요하지 않은 가정이다. 그런 경우에는 옵션을 의도적으로 켜고, 공유 자격 증명을 기기별 정책 밖에 두고, 세션이 주소에서 충돌하지 않도록 풀에 여유를 두어라.

별도 주소, 별도 로그, 별도 제거가 필요한 모든 것에는 정상 등록 경로로 별도 인증서를 발급하라. 그러면 하위의 모든 시스템이 기댈 별개의 객체를 얻고, 이름이 이미 고유하므로 이 옵션은 중요성을 잃는다.

어느 길을 택하든 로그인이 아니라 관리 모델을 시험하라. 두 기기를 연결하고 서로 다른 주소를 갖는지 확인한 뒤, 손실을 시뮬레이션하고 정확히 하나만 제거할 수 있는지 점검하라.openvpn(8) 매뉴얼이 옵션의 범위를 정의한다. 공유가 실제로 수용 가능한지는 당신의 제거 절차가 정의한다.