멀티 : 클라이언트의 잘못된 소스 주소-일회성 솔루션?

설정 : openvpn 클라이언트 / 서버 설정 (아래에 구성 파일)이 MULTI: bad source address from client [192.168.x.x], packet dropped있으며 서버에 악명 높은 메시지가 나타납니다. 서버는 공개 IP 주소를 가지고 있으며 클라이언트는 NAT 뒤에 있습니다.

이전에 제안 된 솔루션의 단점은 :client-config-dir 현재 비어 서버 설정에 정의. 이전 게시물 (여기 및 openvpn 지원 포럼) DEFAULT에서는에 적절한 규칙으로 이름이 지정된 파일을 추가하거나 client-config-dir문제를 해결하기 위해 해당 규칙으로 사용자 별 파일을 추가 할 것을 제안합니다.

그러나 이러한 규칙은 클라이언트 위치에 따라 다르므로 장기적인 해결책은 아닙니다. 따라서 클라이언트 192.168.x.0연결 을 허용하는 규칙을 추가 할 수 있습니다 . 그러나 192.168.y.0NAT 대신 사용하는 다른 네트워크에서 연결 하는 경우 새로운 규칙이 필요합니다.

질문 :

• 필수 규칙을 일반 / 일회성 방식으로 작성할 수 있습니까?
• 누군가 왜이 문제가 처음에 발생하는지 설명 할 수 있습니까?

서버 설정 :

port 1234
proto tcp
dev tun

ca ca.crt
cert openvpn.crt
key openvpn.key
dh dh2048.pem

server 10.78.96.0 255.255.255.0
keepalive 10 120
comp-lzo
cipher CAMELLIA-128-CBC

user nobody
group nogroup  
persist-key
persist-tun
client-cert-not-required
plugin /usr/lib/openvpn/openvpn-auth-pam.so login

status openvpn-status.log

push "redirect-gateway def1"
push "remote-gateway 1.2.3.4"
push "dhcp-option DNS 8.8.8.8"

client-config-dir ccd
verb 4

클라이언트 구성 :

ca ca.crt
client
dev tun
proto tcp
remote 1.2.3.4 1234

auth-user-pass
script-security 2
keepalive 5 60
topology subnet
resolv-retry infinite
nobind
persist-key
persist-tun
ns-cert-type server
cipher CAMELLIA-128-CBC
comp-lzo
verb 4

" 처음에이 문제가 발생하는 이유를 누군가가 설명 할 수 있습니까? "

공식 OpenVPN FAQ 에보고 된 내용에 따르면 OpenVPN 엔진 내의 라우팅 문제로 인한 것입니다.

시나리오를보다 명확하게 설명하려면 다음 다이어그램을 참조하십시오.

여기에서 볼 수 있습니다 :

• HEADQUARTER 내부 네트워크에 연결된 OpenVPN "서버"(10.0.1.0/24)
• 원격 사이트에서 실행되고 원격 192.168.1.0/24 네트워크에 연결된 OpenVPN "클라이언트"

또한

• OpenVPN 터널이 설정되었다고 가정합니다.
  • OpenVPN "서버"는 주소 10.10.0.1 의 자체 tun 인터페이스 를 통해 연결할 수 있습니다. 또한 tun 인터페이스에서 사용되는 P2P 주소는 10.10.0.2입니다 ( 이는 나중에 논의하는 데 중요하므로 강조하겠습니다 )
  • OpenVPN "클라이언트"는 IP 10.10.0.2 의 tun 인터페이스를 가지고 있습니다.

이제 다음과 같이 가정하십시오.

• OpenVPN "클라이언트"는 기본 게이트웨이로 재정의 했으므로 터널 내에서 모든 나가는 IP 트래픽을 리디렉션합니다.
• OpenVPN "클라이언트"는 IP_FORWARDING을 활성화했으며, 따라서 내부 LAN (192.168.1.0/24)에서 오는 패킷을 라우팅 할 수 있습니다 ( 이 시점에서는이 점을 강조합니다 ).

이러한 시나리오가 적용되면 R_PC1 (192.168.1.2)이 에코 요청과 같은 패킷을 L_PC1 (10.0.1.2)에 보낼 때 어떤 일이 발생하는지 자세히 살펴 보겠습니다.

1. R_PC1 NIC를 떠난 후 패킷은 OpenVPN 클라이언트에 도달합니다.
2. OpenVPN 클라이언트 (공통 라우터로 작동하도록 구성되어 있음)를 라우팅 테이블에 따라 라우팅하십시오. 기본 게이트웨이는 터널이므로 패킷을 터널로 보냅니다.
3. 패킷이 OpenVPN 서버의 tun 인터페이스에 도달합니다. OpenVPN은이를보고 "OpenVPN 서버"는 10.0.1.2가 LAN 서브넷에 속하는 주소임을 알고 있으므로 TUN에서 LAN으로 패킷을 "전달"합니다.
4. 패킷 도달 L_PC1.

그래서 모든 것이 괜찮습니다 ...

이제 L_PC1이 R_PC1에 응답하는 에코 응답으로 어떤 일이 발생하는지 확인하겠습니다.

5. echo-reply는 L_PC1 NIC를 떠나 OpenVPN 서버 LAN 인터페이스 (10.0.1.1)에 도달합니다.

