VPN 터널이란 무엇이며 보호는 어디서 끝나는가
터널은 이미 갖고 있던 링크 위에서 선택된 패킷을 두 번째 봉투에 담는다. 요청 하나를 따라가며 사이트가 실제로 기록하는 주소를 확인하라.
클라이언트는 연결됨이라고 하고, 자물쇠는 잠겨 있는데, 사이트는 여전히 당신 집의 주소를 기록한다. 실패한 것은 없다. 터널은 Wi-Fi나 모바일 링크를 대체하지 않는다. 선택된 패킷 둘레에 두 번째 봉투를 씌워, 이미 갖고 있던 네트워크로 그 봉투를 보낸다. 이 속임수를 이해하는 일은 대개 요청 하나를 따라가 봉투가 어디서 열리는지 보는 것이며, 집 주소 유출부터 멈춘 대형 다운로드까지 거의 모든 혼란스러운 증상이 그 경계에서 나온다.
두 개의 봉투, 하나의 물리 링크
노트북은 공유기와의 정상 연결을 유지하고, 공유기는 통신사와의 정상 연결을 유지한다. 터널이 올라와도 그 경로에서는 아무것도 바뀌지 않는다. 바뀌는 것은 선택된 패킷이 가상 인터페이스로 넘겨져 VPN 피어를 향한 새 패킷 안에 싸이고, 물리 링크를 통해 평범한 트래픽으로 전송된다는 점이다.
받는 쪽은 봉투를 열어 원래 패킷을 목적지로 전달하는 장치다. 두 끝 사이에서 관찰자는 바깥 헤더를 보고, 프로토콜이 암호화하지 않는 한 안쪽에 대해서는 아무것도 보지 못한다. 대부분의 소비자용 프로토콜은 암호화하며, 일반적인 기법은 그것을 요구하지 않는다.
그래서 가상 인터페이스는 실제이면서 동시에 오해를 부른다. 그것은 주소와 최대 전송 단위를 가진 커널 객체로 존재하고, 운영체제는 다른 인터페이스와 마찬가지로 그리로 트래픽을 보낸다. 케이블이 아니며, 그 존재는 구성 요소가 설치되었다는 것만 증명한다. 브라우저가 그것을 쓰는지는 라우트가 결정하지, 인터페이스가 올라와 있는지가 아니다.
요청 하나의 여정을 지켜보라
목적지를 고르고 커널에 어떤 인터페이스를 쓸지 물어라. 이 명령 하나로 터널이 무언가를 하는지에 대한 대부분의 논쟁이 정리된다:
ip route get 203.0.113.7
ip -brief addr show
ip -4 addr show dev wg0라우트 출력이 터널 인터페이스를 지목하면 패킷은 싸인다. 물리 인터페이스를 지목하면 싸이지 않으며, 클라이언트를 몇 번 재시작해도 바뀌지 않는다. 두 번째 명령은 두 인터페이스를 나란히 보여 주며, 주소 없이 또는 잘못된 주소 체계로 올라온 터널을 이렇게 찾아낸다.
그다음 봉투 안쪽에서 첫 홉을 보고, 바깥의 첫 홉과 비교하라:
traceroute -n -m 3 203.0.113.7
sudo tcpdump -ni wg0 -c 5터널 안에서 첫 홉은 피어의 내부 주소이지 당신의 공유기가 아니다. 터널 인터페이스에서 캡처하면 안쪽 패킷이 보이며, 그것이 애플리케이션이 보낸다고 믿는 트래픽이다. 동시에 물리 인터페이스에서 캡처하면 바깥 패킷이 보이고, 둘을 함께 보는 것이 터널이 실제로 하는 일의 가장 명확한 시연이다.
세 개의 주소, 그리고 사이트가 보는 것은 하나
사람들은 이것을 끊임없이 혼동하고, 그 혼동이 잘못된 유출 보고를 만든다. 서로 다른 헤더의 서로 다른 필드이며 수명도 다르다.
| Address | Where it appears | Who can see it |
|---|---|---|
| Endpoint address | Outer header, the peer you connect to | Your access network and the path to it |
| Inner tunnel address | Inside the envelope, on the virtual interface | The peer, and anything the peer routes to |
| Exit address | Source of the packet that reaches the website | The website and its upstream |
가상 어댑터 옆의 숫자는 두 번째 행이다. 그것은 사이트가 기록하는 주소가 아니며, 이를 당신의 공용 IP라고 인용하는 것은 그냥 틀렸다. 사이트가 보는 주소는 출구가 부여하며, 사설 네트워크 터널에서는 공용 출구가 아예 없을 수 있다. 목적지가 인터넷이 아니라 조직 내부에 있기 때문이다.
사이트 간 터널은 끝점이 다를 뿐 같은 메커니즘이다. 두 공유기가 네트워크 사이의 트래픽을 싸고, 어느 개별 장치에도 클라이언트가 설치되어 있지 않다. 봉투는 원칙적으로 동일하고, 관리 경계는 그렇지 않다.
봉투가 열리는 곳, 그리고 그것을 살아남는 것
터널은 그 피어에서 끝난다. 애플리케이션 자체의 암호화가 더 멀리 미치면 그 경계를 넘어 살아남으며, HTTPS가 보통 그렇다. 브라우저 세션이 사이트에서 끝나므로 출구는 읽을 수 없는 암호문을 전달한다.
그 밖의 것은 기본적으로 살아남지 않는다. 암호화되지 않은 요청은 카페의 Wi-Fi에서 읽혔던 것과 똑같이 출구에서 읽히며, 터널은 애플리케이션이 애초에 갖지 못했던 보호를 더하지 않는다. 마찬가지로 출구의 방화벽 규칙과 전달 정책이 다음에 무슨 일이 일어날지 결정한다. 성공한 핸드셰이크는 피어 연결에 관한 사실이지 나머지 여정에 관한 것이 아니다.
오버헤드는 또 다른 눈에 보이는 결과다. 각 패킷은 추가 헤더를 나르고, 바깥 전송이 자기 헤더를 더할 수 있어 패킷당 쓸 수 있는 페이로드가 줄어든다. 최대 전송 단위가 고정된 경로에서 터널이 ping은 통과시키고 큰 업로드는 멈추게 하는 이유가 바로 이것이다.
애플리케이션이 실제로 지난 경로를 확인하라
마지막 단계는 기계 전반이 아니라 특정 애플리케이션을 확인하는 것이다. 목적지를 해석하고, 그 주소의 라우트를 보고, 그다음 연결이 열려 있는 동안 관찰하라:
getent hosts example.com
ip route get "$(getent hosts example.com | awk '{print $1; exit}')"
ss -tnp state established '( dport = :443 )'라우트가 터널을 지목하는데 소켓 목록이 물리 인터페이스의 출발지 주소를 가진 연결을 보여 준다면, 애플리케이션이 특정 무언가에 묶여 있거나 두 번째 터널이 기본 라우트를 두고 경쟁하는 것이다. 이것은 라우팅 문제이며, 클라이언트의 상태 화면이 아니라 이 세 출력으로 답할 수 있다.
RFC 4301 보안 아키텍처는 IPsec에서 이 싸기의 IP 계층 버전을 설명하며, 같은 계층 논리가 WireGuard와 OpenVPN에도 적용된다. 안쪽 패킷과 바깥 패킷을 별개의 객체로 가리킬 수 있게 되면, 터널 동작의 대부분은 더 이상 신비롭지 않고 당신이 읽을 수 있는 라우팅 표가 된다.