VPN 홉 두 번 연속: 실제로 누가 당신의 트래픽을 볼까?

모든 클라이언트 프로필은 서버 하나를 지정하므로 사용자 입장에서는 터널 하나와 보호가 끝나는 지점 하나가 있습니다. 그 첫 게이트웨이 뒤에서 무슨 일이 일어나는지는 클라이언트가 결코 보지 못하는 설계 결정이며, 흔한 두 설계는 검사 아래에서 매우 다르게 동작합니다. 직렬 체인에서는 첫 게이트웨이가 복호화한 뒤 다시 암호화합니다. 중첩 체인에서는 바깥 계층을 제거하고 자신이 열 수 없는 안쪽 터널을 전달합니다. 홉 수는 둘 다 같으며, 그래서 차이는 세는 것이 아니라 그려야 합니다.

클라이언트에서 시작해 양 끝을 이름 붙이세요

사용자가 시작하는 곳, 즉 연결 프로필에서 시작합니다. 여기에는 원격 주소 하나, 인증 방식 하나, 그리고 설계가 지원하면 경로 목록이 들어 있습니다. 클라이언트에서 게이트웨이 A까지의 바깥 터널에 이름을 붙이고 예시 주소를 주세요. 클라이언트의 터널 주소 10.77.0.2, A의 10.77.0.1, 그리고 A의 공개 엔드포인트 198.51.100.10이며, 모두 TEST-NET-2 문서용 범위에서 가져와 예시 속 어떤 것도 실제 호스트와 충돌하지 않습니다.

그 프로필에는 게이트웨이 B에 대한 언급이 없고, 그것은 결함이 아닙니다. 두 번째 홉은 A에 속하며, 클라이언트의 유일한 의무는 트래픽을 A로 보내고 돌아오는 것을 받아들이는 것입니다. A가 터널을 종료하는지, 전달하는지, 새로 여는지는 이 안내의 나머지가 답하는 질문이며, A가 무엇을 읽을 수 있는지를 결정합니다.

직렬: A가 복호화한 뒤 다시 암호화합니다

직렬 설계에서 A는 트래픽을 두 번 종료합니다. 클라이언트에서 보호를 벗겨 애플리케이션의 IP 패킷을 얻고, 그 패킷을 A가 B 쪽으로 만드는 두 번째 터널로 보냅니다. 이 두 동작 사이에서 패킷은 A의 전달 경로 안에 사설 목적지로 주소가 지정된 평범한 IP 패킷으로 놓입니다.

그 결과 두 가지를 분명히 말할 만합니다. A는 안쪽 패킷에 정책을 적용할 수 있으며, 경로, 필터 규칙, 출발지와 목적지 기록의 형태입니다. 또한 A는 두 벌의 자격 증명을 보관해야 하며, 하나는 클라이언트에 대한 서버로서, 하나는 B의 클라이언트로서입니다. 보호는 매 순간 존재하지만 보호되는 대상은 A에서 신원을 바꿉니다.

그렇다고 A가 애플리케이션의 평문을 읽는 것은 아닙니다. 클라이언트와 서비스가 TLS를 실행하고 서로의 인증서를 검증할 때, A는 읽을 수 있는 요청이 아니라 TLS 레코드 흐름을 봅니다. 그 보호가 어디서 끝나는지 확인하려면 터널 그림이 아니라 서비스의 인증서 체인을 봐야 합니다.

중첩: A는 바깥 계층만 제거합니다

중첩 설계에서는 클라이언트가 먼저 B로 가는 안쪽 터널을 만들고, 그 터널을 바깥 터널 안에 담아 A까지 갑니다. A는 바깥 헤더를 벗기고 안쪽 터널을 찾아 그 키를 보관하지 않은 채 전달하므로, 안쪽 보호는 여전히 B에서 끝납니다.

