☰

VPN은 VM 게스트에서는 작동하지만 VM 호스트에서는 작동하지 않습니다.

tag-icon • tag-icon networking vpn
VPN은 VM 게스트에서는 작동하지만 VM 호스트에서는 작동하지 않습니다.

3개의 연결 케이블이 있는 스위치가 있습니다.

NAS PC 인터넷

내 VPN은 SonicWall을 사용하고 저는 NetExtender를 사용합니다. 무엇보다도 동일한 프로그램을 사용하여 동일한 자격 증명으로 연결하고 있습니다. 둘 다 연결되어 있고 IP를 통해 트래픽을 전달한다고 보고합니다.

여기서 중요한 점은 VPN에 연결하면 NAS에 연결할 수 없다는 것입니다. 이미 연결되어 있으면 연결이 차단되어 더 이상 작동하지 않습니다. "LinkOnly" 연결을 통해 NAS에 연결합니다. 다른 어떤 것도 작동하지 않을 것입니다.

그러나 게스트에서는 VPN 뒤의 페이지에 액세스할 수 있습니다. 하지만 호스트에서는 할 수 없습니다. 게스트에는 VmWare Workstation v16을 사용하는 NAT 연결 네트워크 어댑터가 있습니다.

실패한 요청에 대한 로그를 확인하도록 IT 부서에 요청했는데 다음과 같이 표시되었습니다. some 403s just after I asked you to hit turo-green with an x-forwarded-for header value of 2a01:4b00:86f0:e00:6c71:9e79:XXX:9597, 64.252.XX.126. The 1st IP is hyperoptic (I guess thats the ISP for you apartment or block of apartments), the 2nd is AWS cloudfront

조금 파고들 때는 curl ifconfig.co주어야 2a01:4b00:86f0:e00:6c71:9e79:e8d:9597하지만, 주어야 한다195.114.XXX.217

Before connection 

(base) hutber@hutber:~$ ip route 
default via 192.168.1.1 dev wlo1 proto dhcp metric 600 
169.254.0.0/16 dev enp2s0 proto kernel scope link src 169.254.168.22 metric 100 
169.254.0.0/16 dev enp8s0 proto kernel scope link src 169.254.59.152 metric 101 
169.254.0.0/16 dev wlo1 scope link metric 1000 
172.16.64.0/24 dev vmnet8 proto kernel scope link src 172.16.64.1 
192.168.1.0/24 dev wlo1 proto kernel scope link src 192.168.1.104 metric 600 
192.168.246.0/24 dev vmnet1 proto kernel scope link src 192.168.246.1 
224.0.0.0/4 dev enp2s0 proto static scope link metric 100 
224.0.0.0/4 dev enp8s0 proto static scope link metric 101 

After connecting    

(base) hutber@hutber:~$ ip route
default via 10.xx.57.3 dev ppp0 scope link 
default via 192.168.1.1 dev wlo1 proto dhcp metric 600 
10.0.0.0/8 via 10.xx.57.3 dev ppp0 scope link 
128.0.0.0/1 via 10.xx.57.3 dev ppp0 scope link 
169.254.0.0/16 via 10.x.57.3 dev ppp0 scope link 
169.254.0.0/16 dev enp2s0 proto kernel scope link src 169.254.168.22 metric 100 
169.254.0.0/16 dev enp8s0 proto kernel scope link src 169.254.59.152 metric 101 
169.254.0.0/16 dev wlo1 scope link metric 1000 
172.16.64.0/24 via 10.xx.57.3 dev ppp0 scope link 
172.16.64.0/24 dev vmnet8 proto kernel scope link src 172.16.64.1 
192.0.2.1 via 10.xx.57.3 dev ppp0 scope link 
192.0.2.1 dev ppp0 proto kernel scope link src 10.10.57.3 
192.168.1.0/24 via 10.xx.57.3 dev ppp0 scope link 
192.168.1.0/24 dev wlo1 proto kernel scope link src 192.168.1.104 metric 600 
192.168.1.1 dev wlo1 scope link 
192.168.246.0/24 via 10.10.57.3 dev ppp0 scope link 
192.168.246.0/24 dev vmnet1 proto kernel scope link src 192.168.246.1 
195.114.XX.217 via 192.168.1.1 dev wlo1 
224.0.0.0/4 via 10.xx.57.3 dev ppp0 scope link 
224.0.0.0/4 dev enp2s0 proto static scope link metric 100 
224.0.0.0/4 dev enp8s0 proto static scope link metric 101

