VPN을 호스트에서 실행할까, VM 안에서 실행할까? 결정 안내서
터널의 소유자가 무엇이 무엇을 덮는지를 결정합니다. 호스트 또는 게스트 배치를 고르고, 게스트 안에서 경로·DNS·출구 점검으로 확인하십시오.
게스트 안에서 터널을 만드는 것과 호스트에서 만드는 것은 둘 다 브라우저가 보고하는 주소를 바꾸지만, 비슷한 것은 거기까지입니다. 게스트가 소유한 터널은 키와 기본 경로와 리졸버를 게스트 커널 안에 두고, 호스트는 암호화된 패킷을 하나의 원격 주소로 전달합니다. 호스트가 소유한 터널은 그 반대입니다. 호스트 클라이언트가 세션을 쥐고 경로와 정책을 적용하며, 게스트는 나오는 것을 그대로 빌려 씁니다. 소유자를 잘못 고르면 이후의 모든 증상이 당신을 잘못된 기계로 보냅니다. 명령 두 개면 약 일 분 만에 답이 나오고, 이 안내서의 나머지는 그 답으로 무엇을 할지입니다.
클라이언트를 건드리기 전에 소유자를 정하십시오
규칙은 암호문이 어디서 만들어지는지에 관한 것이지, 어느 기계가 VPN 아이콘을 보여주는지에 관한 것이 아닙니다. 게스트가 만들면 게스트에는 VPN 서버로 가는 동작하는 경로가 필요하고 호스트에서는 아무것도 필요하지 않습니다. 호스트가 만들면 호스트 클라이언트가 로컬 트래픽에 부과하는 정책이 무엇이든 게스트는 호스트를 거치는 경로를 살려내야 합니다.
보통 세 가지 질문이 배치를 대신 골라 줍니다. 게스트의 트래픽이 호스트의 기업 클라이언트를 통과해야 합니까? 그렇다면 터널은 게스트 안에 있습니다. 여러 게스트가 하나의 자격 증명과 하나의 출구 주소를 써야 합니까? 그렇다면 호스트에 있으며 전달이 의도적으로 설정됩니다. 게스트의 트래픽이 호스트 VPN 밖에 완전히 있어야 합니까? 그렇다면 게스트 안의 터널만이 그것을 구조적으로 제공합니다.
답을 VM 이름 옆에 한 줄로 적어 두십시오: guest-owned 또는 host-owned. 여섯 대짜리 실험실에서는 그 메모가 아래 어떤 단계보다 시간을 더 아껴 줍니다. 로그인한 기계에 애초에 없던 터널을 뒤지지 않게 해 주기 때문입니다.
WSL1과 WSL2는 정반대의 사례입니다
WSL1은 가상 머신이 아니므로 배치 질문이 대부분 사라집니다. 그 Linux 바이너리는 번역 계층을 통해 Windows 네트워크 스택 위에서 돌아가고, Linux VPN 클라이언트에는 설정할 독립 인터페이스가 없습니다. 동작하는 배치는 Windows 쪽 터널이며, 배포판은 아무것도 소유하지 않고 결과만 사용합니다.
WSL2는 반대입니다. Hyper-V 가상 스위치 뒤의 가벼운 유틸리티 VM에서 실제 커널을 돌리고, 주소 공간은 호스트 쪽 어댑터를 통해 NAT됩니다. 그래서 배포판 안의 Linux 클라이언트는 물리 Linux 상자에서처럼 동작합니다. 즉 tun0 또는 wg0를 만들고, 자체 경로를 설치하고, 작동합니다. 실패는 호스트 쪽에 있습니다. Windows VPN 클라이언트가 로컬 네트워크의 트래픽을 막는 정책으로 연결하면, WSL2 서브넷을 신뢰할 수 없는 로컬 네트워크로 취급하고 NAT 경로를 끊습니다. 그러면 배포판은 DNS와 외부 접근을 잃지만 자체 터널은 여전히 건강합니다. wg show는 핸드셰이크를 보고하고, ip route는 정상으로 보이며, curl은 멈춥니다.
어떤 수정을 쓸 수 있는지는 Windows 빌드에 달려 있습니다. 오래된 방법은 호스트 클라이언트에서 WSL 서브넷에 대한 예외로, 클라이언트의 로컬 네트워크 또는 분할 터널 설정 아래에 추가합니다. 새로운 방법은 이를 지원하는 Windows 11 빌드의 미러 네트워킹입니다. %UserProfile%\.wslconfig의 [wsl2] 섹션에 networkingMode=mirrored를 넣고 wsl --shutdown을 실행하면, 배포판이 사설 NAT 서브넷 대신 호스트의 인터페이스를 공유합니다. 미러 모드는 localhost와 인바운드 포트의 동작도 바꾸므로 토글이 아니라 이전으로 다루십시오.
NAT, 브리지, 그리고 호스트가 볼 수 있는 것
NAT 아래에서 게스트의 터널 패킷은 VPN 서버의 공인 주소로 향하고 암호화된 UDP 또는 TCP로 호스트 어댑터를 통해 나갑니다. 호스트는 하나의 흐름과 그 바이트 수만 보고, 내부 목적지에 대해서는 아무것도 모릅니다. 브리지 어댑터 아래에서 게스트는 물리 LAN에서 자체 2계층 신원을 가지며, 자체 DHCP 임대를 받고, MAC 기반 정책에는 두 번째 장치로 보입니다. 어느 모드도 호스트가 터널 페이로드를 읽게 하지 않습니다. 브리지된 게스트는 주변 네트워크에 훨씬 더 잘 보일 뿐입니다.
격리에도 하한이 있습니다. 게스트는 자신의 메모리를 소유한 기계에서 숨을 수 없고, 호스트를 통제하는 사람은 게스트 RAM에서 키를 읽을 수 있습니다. 게스트의 터널이 주는 것은 라우팅 경계와 악성코드 경계이지, 노트북을 들고 있는 사람으로부터의 보호가 아닙니다. 문서화된 어댑터 모드는 고르는 동안 열어 두는 것이 좋습니다. 모드가 호스트가 보는 것과 LAN이 보는 것을 모두 바꾸기 때문입니다.
안내서: 배치하고, 구성하고, 증명하십시오
이 네 가지 점검을 새 게스트 셸에서 순서대로 실행하고, 적어 둔 소유자와 어긋나는 첫 점검에서 멈추십시오.
ip route get 1.1.1.1이tun0또는wg0를 돌려주면 게스트 소유, 사설 다음 홉이 붙은eth0를 돌려주면 호스트 소유입니다.resolvectl query example.com, 또는 게스트가 리졸버 서비스를 돌리지 않는 곳에서는/etc/resolv.conf를 읽으십시오. 트래픽은 나르지만 DNS는 나르지 않는 터널이 가장 흔한 반쯤 구성된 상태입니다.- 출구를 비교하십시오. 게스트에서
curl -4 -s https://ifconfig.me, 호스트에서curl.exe -4 -s https://ifconfig.me입니다. 주소가 다르면 게스트가 터널을 소유한 것이고, VPN에 있는 호스트와 집 ISP를 보여 주는 게스트라면 아무것도 물려받지 않은 사례입니다. - 둘 다
-6으로 반복하십시오. v4 전용 터널은 클라이언트가 막거나 라우팅하지 않으면 v6를 새게 하고, 많은 클라이언트가 기본적으로 v6를 물리 인터페이스에 남겨 둡니다.
여러 게스트가 하나의 터널을 공유하는 호스트 게이트웨이 설계에서는 호스트가 전달하고 변환해야 합니다. Linux 호스트에서는 세 조각이며, 하나라도 빠지면 게스트는 조용히 평범한 경로로 돌아갑니다:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPTWireGuard 쪽에서는 호스트 피어의 AllowedIPs에 게스트 서브넷이 들어 있어야 합니다. 예를 들어 192.168.122.0/24입니다. 그렇지 않으면 돌아오는 패킷이 도착하지 않고 설정이 방화벽 문제처럼 보입니다. Windows 호스트는 인터넷 연결 공유나 Hyper-V 스위치의 NAT 규칙으로 같은 결과를 얻지만, 같은 반환 경로 점검이 필요합니다.
배치가 아직 열려 있다면 이 표가 가장 흔한 구성을 다룹니다:
| Situation | Owner | Check first |
|---|---|---|
| One VM, host also on a corporate VPN | Guest | Does the host client block local networks? |
| Six lab VMs, one exit address | Host plus forwarding | ip_forward, NAT rule, server AllowedIPs |
| Malware or research VM | Guest, NAT | Snapshot age and resolver state |
| Bridged VM on an office LAN | Guest | DHCP lease and port security |
터널 둘, 게스트 둘, 그리고 그 사이의 충돌
동시에 출구 둘이 필요할 때 버티는 패턴은 게스트마다 터널 하나입니다. 각 VM은 자기 기본 경로와 리졸버를 유지하고, 호스트는 평범한 네트워크에 머물며, 두 터널은 같은 라우팅 테이블을 두고 다투지 않습니다. 게스트 둘을 브리지로 묶어도 경로가 합쳐지지 않습니다. 가상 네트워크는 길을 제공할 뿐이고, 이 로컬 트래픽이 터널을 우회해도 된다고 각 클라이언트에 여전히 알려야 합니다.
호스트 터널과 게스트 터널을 함께 돌리는 것은 정당하고, 의도적인 중첩이 때로는 정확히 원하는 것입니다. 게스트가 자기 터널로 나가고 그 터널이 호스트의 터널로 나가는 형태입니다. 이것을 장애로 바꾸는 것은 어느 끝점에 어느 계층으로 도달해야 하는지 아무도 적어 두지 않았다는 점입니다. 목적지와 소유자의 두 열 목록을 유지하면 경로 충돌은 반나절의 발견이 아니라 한 번의 조회가 됩니다.
검증하고, 그다음 복구는 소유자에게 두십시오
게스트 안에서 시험하십시오 새 애플리케이션 프로세스로 트래픽, 이름 해석, 두 주소 체계, 그리고 터널이 끊길 때 무슨 일이 일어나는지 확인합니다. 호스트의 VPN 아이콘은 게스트의 적용 범위에 대해 아무 말도 하지 않으며, 이것이 이 분야 전체에서 가장 흔한 거짓 확인입니다.
복구도 소유자의 몫입니다. 게스트가 소유한 터널은 게스트 자신의 클라이언트와 그것이 쓴 경로로 복구됩니다. 호스트가 소유한 설계는 호스트의 부팅 순서로 복구되며, 전달 규칙은 unit이나 시작 작업이 다시 적용하지 않으면 재부팅을 넘기지 못합니다. 복원된 스냅숏은 배포이지 취소가 아닙니다. 디스크와 함께 오래된 자격 증명과 오래된 경로를 되돌려 놓기 때문입니다. 작업을 끝났다고 말하기 전에, 소유자가 적어 둔 줄과 여전히 맞는지, DNS와 두 주소 체계가 게스트 안에서 해석되는지, 죽은 터널이 블랙홀 대신 쓸 만한 네트워크를 남기는지, 재부팅이나 스냅숏 복원이 같은 상태를 재현하는지 확인하십시오.