사용한 VPN 출구 주소를 기록하고 검증하는 방법
클라이언트 앱은 위치 이름을 보여 줄 뿐, 트래픽이 실제로 나간 주소를 보여 주지 않습니다. 연결할 때 출구 IP를 기록하고 직접 기준선과 비교하세요.
데스크톱 VPN 클라이언트에 어떤 서버를 썼는지 물으면, 정직한 답은 보통 위치 이름입니다. 그 이름은 당신이 고른 진입 지점이고, 트래픽이 실제로 나간 주소는 전혀 다른 장비일 수 있습니다. 앱 안에는 두 번째 숫자를 남기도록 설계된 것이 없으므로 기록은 사용하는 순간에 만들어야 합니다. 두 가지 방법이 있고, 지원 문의를 견디는 것은 그중 하나뿐입니다.
두 개의 기록, 실제로 존재하는 것은 하나
클라이언트 자체의 화면은 기껏해야 선택한 위치와 시간 표시의 목록입니다. 이는 누락이 아니라 설계상의 판단으로, 주소는 운영상의 세부 사항이고 할당 사이에서 바뀌며 매핑을 공개하면 지원과 남용 처리 모두 어려워집니다. 제공자가 자기 네트워크 앞에 클라우드 인스턴스를 두는 이유는 바로 엔드포인트가 아무에게도 알리지 않고 옮겨 갈 수 있게 하기 위해서입니다. 앱이 보여 주는 것은 당신이 한 선택이며, 트래픽이 지난 경로가 아닙니다.
직접 만들 수 있는 기록은 한 줄에 공개 주소 하나와 UTC 시각 하나를 담은 로컬 파일입니다. 더 작고 못생겼지만, 외부 관찰자도 볼 수 있는 것을 정확히 기술하기 때문에 훨씬 쓸모 있습니다.
방법 A: 출구 주소를 직접 기록하기
에코 서비스는 요청이 도착한 원본 주소를 돌려주며, 정의상 그것이 출구 주소입니다. 기록은, 경로와 DNS가 자리 잡기 전에 연결되었다고 말하는 클라이언트가 터널 이전 주소를 적어 첫 줄부터 로그를 오염시키므로, 터널이 연결되었다고 보고한 뒤에 실행하세요.
#!/bin/sh
umask 077
log="$HOME/vpn-exit.log"
printf '%s %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$(curl -fsS https://api.ipify.org)" >> "$log"두 가지 세부가 그 조각을 장식이 아니라 쓸 만한 것으로 만듭니다. 시각과 주소가 한 줄을 공유하므로 나중의 분석이 레코드를 짝지을 필요가 없고, umask 077 파일을 만든 순간부터 비공개로 유지합니다. 부팅마다 한 번이 아니라 연결마다 한 번 실행하고, 장치마다 파일 하나를 두세요.
로그는 언제 터널을 썼고 어느 네트워크에서 나타났는지를 남기며, 이는 계수기보다 브라우징 기록에 가깝습니다. 스스로 변호할 수 있는 보관 기간을 고르고, 파일을 공유 동기화 폴더 밖에 두고, 의도적으로 지우세요.
방법 B: 제공자에게 이력 요청하기
일부 제공자는 연결 로그를 보관하고 지원 질문에 시각과 서버 이름으로 답합니다. 그 기록은 당신의 트래픽이 아니라 그들의 인프라를 기술하며, 보관 기간과 확인하려는 의지가 값어치의 전부입니다. 또한 세션을 기술할 뿐 개별 요청은 아닙니다. 기간은 보통 짧고, 터널 제공자 쪽에서 측정됩니다.
로그를 남기지 않는다고 광고하는 제공자는 요청해도 이를 내줄 수 없고, 클라이언트 측의 최근 위치 목록은 같은 것이 아닙니다. 로그가 없는 제공자에게 출구 주소를 요구하면 대개 그 데이터가 왜 없는지에 대한 설명으로 끝납니다.
지원 문의에서 각 기록이 증명할 수 있는 것
두 기록은 서로 다른 질문에 답하며, 비교가 관념적이지 않게 되는 지점은 바로 그 표입니다.
| Question | Your local log | Provider record |
|---|---|---|
| Which address did the traffic leave from? | Yes, for the moment it was captured | Usually not disclosed |
| Was the tunnel in use at 14:20? | Yes, if the capture ran | Yes, within the retention window |
| Why did a location get slower? | Yes, by comparing addresses over time | Sometimes, as an infrastructure note |
| Who sent this specific request? | No | No |
당신 손에 있는 것은 첫 번째 열뿐입니다. 제공자 기록은 어떤 계정이 특정 시각에 연결되어 있었음을 확인할 수 있지만, 어떤 요청이 터널을 썼는지는 확인할 수 없고, 제공자가 운영 세부로 취급하는 주소를 지목하지도 않습니다. 어느 기록도, 공유된 출구 주소가 같은 분에 많은 고객을 실을 수 있기 때문에, 사람을 특정하지 못합니다.
어느 쪽을 믿기 전에 둘 다 기준선과 비교하세요
주소만으로는 아무것도 증명하지 못합니다. 연결 전에 직접 주소를, 연결 후에 터널 주소를 기록하고 비교하세요. 값이 같다면 그 요청은 터널을 지나지 않은 것이며, 원인은 분할 터널, 우선 프록시, 또는 직접 경로로 되돌아간 클라이언트입니다.
curl -fsS https://api.ipify.org; echo
curl -fsS https://api64.ipify.org; echo
dig +short TXT o-o.myaddr.l.google.com @1.1.1.1DNS와 IPv6에 대해서도 같은 비교를 반복하세요. 주소 에코는 HTTP 요청 하나의 경로를 증명할 뿐 어느 확인자가 답했는지는 말해 주지 않으므로, 한쪽에서 새는 장치가 다른 쪽에서는 완전히 건강해 보일 수 있습니다.