왜 그가 IT에게만 묻지 않는지 궁금할 것입니다. 글쎄, IT는 Linux를 지원하지 않고 OSX를 사용하는 것이 너무 답답합니다 (죄송합니다)

hutber@hutber:~$ curl --interface ppp0 ifconfig.co
195.114.103.217

내가 아는 한, 내 호스트에는 방화벽이 없습니다.

[편집하다]

따라서 이 IP를 매핑하려면 IP 경로를 만들어야 한다고 생각하는데 VPN이 연결되지 않습니다. 195.114.XX.217 via 192.168.1.1 dev wlo1VPN 이 모든 트래픽을 터널링하기 때문인 것 같습니다.192.168.1.1169.254.168.22

여기에 이미지 설명을 입력하세요.

여기에 이미지 설명을 입력하세요.

답변1

관련 댓글을 읽은 후 @larsks가 이를 정리한 것 같습니다.

글쎄, 그것을 확장해 보겠습니다.

첫 번째 라우팅 테이블에서:

  1. 하나의 무선(wlo1) 인터페이스와 두 개의 이더넷(enp2s0, enp8s0) 인터페이스가 있습니다.
  2. 제가 모르는 이유로 멀티캐스트 주소가 있는 것 같습니다. 아마도 일부 스트리밍 소프트웨어일 수도 있습니다(순전한 추측).
  3. 알 수 없는 이유로 링크 로컬 IPv4 주소(서브넷 169.254.0.0/16)가 있습니다. 둘 다 일부 장치에 연결하면 인터페이스의 IP 주소는 169.254.168.22(enp2s0) 및 169.254.59.152(enp8s0)입니다. 나는 그것이 avahi mDNS와 같은 소프트웨어라고 가정합니다. Note: 자동 대체 IP 주소로 간주될 수 있는 DHCP 서버를 실행하지 않는 컴퓨터(예: 스위치 또는 직접 링크) 간의 Windows DHCP 구성 연결만 표시됩니다.
  4. Wi-Fi(wlo1)를 통해 라우터(무선 홈 모뎀이라고도 함)에 연결합니다. 귀하의 IP 주소는 192.168.1.104이고 해당 (게이트웨이) IP 주소는 서브넷 192.168.1.0/24 내에서 192.168.1.1입니다. Note: 의심스러운 경우 라우터(게이트웨이 역할)가 CIDR 표기법으로 192.168.0.1/24, 192.168.1.1/24, 192.168.100.1/24 주소 중 하나 이상으로 작동한다고 가정합니다. 두 개의 서브넷을 차지하여 올바른 서브넷으로 리디렉션되는 일부 홈 라우터를 발견했습니다.
  5. 서로 다른 가상 네트워크(192.168.246.0/24, 172.16.64.0/24)를 사용하여 실행 중인 두 개의 가상 머신이 있습니다. 이는 NAT 네트워크이며 귀하의 컴퓨터(하이퍼바이저)는 이러한 네트워크의 게이트웨이입니다. 하이퍼바이저의 IP는 각각 192.168.246.1 및 172.16.64.1입니다.

