VPN 서버를 직접 운영할 때 당신은 누구를 믿는가

셀프 호스팅은 운영자 역할을 당신에게 준다: 소프트웨어, 구성, 업데이트 일정, 그리고 자신의 서비스가 무엇을 기록하는지를 당신이 고른다. 그것이 하지 않는 일은 연결에서 다른 당사자들을 빼는 것이다. 당신의 접속망은 여전히 패킷을 나르고, 호스팅 제공자는 여전히 기계를 운영하며, 리졸버는 여전히 질의에 답하고, 목적지는 여전히 요청을 본다. 그중 무엇을 실제로 바꿨는지 아는 것이 이 연습의 전부다.

1단계: 관련 당사자를 목록화하기

실제 배포에 있는 모든 당사자를 나열하라. 당신의 기기, 접속하는 망, VPN 호스트, DNS 리졸버, 그리고 목적지 서비스다. 각각에 대해 무엇을 관찰할 수 있고 어떤 설정을 당신이 통제하는지 적어라.

그 표는 익명성에 관한 어떤 주장보다 유용하다. 통제가 실제로 어디서 바뀌었는지를 보여 주기 때문이다. 당신은 호스트의 구성과 로그를 통제한다. 접속망이 당신의 연결을 보는 관점은 통제하지 못하고, 목적지가 당신의 계정에 대해 무엇을 기록하는지도 통제하지 못한다.

가정용 종단점에서는 가려진 트래픽이 보통 그 집의 접속 회선을 통해 나간다. 목적지가 보는 출구 주소는 그 가구의 주소이며, 이는 토폴로지의 사실이지 소프트웨어의 결함이 아니다. 바꾸고 싶은 것이 바로 그 주소라면 가정용 서버로는 할 수 없다. 다른 곳에 출구가 필요하다.

2단계: 얻은 것을 적기

배포된 구성을 살펴보고, 어떤 기기가 참여할 수 있는지 정하고, 진단 정책을 세우고, 선택한 기록을 보관할 수 있다. 그것들은 당신이 유지할 때 진짜 통제이며, 셀프 호스팅의 정직한 이유다.

그것들은 조건부이기도 하다. 쓰이지 않는 기본 설정과 검증하지 않은 백업은 프로토콜이 제공하는 속성이 아니라 의도다. 통제를 그것을 증명하는 시험과 함께 적어라. 그렇지 않으면 인정되지 않는다.

3단계: 유지보수 목록 받아들이기

목록은 짧고 가차 없다: 관리자 계정을 보호하고, 서버 키를 보호하고, 클라이언트 신원을 발급하고 폐기하고, 백업을 유지하고, 잃어버린 기기를 제거하고, 실패한 터널에 의존하지 않는 복구 경로를 남겨라.

폐기는 따로 한 줄이 필요하다. 구성에서 제거했지만 한 번도 폐기하지 않은 기기는 여전히 유효한 자격 증명을 갖고 있고, 그 차이는 누군가 그것을 쓸 때에야 드러난다. 옛 자료로 연결을 시도해 제거를 시험하라.

백업도 같은 대우가 필요하다. 예비 호스트에 하나를 복원하라 그리고 같은 신원으로 터널이 올라오는지 확인하라. 한 번도 복원하지 않은 백업은 파일일 뿐, 복구 계획이 아니다.

4단계: 익명성 가정 내려놓기

서버를 운영한다고 브라우저가 익명이 되지는 않는다. 사이트는 여전히 계정 정보와 쿠키를 받고, HTTPS는 터널과 무관하게 자기 경로에서 애플리케이션 데이터를 보호한다.

더 미묘한 효과도 있다. 당신만 쓰는 주소는 당신의 사용과 연결된 안정적인 신호가 될 수 있다. 상업적 출구는 낯선 사람들과 공유되며, 이는 프라이버시에 한쪽으로 나쁘고 다른 쪽으로 좋다. 당신 자신의 주소는 유일하며, 그 거래를 뒤집는다.

목표가 연관되기 어렵게 만드는 것이라면, 셀프 호스팅은 어렵게 만들기보다 쉽게 만들 수 있다. 저녁 하나를 쏟기 전에 어떤 속성을 정말 원하는지 결정하라. 유일성은 비용이지 기능이 아니며, 셀프 호스팅 글 대부분에는 나오지 않는다. 1단계의 당사자 표에 적으면 그 거래가 보이게 된다.

5단계: 명시한 이유로 선택하기

자기 망에 대한 사적 접속, 구성 통제, 특정 라우팅 요구, 또는 공급자 정책으로부터의 독립은 모두 좋은 이유다. 해당하는 것을 적고 그것이 작동함을 보여 줄 시험을 설계하라.

다음으로 지루한 부분을 확인하라. 호스트는 패치되었는가, 옛 키는 사라졌는가, 보존은 기록한 대로인가, 장애 후에 서비스를 복구할 수 있는가? 그 네 가지 답은 프로토콜 이름보다 훨씬 잘 신뢰 모델을 설명한다.

6단계: 나가는 길을 계획하기

호스트에서 어떻게 옮겨 갈지 미리 정하라. 구성이 어디에 있고, 클라이언트 프로필을 어떻게 다시 발급하며, 보관한 기록은 어떻게 되는지. 나가는 계획이 없는 셀프 호스팅 서비스는 없앨 수 없는 의존이 된다.

AWS 공동 책임 모델은 AWS 밖에서도 유용한 틀인데, 같은 질문을 강요하기 때문이다. 어느 계층이 당신의 것이고 어느 계층이 다른 사람의 것인가. 1단계의 모든 당사자에 대해 답하면 신뢰 모델은 구호가 아니게 된다.