이제 OpenVPN 서버가 원격 사이트에 도달 할 수있게하려면 "정적 경로"를 사용하여 라우팅을 정의해야합니다. 다음과 같은 것 :

route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.10.0.2

게이트웨이로 사용되는 P2P 주소를 참고하십시오 .

이러한 고정 경로는 OS 수준에서 작동합니다. 즉, 운영 체제가 패킷을 올바르게 라우팅해야합니다. "192.168.1.0/24 서브넷으로 주소가 지정된 모든 트래픽은 OS가 P2P 주소를 통해 통신 할 수있는 OpenVPN 엔진으로 전달되어야합니다."와 같은 의미입니다. 정적 경로 덕분에 이제는 ...

6. 패킷은 OS 라우팅 컨텍스트를 떠나 OpenVPN에 도달합니다. OpenVPN 서버에서 실행중인 OpenVPN 인스턴스 따라서이 시점에서 OS는 더 이상 할 일이 없으며 모든 VPN (VPN 내) 라우팅은 OpenVPN 서버 소프트웨어에 맡겨집니다.

이제 문제는 openvpn 서버 소프트웨어가 SRC_IP 10.0.1.2 및 DST_IP 192.168.1.2를 사용하여 패킷 경로를 결정하는 방법입니다 .

OpenVPN 서버의 구성 에 따라 192.168.1.0/24 네트워크 나 192.168.1.2 호스트에 대해서는 아무것도 모릅니다 . 연결된 클라이언트 가 아닙니다 . 로컬 클라이언트 가 아닙니다 . 그래서? OpenVPN을도, 그것이 것을 알고 하지 정말 원하지 않는, 그래서 "OS-라우터"(그리고 .... 수) 로컬 게이트웨이로 패킷 다시 보냅니다. 따라서 여기서 유일한 옵션은 오류를 발생시키는 것입니다. 정확하게 발생하는 오류

FAQ의 언어로 말하면 : " ...이 기계로 패킷을 라우팅하는 방법을 모르므로 패킷을 떨어 뜨립니다 ... ".

문제를 어떻게 해결할 수 있습니까?

공식 문서 에서 볼 수 있듯이 iroute 옵션 은 우리 범위에 정확히 해당합니다.

--iroute network [netmask]
Generate an internal route to a specific client. The netmask 
parameter, if omitted, defaults to 255.255.255.255.
This directive can be used to route a fixed subnet from the server 
to a particular client, regardless of where the client is 
connecting from. Remember that you must also add the route to the 
system routing table as well (such as by using the --route 
directive). The reason why two routes are needed is that the 
--route directive routes the packet from the kernel to OpenVPN. 
Once in OpenVPN, the --iroute directive routes to the specific 
client.

따라서 다음이 필요합니다.

--iroute 192.168.1.0 255.255.255.0

OpenVPN 클라이언트가 연결될 때 (예 : 서버에 정의 된 애드혹 구성 파일 (client-config-dir 등)을 통해) 서버에 적용됩니다.

위의 2) 단계 에서이 문제가 발생하지 않는 이유에 대해 궁금한 점이 있다면 OpenVPN 클라이언트 가 라우팅하는 방법을 알고 있습니다. VPN 터널이 기본 게이트웨이라는 것을 알고 있기 때문입니다.

OpenVPN 서버에서도 동일한 작업을 수행 할 수 없습니다. 기본 게이트웨이가 완전히 재정의 되지 않았기 때문 입니다. 또한 OpenVPN 클라이언트가 많은 단일 OpenVPN 서버를 가질 수 있다고 생각하십시오. 각 클라이언트는 서버에 도달하는 방법을 알고 있지만 서버는 어떻게 클라이언트가 알 수없는 서브넷의 게이트웨이 역할을하는지 결정할 수 있습니까?

첫 번째 질문 ( 필요한 규칙을 일반 / 일회성으로 작성할 수 있습니까? )과 관련하여 미안하지만 문제가 발생하지 않습니다. 자세한 내용을 제공하는 문구를 다시 쓸 수 있습니까?

비슷한 문제가 있었지만 문제와 같은지 확실하지 않습니다. openvpn 클라이언트에서 openvpn 서버의 로컬 네트워크 (서버 구성에 라우팅 됨)의 컴퓨터로 핑을 시도했지만 응답이없고 서버의 openvpn 로그에 "잘못된 소스 주소"메시지가 표시됩니다.

이를 해결하기 위해 두 가지 작업을 수행해야했습니다.

1. 서버에서 IP 전달을 활성화하십시오.
2. 필자의 경우 서버의 로컬 네트워크에 대한 게이트웨이는 서버 자체가 아니라 라우터이므로 서버 게이트웨이에 VPN 서브넷에 대한 경로를 추가하십시오. 핑된 컴퓨터가 게이트웨이를 통해 응답하려고했으나 VPN 서브넷에 대해 어떻게해야할지 몰랐습니다. 그래서 대상의 VPN 서브넷을 사용하여 라우터에 고정 경로를 추가하고 게이트웨이의 게이트웨이로 openvpn 서버의 IP를 추가했습니다.

그것은 나를 위해 그것을 고쳤다.