WSL2가 VPN 서브넷에 도달하지 못함: 호스트 경로 읽기

배포판 내부에서 내부 서버로 보낸 ping은 시간 초과되는데 같은 주소는 Windows에서 응답합니다. VPN은 연결되어 있고 Windows 경로도 올바르므로, 빈틈은 WSL 경계입니다. 실패한 명령에서 호스트 인터페이스까지 경로를 따라가 보십시오. 해결책은 설정 파일에 고정 CIDR을 적는 것이 아니라, 현재 주소를 읽어 배포판이 쓸 수 있는 곳에 추가하는 것입니다.

경로가 어디서 멈추는지 확인

양쪽에서 같은 테스트를 실행하십시오. Windows에서 내부 호스트 하나를 확인하고 연결한 뒤 배포판에서 반복합니다. Windows의 성공과 배포판의 시간 초과가 함께 나타나면 장애는 둘 사이에 있으며, VPN 클라이언트나 내부 서버가 아닙니다. 어떤 경로든 바꾸기 전에 이렇게 해서 두 결과가 같은 목적지를 가리키게 하십시오.

배포판 안에서 ip -4 addr는 WSL NAT 대역의 주소를 가진 가상 어댑터를 보여 주고, ip route는 WSL 게이트웨이를 향하는 기본 경로를 보여 줍니다. 회사 프리픽스에 대한 경로는 없습니다. 호스트의 터널 어댑터에 배포판 내부의 대응물이 없기 때문입니다. 기본 게이트웨이는 WSL NAT로 향하며 회사 네트워크로 가지 않습니다.

도달 가능한 링크에 로컬 주소를 먼저 추가하지 않고 회사 경로를 추가하면 시간 초과나 네트워크 도달 불가 오류가 발생합니다. 경로를 쓸 수 있게 만드는 부분은 주소이므로 먼저 주소를 읽고 경로는 두 번째 단계로 다루십시오.

미러 네트워킹 또는 스크립트 경로 선택

미러 네트워킹은 호스트 자체의 인터페이스를 배포판에 넘기므로 터널과 그 경로가 복사 없이 나타납니다. 이 기능은 최신 Windows 빌드와 .wslconfig의 networkingMode=mirrored에 의존하며, 켜면 localhost 전달처럼 무관한 동작도 바뀝니다. 경로 조정이 아니라 플랫폼 변경으로 다루십시오. 빌드가 지원하고 부작용이 허용된다면 가장 짧은 길입니다.

더 좁은 방식은 기본 NAT를 유지하고 터널이 올라올 때마다 터널 주소와 경로를 배포판에 복사합니다. 더 많은 빌드에서 동작하고, localhost 동작을 바꾸지 않으며, VPN이 꺼져 있으면 눈에 띄게 실패합니다. 대가는 연결할 때마다 실행해야 하는 작은 스크립트입니다.

하나를 골라 적어 두십시오. 미러 구성과 수동 경로를 섞으면 같은 프리픽스로 가는 경로가 둘이고 어느 쪽도 소유자가 분명하지 않은 배포판이 됩니다. 문서화된 방법 하나가 반쯤 설정된 방법 둘보다 디버그하기 쉽습니다.

호스트에서 현재 터널 정보 가져오기

어댑터는 이름이 아니라 MAC 주소로 맞추십시오. 이름은 VPN 클라이언트와 연결 순서에 따라 바뀝니다. 어댑터를 한 번 나열하고 터널 어댑터의 MAC을 적은 뒤, 그 주소와 프리픽스를 조회하십시오. MAC은 재연결 사이에도 가상 어댑터에 남지만 이름과 인터페이스 인덱스는 남지 않습니다:

powershell.exe 'Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" } | Get-NetIPAddress -AddressFamily IPv4 | Select-Object IPAddress, PrefixLength'

게이트웨이는 인터페이스 구성에서 나옵니다. 먼저 인터페이스 인덱스를 가져온 뒤 다음 홉을 읽으십시오. 인덱스는 재부팅이나 어댑터 재설정 후에 바뀔 수 있으므로 스크립트는 저장하지 말고 읽어야 합니다:

powershell.exe '(Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" }).InterfaceIndex'
powershell.exe '(Get-NetIPConfiguration -InterfaceIndex 27).IPv4DefaultGateway.NextHop'

출력을 변수에 할당하기 전에 tr -d '\r'를 통과시키십시오. PowerShell은 줄을 캐리지 리턴으로 끝내므로, 제거하지 않으면 마지막 필드에 숨은 문자가 남아 경로 명령이 이해하기 어려운 구문 분석 오류로 실패합니다.

배포판 안에서 주소와 경로 적용

터널 주소를 프리픽스가 붙은 주소로 배포판 인터페이스에 설치한 뒤, 회사 블록을 호스트 게이트웨이로 라우팅하십시오:

sudo ip addr add 172.20.14.37/22 dev vpn
sudo ip route add 172.20.0.0/16 via 172.20.12.1 dev vpn

연결이 순환하면 NetworkManager는 수동으로 설정한 주소를 버리고, 어떤 DHCP 클라이언트도 대체 주소를 요청하지 않습니다. 방식을 자동으로 두어 재연결마다 주소를 갱신하게 한 뒤 연결을 다시 올리십시오. 수동 방식은 첫 재연결까지는 안정해 보입니다:

nmcli con show vpn
sudo nmcli con mod vpn ipv4.method auto
sudo nmcli con up vpn

두 단계 모두 VPN을 시작하는 훅에서 실행하고 대화형 셸에서 실행하지 마십시오. 주소를 읽고, 추가하고, 경로를 추가하고, 값을 기록하는 스크립트는 반복되는 수동 수리를 재현 가능한 절차로 바꿉니다. 프리픽스가 바뀔 때 가장 먼저 읽을 것은 그 로그입니다.

이름을 고정하고 경로를 증명

네트워크 전환 후 커널은 배포판 인터페이스 이름을 eth1과 eth2 사이에서 바꿀 수 있고, 이름을 기준으로 작성된 스크립트는 그때 잘못된 장치를 편집합니다. MAC에 묶인 udev 규칙은 인터페이스에 안정된 레이블을 줍니다:

SUBSYSTEM=="net", ACTION=="add", ATTRS{address}=="3c:52:82:0a:1b:7c", NAME="vpn"

그다음 주소, 경로, 실제 TCP 연결로 확인하십시오. ip -4 addr show dev vpn, ip route get 172.20.4.10, 그리고 알려진 내부 포트로의 연결입니다. 경로 조회는 vpn 장치와 추가한 원본 주소를 보여 주어야 합니다.

세 가지가 모두 배포판 안에서 통과하는데도 연결이 실패하면, 패킷은 WSL을 떠나 Windows 쪽에서 버려지고 있습니다. 스크립트를 바꾸기 전에 호스트 방화벽과 VPN 클라이언트 자체의 필터링을 확인하십시오. 또 다른 경로 편집으로는 이미 호스트에 도달하는 패킷을 고칠 수 없습니다.