그러면 클라이언트의 상향 링크는 두 계층을 나르고, A와 B 사이의 경로는 하나를 나릅니다. A는 안쪽 터널의 바깥 주소를 봅니다. 그것으로 트래픽이 있다는 것과 대략 어디로 가는지는 알 수 있고, 페이로드를 읽기에는 부족합니다. 직렬 경우와의 차이는 이것이 전부이며, 어떤 홉 카운터도 그것을 보여 주지 않습니다. A가 여전히 할 수 있는 일은 읽을 수 없는 것을 전달하지 않는 것이며, 그것은 그 게이트웨이 운영자에게 언제나 열려 있습니다.

중첩은 그 속성의 대가를 치릅니다. 계층이 늘 때마다 헤더 오버헤드가 더해지므로 MTU와 MSS 계획은 정돈이 아니라 필수가 되고, 한 계층에서 작동하는 경로가 두 계층에서는 큰 패킷을 조용히 버릴 수 있습니다. 각 계층은 재연결과 연결 유지 동작도 따로 필요하며, 한 계층의 실패는 다른 계층을 통해 부분 장애처럼 보입니다.

터널만이 아니라 관찰자를 그리세요

터널은 그림에서 쉬운 부분입니다. 설계의 주제는 관찰자이므로 관점마다 한 줄을 쓰고 각자가 실제로 무엇을 읽을 수 있는지 채우세요.

두 줄은 늘 혼동됩니다. A의 운영자와 클라이언트 터널의 제공자입니다. 둘은 같은 주체일 수 있으며, 게이트웨이 이름이 다르다고 해서 독립되지 않습니다. 독립된 소유에는 별도의 관리 통제, 별도의 자격 증명, 별도의 기록이 필요합니다.

메타데이터는 두 설계 모두에서 살아남습니다. 시각, 패킷 크기, 연결 수는 각 홉에서 계속 관찰 가능하므로 두 홉은 신호를 없애는 것이 아니라 상관 비용을 높입니다. 불가시성을 약속하는 설계는 누군가 그것에 의존하기 전에 그 목록과 대조해야 합니다.

고르기 전에 실패 경로를 걸어 보세요

사용자가 만나게 될 순서대로 클라이언트에서 일부러 망가뜨립니다. 인터페이스와 그 MTU부터 시작하세요. 중첩은 인증에서 실패하기 훨씬 전에 패킷 크기에서 실패하기 때문입니다.

ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1

그다음 보호 엔드포인트를 가정하지 말고 확인합니다. 올라와 있는 터널 안쪽에서 서비스에 인증서를 요청하고, 클라이언트가 보는 체인과 서비스가 실제로 제시하는 체인을 비교합니다. 다시 서명하거나 가로채는 게이트웨이는 그 인증서를 바꾸며, 검사는 명령 하나로 드러납니다.

openssl s_client -connect intranet.example.com:443 -brief < /dev/null

재연결 행렬로 마무리합니다. 클라이언트 터널이 끊기고, B의 터널이 끊기고, A와 B 사이의 경로가 바뀝니다. 무엇이 돌아오고 무엇이 돌아오지 않는지, 안쪽 연결이 의도한 전달자 밖의 경로로 떨어지는지 적습니다. 각 시험이 사용한 주소를 기록하세요(다른 접속망에서 반복하면 다른 질문에 답하게 되기 때문입니다). 재연결마다 MTU 점검도 반복하세요. 경로가 바뀌면 설정 한 줄도 움직이지 않은 채 쓸 수 있는 크기가 줄어들 수 있습니다.

A가 안쪽 패킷에 정책을 적용해야 할 때, 또는 클라이언트가 겹친 터널 두 개를 돌릴 수 없을 때 직렬을 고릅니다. 안쪽 페이로드가 A에서 읽히지 않아야 할 때 중첩을 고릅니다. 선택을 관찰자와 MTU 수치와 함께 적어 두면, 다음 사람은 질문 하나에 답하려고 그림 전체를 다시 그리지 않아도 됩니다.