로컬 네트워크 서브넷 주소가 원격 네트워크와 충돌 할 때 VPN을 통해 원격 서버에 연결

이것은 VPN 클라이언트의 로컬 네트워크와 VPN 링크를 통한 하나의 IPv4 서브넷 충돌을 해결 하는 것에 관한 정식 질문 입니다.

OpenVPN을 통해 원격 위치에 연결 한 후 클라이언트는 192.0.2.0/24와 같은 서브넷에있는 네트워크의 서버에 액세스하려고합니다. 그러나 때때로 클라이언트 LAN의 네트워크는 192.0.2.0/24와 동일한 서브넷 주소를 갖습니다. 이 충돌로 인해 클라이언트가 IP를 입력하여 원격 서버에 연결할 수 없습니다. VPN에 연결되어 있으면 공용 인터넷에 액세스 할 수 없습니다.

문제는이 서브넷 192.0.2.0/24를 VPN으로 라우팅해야하지만 클라이언트의 LAN으로 라우팅해야한다는 것입니다.

누구 든지이 문제를 완화시키는 방법을 알고 있습니까? OpenVPN 서버에 액세스 할 수 있습니다.

NAT를 사용하여이 문제를 해결할 수 있습니다. 그다지 우아하지 않습니다.

따라서 실제로 충돌하지 않는 네트워크 번호를 가진 내부 네트를 사용 하여이 문제를 해결할 수 없다는 가정하에 원칙은 다음과 같습니다.

로컬 서브넷과 원격 서브넷이 모두 동일한 네트워크 번호를 가지므로 클라이언트의 트래픽은 대상에 도달하기 위해 터널 게이트웨이를 통과해야한다는 것을 결코 인식하지 못합니다. 그리고 가능하다고 생각하더라도 원격 호스트가 응답을 보내려는 상황과 동일합니다.

따라서 나와 함께 머물면서 아직까지 완전한 연결을 위해서는 호스트 내부를 구별하고 라우팅을 허용하기 위해 터널 내부의 양쪽 끝을 NAT로 연결 해야하는 부수적 인 문제가 없다고 가정하십시오.

여기에 그물을 만들기 :

• 사무실 네트워크는 192.0.2.0/24를 사용합니다
• 원격 사무실은 192.0.2.0/24를 사용합니다
• 사무실 네트워크 VPN 게이트웨이는 NAT 네트워크 번호 198.51.100.0/24 뒤에 192.0.2.0/24 호스트를 숨 깁니다.
• 원격 사무실 네트워크 VPN 게이트웨이는 NAT 네트워크 번호 203.0.113.0/24 뒤에 192.0.2.0/24 호스트를 숨 깁니다.

따라서 VPN 터널 내에서 사무실 호스트는 이제 198.51.100.x이고 원격 사무실 호스트는 203.0.113.x입니다. 또한 모든 호스트가 해당 VPN 게이트웨이의 NAT에 1 : 1로 매핑되어 있다고 가정합시다. 예를 들면 :

• 사무실 네트워크 호스트 192.0.2.5/24는 사무실 VPN 게이트웨이 NAT에서 198.51.100.5/24로 정적으로 매핑됩니다.
• 원격 사무실 네트워크 호스트 192.0.2.5/24는 원격 사무실 VPN 게이트웨이 NAT에서 203.0.113.5/24로 정적으로 매핑됩니다.

따라서 원격 사무실의 호스트 192.0.2.5/24가 사무실 네트워크에서 동일한 IP로 호스트에 연결하려면 주소 198.51.100.5/24를 대상으로 사용해야합니다. 다음과 같은 일이 발생합니다.

• 원격 사무실에서 호스트 198.51.100.5는 VPN을 통해 도달하여 라우팅 된 원격 대상입니다.
• 원격 사무실에서 호스트 192.0.2.5는 패킷이 NAT 기능을 통과함에 따라 203.0.113.5로 가장합니다.
• 사무실에서 호스트 198.51.100.5는 패킷이 NAT 기능을 통과함에 따라 192.0.2.5로 변환됩니다.
• 사무실에서 호스트 203.0.113.5 로의 리턴 트래픽은 반대 방향으로 동일한 프로세스를 거칩니다.

