피어 투 피어 VPN에는 여전히 중앙 의존성이 있다

피어 투 피어는 애플리케이션 패킷이 어떻게 이동하는지만 설명한다. 피어들은 여전히 서로를 찾고, 자신이 누구인지 증명하고, 때로는 직접 경로를 만들 수 없을 때 릴레이에 의존해야 했다. 이는 세 가지 별개의 서비스이며, 배포는 데이터에 대해서는 피어 투 피어이면서 나머지 모든 것에 대해서는 완전히 중앙집중적일 수 있다. 설계를 비교한다는 것은 그림의 화살표가 아니라 이 작업들을 비교하는 것이다.

중앙 전달 화살표가 없는 그림은 등록 기관, 발견 서비스, 릴레이를 숨길 수 있으며, 이들은 모두 운영 의존성이다.

직접 경로, 공유 제어 평면

패킷을 직접 교환하는 두 머신도 인증서를 발급한 공동 기관과 각자에게 상대가 어디 있는지 알려 준 서비스에 의존할 수 있다. 두 역할 중 어느 것도 애플리케이션 트래픽을 전달하지 않으므로 토폴로지 그림에서 빠진다. 그 기관이나 서비스가 중단되면 기존 세션은 계속될 수 있지만 새 피어는 참여할 수 없다. 세션을 시작하는 것과 계속하는 것의 차이가 어떤 설계에도 먼저 물어야 할 질문이다.

하나의 호스트가 모두 수행하더라도 작업마다 따로 그려라. 그렇지 않으면 그림은 분산된 데이터 평면을 보여 주면서 새 피어마다 같은 두 서비스가 필요하다는 운영 현실을 숨긴다.

발견, 신뢰, 릴레이는 세 가지 작업

Nebula의 설계는 문서가 이들을 분리해 두기 때문에 유용한 예다. 호스트는 신원을 위한 인증서를 지니고, 등대는 어디에 있는지에 답하며 NAT 통과를 돕고, 릴레이는 직접 경로를 세울 수 없을 때 트래픽을 전달한다. 릴레이 역할은 등대 역할과 의도적으로 구분되므로, 등대에 도달할 수 있다고 해서 특정 쌍이 대화할 수 있는 것은 아니다. 다른 제품은 경계를 다른 곳에 긋기 때문에 이것은 템플릿이 아니라 사례다.

제안된 배포에 대해 직접 연결할 수 없는 쌍을 위한 지원되는 대체 경로를 적어 두라. 실패한 홀 펀치는 하나의 네트워크에 대한 하나의 데이터 점일 뿐, NAT 뒤의 두 피어가 절대 만날 수 없다는 증거가 아니며, 직접 연결이 임의의 정책 아래에서도 작동한다는 반대 주장도 똑같이 근거가 없다.

각 의존성은 어디에서 실패하는가

시험 대상 의존성을 사용할 수 없는 동안 네 가지 경우를 따로 평가하라: 기존 피어 트래픽, 완전히 새로운 피어 연결, 끝점이 바뀐 피어, 방금 취소된 접근이다. 각각 다른 서비스에 의존하고 다르게 실패한다. 기존 세션은 발견 중단을 견딜 수 있지만 취소된 키는 여전히 거부되며, 새 피어는 전달과 무관한 이유로 실패할 수 있다. 하나에서 결론을 내리지 말고 개별적으로 시험하라.

한 번의 중단을 견딘 연결이 무기한의 독립을 증명하지는 않는다. 당신이 일으킨 중단이 그 경로를 끊는 중단이 아니었음을 증명할 뿐이며, 무엇을 일으켰는지 기록해 두었다면 그것도 유용한 정보다.

어떤 중단을 견딜 수 있는지 물어라

비슷하게 들리는 요구는 서로 다른 설계로 이어진다. 단일 전달 병목을 피하는 것은 공급자가 호스팅하는 제어 평면을 피하는 것과 같지 않고, 둘 다 조정자가 중단된 동안 계속 운영하는 것과는 맞지 않는다. 배포가 이 세 가지 중 무엇을 충족해야 하는지 이름 붙이고, 그다음 대응을 확인하라. 첫째를 충족하고 둘째에서 실패하는 설계는 흔하며, 아무도 그것을 완전한 분산형이라고 부르지 않는 한 부정직하지 않다.

발견, 신뢰, 릴레이를 누가 운영하며 각각이 어떻게 대체되는지 기록하라. 그 기록이 있어야 다음 사람이 실제 질문에 답할 수 있다: 이 네트워크는 어떤 장애를 견디며, 공유된 채로 남는 상태를 누가 유지하는가.

분산형이라는 말은 그 장애들을 지목할 때 비로소 제값을 한다. 그 목록이 없으면 그것은 시스템이 아니라 그림을 설명한다.