다음과 같이 수신 측에서 전달이 가능한 멀티캐스트 라우팅 설정이 있습니다(모두 Linux).
+----------------+ +----------------+ +-------------+
| openvpn-server |tun0 tun0| openvpn-client | forward port 53 | application |
| 10.8.0.1 |============| 10.8.0.2 |-------------------| 172.16.3.3 |
+----------------+ +----------------+ +-------------+
joined 239.1.2.3
multicast group
이 설정에서 측면에서는 openvpn-server포트 53의 멀티캐스트 그룹 239.1.2.3으로 UDP 패킷을 보냅니다. 특히 패킷은 DNS NOTIFY 메시지이지만 여기서는 관련성이 없다고 생각합니다. ( openvpn-client멀티캐스트가 사용되는 이유는 여러 가지가 있습니다 .)
openvpn-client그런 다음 트래픽을 로 전달합니다 application. 이 호스트는 다른 UDP 패킷으로 응답하여 패킷 수신을 승인합니다.
응답 패킷은 다음 openvpn-client위치 로 다시 전송됩니다.Linux는 소스 IP를 초기 패킷이 들어올 때의 대상 IP 주소로 다시 변환합니다.openvpn-server에서(원래 대상이 이제 응답의 발신자라고 가정), 즉 239.1.2.3.이게 문제 야:이 소스 IP로 인해 첫 번째 패킷의 원래 보낸 사람에게 패킷이 전송되지 않으며, 보낸 사람은 패킷이 전송되지 않은 것으로 생각합니다. 이로 인해 불필요한 재시도가 여러 번 발생하고 로깅이 많이 발생합니다.
그만큼질문openvpn-client지시 할 수 있는 경우입니다.10.8.0.2대신 응답의 소스 주소를 다시 작성하십시오.. 더 구체적으로 말하자면, tun0VPN 재연결로 인해 IP 주소가 변경되는 경우에도 모든 것이 순서대로 유지되도록 인터페이스와 연결된 주소가 되기를 바랍니다 .
iptables MASQUERADE가 비슷한 작업을 수행하기 때문에 이것이 가능하다고 생각합니다(그러나 에서 시작된 연결의 경우 application). 또한, 이렇게 구성하면 응답 패킷이 전달될 것이라고 믿습니다. 이것이 가능한가?
10.8.0.1에서 239.1.2.3으로 ping을 실행하면 에코 패킷이 239.1.2.3이 아닌 10.8.0.2에서 발생하는 것으로 나타났습니다. (ping 사례에는 포트 전달이 포함되지 않습니다.) UDP 사례에 대해 동일한 동작을 달성하려면 어떻게 해야 합니까?