기기 두 대, 하나의 Wi-Fi, 서로 다른 VPN 출구: 무엇이 결정하는가

같은 가정용 공유기에 연결된 노트북 두 대가 서로 다른 VPN 출구로 인터넷에 나갈 수 있으며, 공유 Wi-Fi는 여기에 아무 관여도 하지 않습니다. 결과를 결정하는 것은 터널이 어디서 도는지, 그리고 각 요청의 경로를 어떤 정책이 고르는지입니다. 반대 믿음도 똑같이 흔하고 똑같이 틀렸습니다. 프로필이 따로인 기기 두 대가 자동으로 공인 주소 두 개를 만드는 것은 아닙니다. 두 오류 모두 주소 하나를 셋처럼 다루는 데서 나옵니다.

주소 세 개, 그중 나가는 것은 하나뿐

노트북에는 로컬 세그먼트에서 자신을 식별하는 가정용 LAN 주소가 있고, VPN 내부에서 할당된 터널 주소도 있을 수 있습니다. 둘 다 원격 서비스에는 보이지 않습니다. 그 서비스가 기록하는 것은 경로상의 어떤 변환을 거친 뒤 패킷을 최종적으로 보내는 기기의 공용 출구 주소입니다.

여기서 생기는 혼란의 대부분을 설명하는 구분을 RFC 3022가 제시합니다. 전통적인 NAT는 내부 주소를 공인 주소로 매핑하고, 포트 변환은 여러 내부 주소가 동시에 하나의 공인 주소를 공유하게 합니다. 공인 주소 하나에 기기 여러 대인 가정은 두 번째 경우이며, 이는 거의 모든 곳에서 기본값입니다.

프로필이 아니라 공인 주소를 세십시오. 터널 주소가 다르고 출구 정책이 같은 클라이언트 두 개는 관측되는 주소 하나를 만들고, 경로가 다른 출구를 가진 클라이언트 하나는 다른 주소를 만들 수 있습니다. 그 한 번의 비교가 시험의 전부입니다. 나머지는 모두 먼 쪽에 대한 가정입니다.

두 출구를 실제로 다르게 만드는 것

인터넷 직전의 마지막 기기가 그 트래픽에 다른 공인 주소를 쓰면 출구가 다릅니다. VPN이 다른 위치에서 종료되거나, 출구 풀이 다른 주소를 할당하거나, 제공자가 요청을 다른 출구로 라우팅할 때 그렇게 됩니다. 셋 모두 먼 쪽에서 내리는 정책 결정이며, 어느 것도 가정용 공유기에서는 보이지 않습니다.

같은 프로필로 각자 클라이언트를 돌리는 기기 두 대는 보통 같은 풀에 들어가고 주어진 세션에서 같은 출구를 받는 일이 많습니다. 이는 결함이 아니라 공유 풀의 정상 동작입니다. 서로 다른 출구를 얻으려면 보통 클라이언트를 두 번 설정하는 대신 서비스에 서로 다른 할당을 요청해야 합니다.

보장을 전제로 설계하기 전에 동시 접속에 관한 서비스 약관을 읽으십시오. 두 번째 로그인은 접속 허가이지 전용 주소의 약속이 아닙니다. 약관이 침묵하면 가정하지 말고 제공자에게 물어보십시오. 그 답은 어떤 클라이언트 설정보다 설계를 더 많이 바꿉니다.

프로필이 따로라고 해서 출구가 따로인 이유는 아닙니다

프로필은 VPN에 도달하는 방법과 인증 방법을 설명하며, 그 뒤에 무슨 일이 일어나는지는 거의 말하지 않습니다. 출구는 먼 쪽이 고르고, 라우팅과 주소 풀, 변환 정책이 그곳에 있습니다. 프로필을 두 번째 기기에 복제하면 클라이언트 구성이 복제될 뿐, 서버의 결정이 복제되지는 않습니다.

반대도 성립합니다. 라우팅과 변환 정책이 그렇게 만들어졌다면 VPN 서버 하나가 여러 공용 출구를 제시할 수 있고, 반대로 분리된 서버들이 하나의 하위 출구로 이어질 수도 있습니다. 따라서 구성에 적힌 서버 이름의 개수는 주소 개수에 대해 아무것도 말해 주지 않습니다. 그래서 이 답을 구성 안에서 찾는 것은 잘못된 접근입니다.

믿을 수 있는 답은 사용하려는 구성 자체를 통해 만든 요청에서만 나옵니다. 나머지는 모두 추론입니다.

분리를 어디에 둘 것인가

공유기 터널은 온 가정을 덮으므로 편리하고, 그 뒤의 모든 기기에 공유 출구를 정확히 하나 만들어 줍니다. 기기마다 클라이언트를 두면 기기별 통제가 가능하지만, 모든 기기가 준비되어 있고 계속 준비된 상태로 유지되어야 합니다. 정책을 다룰 수 있는 공유기는 그 중간에서 기기별로 경로를 고르며, 재접속과 DHCP 변경을 넘겨 기기를 안정적으로 식별할 수 있을 때만 동작합니다.

공유기에 사설 DHCP 임대를 하나 더 만드는 것은 공인 주소를 하나 더 만드는 것과 같지 않습니다. 그것은 로컬에서 보이는 모습만 바꾸고 출구는 그대로 둡니다. 분리는 출구 정책 안에 있으며, 그 정책이 공유기에 있든 VPN 서비스에 있든 같습니다.

어떤 형태를 고르든 소유권을 적어 두십시오. 누가 기기를 준비하고, 누가 그 자격 증명을 교체하며, 누가 의도한 경로를 쓰지 않게 된 것을 알아차리는지.

실제로 받은 출구를 확인하십시오

중요한 애플리케이션에서 확인하고, 두 기기에서 같은 주소 체계를 비교하십시오. 한쪽의 IPv4 결과와 다른 쪽의 IPv6 결과는 어느 쪽에 대해서도 아무것을 증명하지 못합니다. 그런 다음 재접속 후 다시 확인하십시오. 풀 할당은 세션 사이에 바뀔 수 있습니다.

터널 정책 내부의 터미널에서 실행하고, 정책을 우회하는 기기에서 실행하지 마십시오. 잘못된 호스트는 자신만만한 잘못된 답을 냅니다.

curl -4 -sS https://api.ipify.org; echo
curl -6 -sS https://api64.ipify.org; echo
ip route get 1.1.1.1

두 기기가 같은 IPv4 주소를 출력한다면, 터널이 몇 개 올라가 있든 출구 하나를 공유합니다. 그다음 터널이 실패할 때 무슨 일이 일어나는지 정하십시오. 직접 경로로 되돌아가는 클라이언트는 두 기기를 다시 집 주소로 돌려놓고, 분리는 오류 없이 사라집니다. 이 구성을 두 개의 출구라고 부르기 전에 그 폴백 동작을 확인하고, 서로 다른 주소는 네트워크의 결과이지 두 개의 익명 신원이 아니라는 점을 기억하십시오.