공유 VPN IP와 전용 VPN IP: 실제로 무엇이 달라지는가
고정된 출구와 공유 풀은 같은 재작성을 거칩니다. 달라지는 것은 받는 포트 블록, 바인딩이 유지되는 기간, 그리고 그 이력을 누구와 공유하는지입니다.
공유 출구와 전용 출구는 같은 재작성을 거칩니다. 게이트웨이는 출발지 주소를 풀의 공인 주소로 바꾸고 포트를 고르며, 차이는 그 풀이 어떻게 만들어졌는지와 바인딩이 얼마나 오래 살아남는지에 있습니다. 이것은 할당 결정이며 암호화 업그레이드가 아닙니다.
그 틀은 대부분의 실무 질문에 한 번에 답합니다. 허용 목록은 바인딩의 안정성을 신경 쓰고, 웹사이트의 사기 검사는 주소의 이력을 신경 쓰며, 둘 다 요금제 이름에는 관심이 없습니다.
두 선택지 모두 하나의 주소 위 포트 매핑
클라이언트가 출구를 통해 연결을 열면 게이트웨이는 출발지 주소를 풀이 내주는 공인 주소로 다시 쓰고 그 주소의 빈 범위에서 출발지 포트를 고릅니다. 같은 출구의 두 가입자는 하나의 IPv4 주소 위 두 개의 포트 블록이 됩니다. 원격 서버는 동시 연결이 많은 하나의 호스트를 보며, 페이로드에는 어느 블록이 누구 것인지 말해 주는 것이 없습니다. 그 포트 매핑이 주소 공유를 애초에 가능하게 하는 메커니즘입니다.
전용 할당은 모양을 바꾸지 않고 그 이야기를 줄입니다. 풀은 계정을 위해 구성원 하나를 보관하고, 운영자는 당신을 고리 안에서 돌리는 대신 그것을 고정하며, 포트는 여전히 당신 자신의 세션 사이에서 공유되고, 주소도 기기로 라우팅되는 대신 출구에서 변환됩니다.
따라서 회선 위 동작은 동일하고, 달라지는 것은 장부뿐입니다.
| Property | Shared pool | Pinned assignment |
|---|---|---|
| Address selected at connect | Any free member of the pool | The one address bound to the account |
| Other subscribers on it | Present, unknown to you | Usually none, though the operator may oversubscribe |
| Stability across reconnects | Depends on pool size and rotation policy | Holds until the operator changes the assignment |
허용 목록은 라벨이 아니라 바인딩을 따라간다
비즈니스 서비스의 IP 기반 접근 규칙은 패킷 헤더의 한 필드를 확인합니다. 그 필드가 고정 값과 일치해야 한다면, 주소가 아무리 많아도 회전하는 풀은 잘못된 도구입니다. 고정 할당은 유지보수가 주소를 옮길 때까지 규칙을 만족하며, 그래서 유지보수 정책이 기능 목록과 같은 대화에 속합니다.
curl -4 -s https://api.ipify.org; echo curl -6 -s https://ifconfig.co; echo
터널을 켠 채로 두 줄을 모두 실행하세요. 첫 번째는 허용 목록이 보게 될 IPv4 출구를 확인하고, 두 번째는 IPv4가 터널을 지나는 동안 IPv6 트래픽이 제공자를 통해 빠져나가는 이중 스택 누출을 잡아냅니다. 두 계열을 모두 받아들이는 서비스는 IPv4 결과가 결코 보여 주지 않는 이유로 허용 목록 검사에 실패할 수 있습니다.
그다음 허용 목록이 필요한 애플리케이션이 터널을 쓰는 그 애플리케이션인지 확인하세요. 분할 터널, 제외된 경로 또는 프록시 설정은 브라우저 테스트가 올바르게 보이는 동안에도 그 앱을 곧바로 밖으로 내보낼 수 있으며, 터널이 끊길 때 트래픽을 차단하는 킬 스위치는 집 주소로 조용히 되돌아가는 것보다 낫고, 허용 목록 워크플로가 잘못된 방향으로 깨지는 방식이 바로 이것입니다.
평판은 주소와 함께 이동한다
공유 출구는 그것을 쓴 모든 사람의 누적된 행동을 짊어지므로 목적지 쪽 점수, 속도 제한, 챌린지 페이지가 그 이력에 반응합니다. 그러면 평범한 브라우징이 보이지 않는 이유로 추가 검증을 만날 수 있습니다. 고정 주소는 기여자 집합을 당신의 계정으로 좁힙니다. 그래도 깨끗하게 도착하지는 않는데, 고정 주소는 재활용되고 데이터센터 대역은 지금 누가 갖고 있든 주거용 대역과 다르게 취급될 수 있기 때문입니다.
계정, 쿠키, 브라우저 지문이 여전히 그 결정의 대부분을 좌우합니다.
평판을 요금제 이름에 붙은 숫자가 아니라 전체 경로의 속성으로 다루세요. 같은 제공자의 두 고객이 서브넷, 목적지 자체의 정책 또는 요청 배후의 계정 때문에 다르게 취급될 수 있습니다.
어느 쪽이든 같게 남는 것
터널은 같은 방식으로 암호화합니다. WireGuard는 여전히 같은 키로 핸드셰이크하고, OpenVPN은 여전히 같은 암호 스위트를 협상하며, 출구 주소는 그 협상에 결코 들어가지 않습니다. 고정 주소에 지불하는 것은 할당 동작이지 더 강한 전송이 아닙니다.
운영자의 가시성도 그대로입니다. 출발지 연결, 타임스탬프, 계정 식별자는 두 방식 모두에서 출구에서 관찰 가능한 채로 남고, 낯선 사람과 주소를 공유한다고 해서 로깅 정책이 생기지는 않습니다. 고정 주소는 세션 사이에서 더 안정적인 식별자 역할을 할 수도 있으며, 이는 전용이 더 사적이라는 가정에 어긋납니다.
목적지가 안정적인 출발지를 요구할 때, 워크플로가 회전을 견디지 못할 때, 또는 공유 이력이 정당한 트래픽을 자꾸 방해할 때 고정을 선택하세요. 유일한 요구가 다른 출구이고 회전에 비용이 들지 않는다면 풀에 머무르세요. 두 가정 중 어느 것도 믿기 전에 위의 두 명령으로 결과를 확인하세요. 당신이 있다고 생각하는 출구와 서버가 보는 출구는 그 사이에서 무엇도 다시 쓰지 않을 때만 같은 필드입니다.