두 번째 라우팅 테이블에 따르면 이전 관찰을 기반으로 합니다.

  1. 어떤 이유에서인지 이제 Wi-Fi가 NAS(195.114.XX.217)에 대한 인터페이스라는 것을 알게 되었습니다. 이전 출력 이전에 연결되지 않았으며 VPN에 대한 특별한 내용은 없는 것 같습니다.
  2. 소위 mDNS 클라이언트(169.254.0.0/16을 담당)는 이전에 wlo1에서 그랬던 것처럼 ppp0에서 행운을 시험했습니다. 다시는 특별한 것이 없습니다.
  3. VPN(ppp0)에 10.0.0.0/8, 128.0.0.0/1 및 192.0.2.1/24에 대한 경로가 추가되었습니다.192.168.1.0/24(모두 VPN IP 주소 10.XX.57.3을 통해). Note: VPN 서버에 연결할 수 있는 인터넷 연결이 있는 한 VPN 주소는 작동합니다. 따라서 이러한 모든 네트워크는 홈 네트워크가 제대로 작동하는지에 달려 있습니다. 굵은 서브넷은 문제가 많습니다. 자세한 내용은 나중에 설명하겠습니다.
  4. NAT 작동 방식으로 인해 가상 네트워크가 VPN IP 주소(10.XX.57.3)를 통해 광고되고 있습니다. 패킷은 다음에서 제공됩니다.다른 쪽위의 서브넷 중 하나를 이러한 방식으로 다시 적절한 VM으로 라우팅하는 것이 가능합니까? 우선 VM에 의해 연결이 시작될 것이 거의 확실합니다.

이 모든 것을 분석한 결과 문제는 다음과 같습니다.

default via 10.xx.57.3 dev ppp0 scope link 
default via 192.168.1.1 dev wlo1 proto dhcp metric 600

192.168.1.0/24 via 10.xx.57.3 dev ppp0 scope link 
192.168.1.0/24 dev wlo1 proto kernel scope link src 192.168.1.104 metric 600

귀하의 컴퓨터는 적어도 컴퓨터의 관점에서 보면 라우터에 액세스할 수 없는 ppp0 인터페이스를 통해 연결을 시도하고 있기 때문에 홈 라우터(192.168.1.1)에 연결할 수 없습니다.

나는 ppp0 인터페이스가 패킷을 영원히 루프하지 않고 첫 번째 루프 이후에 패킷을 삭제하고 대신 성능상의 이유로 다음 인터페이스(wlo1)를 시도한다고 의심합니다. 다시 순수한 추측.

그러나 wlo1 우선 순위가 ppp0(더 작은 정수)보다 높으면 홈 LAN 연결과 NAS 및 VPN 연결이 유지됩니다. 그러나 VPN의 192.168.1.0/24는 홈 LAN에 의해 ​​차단되므로 작동하지 않습니다.

라우터 장치의 Wi-Fi 구성에서 홈 LAN 서브넷을 위에 기록되지 않은 일부 서브넷으로 변경하는 것이 좋습니다. 192.168.XXX.1/24 형식을 사용하는 것이 좋습니다.

PS 다시 추측하고 있지만 이미 다음 줄이 있었기 때문에 VPN 연결 후 라우팅 테이블을 편집한 후 NAS에 연결할 수 있었던 것 같습니다.

195.114.XX.217 via 192.168.1.1 dev wlo1

따라서 195.114.XX.217을 찾으면 테이블 항목은 192.168.1.1을 거쳐야 함을 의미합니다. wlo1의 IP 주소는 192.168.1.104/24이고 192.168.1.1에 대한 LAN 연결이며 게이트웨이 없이 패킷을 보낼 수 있습니다. 다른 주소를 시도하면 192.168.1.1(게이트웨이)을 통해 전송하고 실패한다는 것을 알 수 없으므로 인터넷은 없지만 NAS 연결은 있습니다. 그게 내 최선의 추측이야.

답변이 만족스러우면 @larsks의 댓글에도 찬성 투표해 주세요. 그는 신호입니다.

관련 정보