따라서 해결책이 있지만 실제로 적용하려면 해결해야 할 여러 가지 문제가 있습니다.

• 가장 된 IP는 원격 연결에 사용해야합니다. DNS가 복잡해집니다. 이는 연결 호스트에서 볼 때 엔드 포인트에 고유 한 IP 주소가 있어야하기 때문입니다.
• NAT 기능은 VPN 솔루션의 일부로 양쪽 끝을 구현해야합니다.
• 호스트를 정적으로 매핑하는 것은 다른 쪽 끝에서 접근 할 수 있어야합니다.
• 트래픽이 단방향 인 경우 수신 측에만 관련된 모든 호스트의 정적 매핑이 필요합니다. 클라이언트는 원할 경우 동적으로 NAT되는 것을 피할 수 있습니다.
• 트래픽이 양방향 인 경우 양쪽 끝에 모든 관련 호스트의 정적 매핑이 필요합니다.
• 분할 또는 비분 할 VPN에 관계없이 인터넷 연결이 손상되지 않아야합니다.
• 일대일로 매핑 할 수 없으면 지저분합니다. 신중한 부기는 필수입니다.
• 당연히 NAT 주소를 사용할 위험이 있습니다. NAT 주소도 중복됩니다 :-)

따라서이를 해결하려면 신중한 디자인이 필요합니다. 만약 당신의 원격 사무실이 실제로로드 워리어로 구성되어 있다면 다음과 같은 문제를 추가 할 수 있습니다 :

• 그들은 겹치는 넷 ID로 끝나는 것을 미리 알지 못합니다.
• 원격 사무실 게이트웨이 NAT는 랩톱에서 구현해야합니다.
• 사무실 게이트웨이는 두 시나리오를 모두 다루기 위해 NAT가없는 VPN과 NAT가없는 VPN이 필요합니다. 그렇지 않으면 누군가 누군가 NAT 방법으로 선택한 서브넷 중 하나를 선택하는 경우 작동하지 않습니다 .

VPN 클라이언트에 따라 로컬 세그먼트의 네트워크 주소에 따라 하나의 VPN을 자동으로 선택할 수 있습니다.

이와 관련하여 NAT에 대한 언급은 모두 터널 관점에서 발생하는 NAT 기능을 나타냅니다. 프로세스 적으로, 정적 NAT 매핑은 패킷이 터널에 "들어가기"전에, 즉, 인터넷을 통해 다른 VPN 게이트웨이로 가져가는 전송 패킷에 캡슐화되기 전에 수행되어야한다.

즉, VPN 게이트웨이의 공용 IP 주소 (실제로 NAT : ed 일 수도 있지만 VPN을 통해 원격 사이트로 전송되는 관점에서 완전히 벗어남)와 가장 무도회로 사용되는 고유 한 개인 주소를 혼동해서는 안됩니다. 중복 개인 주소 이 추상화가 이해하기 어려운 경우, NAT가 VPN 게이트웨이와 물리적으로 어떻게 분리 될 수 있는지에 대한 그림이 여기에 있습니다 :
겹치는 네트워크에서 NAT 사용 .

NAT와 VPN 게이트웨이 기능을 모두 수행 할 수있는 동일한 그림을 한 시스템 내부의 논리적 분리에 집약하는 것은 동일한 예를 한 단계 더 나아가고 있지만 현재 소프트웨어의 기능에 더 중점을 둡니다. 예를 들어 OpenVPN 및 iptables와 함께 해킹하고 여기에 솔루션을 게시하는 것은 가치가 있습니다.

Softwarewise 확실히 가능하다 :
PIX / ASA 7.x 및 이후 버전 : 고성능 LAN-to-LAN의 IPsec 중복 네트워크 구성 예와 VPN
과 :
중복 LAN 서브넷과 라우터 사이의 IPSec 터널을 구성

따라서 실제 구현은 많은 요소, 관련 운영 체제, 관련 소프트웨어 및 그 가능성에 달려 있습니다. 그러나 확실히 가능합니다. 조금 생각하고 실험해야합니다.

링크에서 볼 수 있듯이 Cisco에서 이것을 배웠습니다.

