암호화된 트랜짓은 캐리어에 대한 접근을 허용하지 않는다

승인된 게이트웨이 두 대가 신뢰도가 낮은 네트워크의 트래픽을 제한된 전송 네트워크 너머로 운반한다. 페이로드를 암호화하면 일반적인 트랜짓 관찰자에게는 읽을 수 없게 되는데, 사람들이 가장 먼저 설계하고 나서는 더 이상 생각하지 않는 부분이 바로 이것이다. 암호화가 하지 않는 일은 신뢰도가 낮은 쪽이 어떤 자원에 도달할 수 있는지를 정의하는 것이다. 설계에는 두 개의 경계가 필요하다. 운반되는 대화를 둘러싼 경계와 캐리어 자체에 대한 접근을 둘러싼 경계다.

아래 단계를 순서대로 수행하고, 어느 단계에서든 실패는 구성 조정이 아니라 설계 변경으로 다루어라.

구성을 건드리기 전에 두 경계를 모두 정의하라

첫 번째 경계는 대화다. 어떤 게이트웨이 쌍이 터널을 세울 수 있고, 어떤 내부 트래픽이 그 안을 통과할 수 있는지다. 두 번째는 캐리어다. 신뢰도가 낮은 호스트가 터널 밖에서 어떤 주소와 서비스에 도달할 수 있는지다. 팀은 보통 첫 번째를 만들고 두 번째는 이미 존재하던 라우팅에서 물려받는다. 그래서 제한된 설계가 조용히 넓은 설계가 된다. 검토에서 신뢰도가 낮은 호스트가 아무도 승인하지 않은 무언가와 대화하고 있다는 사실이 드러날 때, 그 물려받은 것이 흔한 근본 원인이다.

둘 다 주소, 포트, 방향의 목록으로 적어라. 목록을 적을 수 없다면 경계는 아직 정의되지 않은 것이다.

단계 1: 바깥 터널을 제한하라

캐리어 쪽 인터페이스에서는 터널에 필요한 것만 허용하라. 두 게이트웨이 주소 사이의 UDP 500 및 4500의 IKE, 그리고 NAT 트래버설을 쓰지 않는 곳의 ESP다. 그 인터페이스로 들어오는 나머지 모든 것은 관리 프로토콜을 포함해 거부하라. ESP 명세는 보호 서비스를 다루지만, 게이트웨이가 캐리어 자신의 어떤 서비스를 쓸 수 있는지에 대해서는 아무 말도 하지 않는다. 이를 명시적 허용 목록으로 표현해, 새로 공개된 캐리어 서비스가 기본적으로 도달 가능해지지 않게 하라.

이 규칙 집합이 설계를 피어링 약정이 아니라 트랜짓 설계로 만든다.

게이트웨이 콘솔이 아니라 신뢰도가 낮은 쪽에서 확인하라. 그곳의 호스트는 터널이 올라오기 전에도 캐리어의 DNS 서버에 도달하지 못해야 한다.

단계 2: 원격 게이트웨이가 무엇을 전달하는지 결정하라

원격 끝에서는 복구된 트래픽이 특정한 곳으로 가야 한다. 어떤 내부 서비스가 허용되고, 어느 소스 범위에서 오며, 응답이 대칭일 것으로 기대하는지를 정의하라. 관리 접근은 따로 검토하라. 같은 게이트웨이가 트랜짓 계획의 일부가 아니었던 관리 인터페이스를 흔히 노출하기 때문이다.

복호화 성공에서 멈추는 다이어그램은 가장 중요한 결정을 건너뛴 것이다.

단계 3: 계층별 소유권을 유지하라

트랜짓 장비는 여전히 바깥 패킷을 수신하고 전달하므로 패치와 용량 계획이 필요하다. 터널 종단점은 보호된 프로토콜을 처리하고 내부 트래픽을 자신의 전달 경로에 노출하므로 자체 규칙과 자체 모니터링이 필요하다. 최종 애플리케이션은 페이로드를 처리하며, 불투명한 페이로드는 복호화된 다운로드가 무해하다는 증거가 아니다.

각 계층에 소유자를 지정하라. 소유자가 없는 계층이 바로 흘러가 버리는 계층이다.

단계 4: 검증한 뒤 당국에 넘겨라

터널이 올라오고 캐리어 규칙이 적용된 상태에서 바깥 경로를 검증하라. 그런 다음 신뢰도가 낮은 쪽이 도달해서는 안 되는 각 자원을 시험하고, 실패가 거부인지 경로를 숨기는 타임아웃인지 확인하라. 가용성과 자원 한도도 확인하라. 암호화된 링크도 포화될 수 있기 때문이다.

규제 또는 기밀 환경이라면 설계를 책임 보안 당국에 가져가 그 승인된 분리 아키텍처를 사용하라. VPN 구성과 개념적 설명은 인증을 성립시키지 않는다. 그 단계는 서류 작업이 아니다. 설계가 존재해도 되는지를 결정한다.