VPN 클라이언트 두 개를 동시에 실행하는 것은 라우팅 논쟁이지 개인정보 설정이 아닙니다. 더 구체적인 경로를 가진 터널이 트래픽을 받고, 다른 하나는 연결된 채로 유휴 상태로 남습니다. 그러면 회사 게이트웨이는 개인용 출구에서 도착하는 연결을 봅니다만 기기의 회사 클라이언트는 여전히 모든 어댑터를 봅니다. 이 두 사실 중 어느 것이 중요한지 정하는 것이 이 작업의 전부입니다.

경로 테이블이 하나의 승자를 고릅니다

회사 클라이언트가 시작되기 전과 후에 테이블을 캡처하고, 목적지만이 아니라 인터페이스 열을 읽으세요. 외부 터널의 단순한 기본 경로는 /1 쌍이 /0보다 더 구체적이기 때문에 밀려나기 쉽습니다. 리터럴 0.0.0.0/1 및 128.0.0.0/1 쌍은 전체 IPv4 공간을 두 반으로 덮고 어떤 단일 기본 경로도 이깁니다. 설치되면 외부 터널은 여전히 연결된 것으로 표시되고 아무것도 나르지 않습니다.

ip route show default
ip route show | grep -E '^(0.0.0.0/1|128.0.0.0/1)'

정책 라우팅은 기본 테이블을 완전히 무시할 수 있으므로 경로뿐 아니라 규칙도 읽으세요. 표시된 트래픽을 다른 테이블로 보내는 규칙은 기본 테이블을 조회하기 전에 이깁니다. 이렇게 하면 한 애플리케이션은 물리 링크에 남고 나머지는 모두 터널을 씁니다.

ip rule show

Windows는 메트릭으로 결정합니다

Windows에서는 목적지에 대한 메트릭이 가장 낮은 경로가 승자이며, 두 클라이언트가 서로 다른 메트릭으로 기본 경로를 설치할 수 있습니다. 메트릭이 더 낮은 어댑터가 항상 예상한 것이 아니므로, 테이블과 인터페이스 구성을 함께 읽으세요. 인터페이스 메트릭도 설정하는 클라이언트는 경로를 하나도 추가하지 않고 기본 경로를 옮길 수 있습니다. 진 어댑터는 켜진 채로 남아 그냥 아무것도 받지 않습니다.

route print -4
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4DefaultGateway

두 출력을 비교하고 0.0.0.0/0을 가진 인터페이스의 이름을 대세요. 두 클라이언트가 모두 주장하면 메트릭이 결정하므로, 연결 순서 테스트가 기기마다 일관되지 않게 보일 수 있습니다. 어느 출력도 기본 게이트웨이를 보여주지 않으면 클라이언트는 전체 터널로 실행되지 않으며 체인 논리는 의미가 없습니다.

두 관찰자, 두 가지 다른 시각

원격 게이트웨이는 외부 출구에서 오는 연결 하나와 클라이언트가 자기 터널로 전달하는 모든 것을 봅니다. 로컬 클라이언트는 그것들을 만들 권한으로 실행되기 때문에 어댑터, 경로, 다른 터널의 존재를 봅니다. 이 시각을 나누는 것이 요점이며, 클라이언트가 알아챌 수 없다고 주장하는 것이 아닙니다.

클라이언트가 원하는 것을 얼마든지 열거할 수 있다고 가정하고, 대신 게이트웨이의 시각을 위해 설계하세요. 클라이언트가 계속 눈멀어 있다는 데 의존하는 설계는 업데이트 하나면 깨집니다.

DNS와 IPv6가 체인이 새는 곳입니다

DNS는 이긴 리졸버 설정을 따르며, 그것이 패킷이 가는 경로와 같다는 보장은 없습니다. 회사 터널을 통해 도달하는 회사 리졸버는 설계와 일관되지만, 그 밖에서 도달하는 로컬 리졸버는 그렇지 않으며 터널이 숨기려던 이름을 노출합니다. IPv6는 두 번째 누출로, 듀얼 스택 호스트는 터널이 IPv4로만 나르는 목적지로 IPv6를 계속 사용합니다. IPv4 전용 터널은 IPv6 경로나 리졸버에 대해 아무것도 말하지 않으므로 계열을 따로 확인하세요.

ip -6 route show default
resolvectl status | grep -A2 'DNS Servers'

리졸버와 IPv6 경로를 의도적으로 고치고, 그 위에 두 번째 터널을 쌓지 마세요. 이중 캡슐화는 MTU도 소모하므로 체인이 올라온 뒤 페이지가 멈추면 더 작은 내부 MTU를 먼저 시도하세요. 빠르게 응답하는 리졸버가 올바른 리졸버라는 증거는 아닙니다.

관련 글