하나 또는 소수의 알려진 서버 IP에 대한 일시적인 더티 해결 방법이 필요한 경우 가장 간단한 해결 방법은 정적 클라이언트 측 라우팅 옵션입니다.

필자의 경우 원하는 대상 서버 (192.168.1.100)를 다음을 통해 Linux 클라이언트의 라우팅 테이블에 추가했습니다.

route add 192.168.1.100 dev tun0

그런 다음 route delete 명령으로이 고정 경로를 제거하십시오.

this 이것은 최악이다. 나를 위해 그것은 호텔 방에서 항상 일어났습니다. VPN 관리자가 더 모호한 IP 범위를 사용해야한다는 것을 깨달았습니다. 10.0.0.0/24 및 10.1.1.1/24가 최악입니다. 당신이 그렇게 무선 네트워크를 ip하지 않도록 도울 수 있다면.

따라서 대답은 다른 내부 네트워크 (예 : 10.255.255.0/24)를 사용하도록 wap을 "수정"한 다음 diff 임대 (예 : corp vpn으로 다시 라우팅 할 수있는 범위의 ip)를 제공하거나 그렇지 않은 경우 / wap에서 관리자를 사용할 수 없으며 스타 벅스로 이동하십시오. 또는 20 분의 워드 리빙 :)

실험실 환경에있는 경우 다른 범위를 사용하십시오.

엘 캐피 탄을 운영하는 맥을 사용하고 있습니다. 위의 제안이 저에게 효과가 없었지만 그들은 나를 해결책으로 이끌었습니다.

1. VPN을 시작하기 전에 실행 ifconfig

2. VPN을 시작하고 ifconfig새로운 인터페이스를 확인하십시오. 내 경우에는 IP 주소가 192.168.42.74 인 ppp0 이었습니다.

   ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
       inet 192.168.42.74 --> 192.0.2.1 netmask 0xffffff00
   

3. 입력 :

   sudo route add 192.168.1.79  192.168.42.74
   

먼저 a로 테스트 ping한 다음 git 서버에 액세스하여 작동한다는 것을 증명했습니다.

위에서 언급 한 것처럼 라우트 명령의 끝에 dev ppp0 을 사용해 보았을 때 불평했습니다.

IP 범위 (10.x)가 충돌하는 공동 작업 공간에서 사용하는 간단한 솔루션이 있습니다.

휴대폰으로 네트워크에 연결 한 다음 블루투스를 통해 네트워크 연결을 랩톱과 공유했습니다. 이제 원격 고용주에 VPN을 사용할 수 있습니다.

더 빠른 연결이 필요한 경우 USB를 통해 동일한 방식으로 작동한다고 확신합니다.

하나 또는 두 개의 IP 주소를 사용해야하는 경우 다음과 같이 ovpn 구성 파일에 경로 명령문을 추가하십시오.

노선 192.168.1.10 255.255.255.255

노선 192.168.1.11 255.255.255.255

VPN을 연결할 때 IP의 경로를 추가하고 연결이 끊어진 VPN을 제거합니다.

어쨌든 Windows에서 나를 위해 일했습니다.

Aydin K.의 답변은 Linux 용입니다. 당신이 창문에 대해 동일한 funtionality를 원한다면, 당신은 입력 할 수 있습니다

route ADD 192.168.1.10 <IP of tunnel adapter>

또는

route ADD 192.168.1.10 IF <interface id>

다음 명령으로 인터페이스 ID를 얻을 수 있습니다.

route print

이 문제는 다년간의 IPv4 주소 부족과 NAT 뒤에서 개인 IP 범위를 광범위하게 사용 하여이 문제를 해결했습니다.

이 문제에 대한 이상적이고 결정적인 해결책은 매우 간단합니다 (전 세계적으로 출시되기까지는 시간이 걸리더라도 시간이 걸리지 만) : IPv6 ...

IPv6 세계에서는 퍼블릭 IP 부족이 없습니다 (몇 십년 안에는 이벤트가 없을 것입니다). 따라서 모든 네트워크의 모든 장치에 퍼블릭 IP가없는 이유는 없습니다. 네트워크 격리가 필요한 경우 방화벽을 사용하여 필터링을 수행하지만 추악한 NAT는 사용하지 마십시오.