공유 VPN 계정: 기기 한도는 클라이언트 격리가 아니다

동시 접속 여덟 개는 라이선스 페이지에 적힌 숫자일 뿐이고, 그 여덟 대의 기기가 서로에게 무엇을 할 수 있는지는 말해 주지 않는다. 공유 로그인은 세션별 키와 함께 존재할 수 있고, 한 클라이언트의 트래픽을 기꺼이 다른 쪽으로 전달하는 게이트웨이와도 함께 존재할 수 있다. 계정을 보안 경계로 보는 것이 실수다. 대신 무엇을 샀는가, 무엇이 터널을 보호하는가, 피어 사이로 무엇이 건널 수 있는가, 무엇이 로컬 링크를 끊을 수 있는가라는 네 가지 질문을 따로 하라.

연결 허용량이 실제로 약속하는 것

기기 한도는 제공자가 하나의 구독에 대해 몇 개의 세션을 받아들이는지 세는 것이다. 이는 상업적·운영적 통제이지 신원이나 격리에 관한 진술이 아니다. 어떤 제공자는 하나의 계정 아래 기기마다 별도 인증서를 발급하고, 다른 제공자는 모든 연결에 하나의 자격 증명을 재사용한다. 차이는 폐기 시점에 드러나는데, 별도 자격 증명은 기기 하나를 끊을 수 있게 하지만 공유 자격 증명은 그런 선택지를 남기지 않는다.

키 분리에 대해 무엇이든 가정하기 전에 제공자가 자격 증명을 어떻게 발급하는지 읽어 보라. 계정 이름 자체는 그 무엇도 드러내지 않는다.

게이트웨이가 클라이언트 사이를 전달하는지 확인하라

피어 간 도달 가능성은 서버 측 결정이다. OpenVPN 에서는 해당 스위치가 구성에 나타나지 않으면 없는 것이지만, 현대의 데이터 플레인 오프로드는 규칙이 적용되는 위치를 바꾼다.

grep -n "client-to-client" /etc/openvpn/server.conf
iptables -A FORWARD -i tun0 -o tun0 -j DROP

그 지시가 없는 구성에서는 피어 트래픽이 호스트 방화벽에 맡겨지고, 방화벽이 여전히 허용할 수도 있다. 오프로드가 활성화되면 터널 인터페이스는 사용자 공간 프로세스가 아니라 커널이 처리하므로, 파일을 믿지 말고 규칙 카운터를 확인하라. 터널 주소 사이에서 전달되는 트래픽을 차단하면 게이트웨이에 대한 접근을 건드리지 않고 클라이언트를 격리할 수 있다. 한 클라이언트에서 다른 클라이언트의 서비스로 보내는 검사로, 규칙 전과 후 모두 확인하라.

피어보다 세션을 먼저 보호하라

터널 보호와 피어 접근은 서로 다른 속성이고, 강한 암호가 격리를 뜻하지는 않는다. TLS 모드에서는 각 클라이언트가 자기 세션 키를 도출하므로, 게이트웨이가 전달하더라도 한 클라이언트가 다른 클라이언트의 트래픽을 읽을 수 없다. 옛 정적 키 방식은 모두가 하나의 키를 공유하므로, 거기서 로그인을 재사용하면 훨씬 나쁜 결과를 낳는다. 마케팅 페이지가 아니라 구성된 모드를 살피고, 그다음 계정 공유가 해당 데이터에 맞는지 판단하라.

각 호스트에서의 서비스 인증은, 터널이 클라이언트의 네트워크 도달만 증명하고 특정 데몬에 도달해야 함을 증명하지 않기에 여전히 중요하다.

로컬 Wi-Fi 장애는 VPN 침해가 아니다

끊긴 연결은 로컬 링크가 실패했다는 증거이지, 누군가 터널을 깼다는 증거가 아니다. 간섭, 만료된 DHCP 임대, 로밍 핸드오프는 모두 자격 증명이나 암호문을 건드리지 않고 세션을 끝낸다. 연결 끊김을 가용성 소견으로 다루고, 기밀성 및 피어 접근 소견과 분리해 두라. 로컬 네트워크를 신뢰할 수 없는 곳에서는 터널에만 기대지 말고 트래픽을 종단 간 보호하라.

허용량, 키 모델, 피어 정책, 로컬 링크 의존성이라는 네 가지 답을 적어 두라. 그 기록이 공유 계정에 대한 막연한 걱정을 구체적인 통제로 바꾼다.