Ich habe ein Multicast-Routing-Setup mit Weiterleitung auf der Empfangsseite wie folgt (alles 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
In dieser Konfiguration openvpn-serversendet die Seite UDP-Pakete an die Multicast-Gruppe 239.1.2.3 auf Port 53. Genauer gesagt handelt es sich bei den Paketen um DNS-NOTIFY-Nachrichten, aber ich glaube nicht, dass dies hier von Bedeutung ist. (Es gibt mehrere Fälle, in openvpn-clientdenen Multicast verwendet wird.)
openvpn-clientleitet den Datenverkehr dann an weiter application. Dieser Host bestätigt den Empfang des Pakets, indem er mit einem weiteren UDP-Paket antwortet.
Das Antwortpaket wird dorthin zurückgesendet, openvpn-clientwoLinux übersetzt die Quell-IP zurück in die Ziel-IP-Adresse des ursprünglichen Pakets, wie es eingegangen ist.vom OpenVPN-Server (unter der Annahme, dass das ursprüngliche Ziel nun der Absender der Antwort ist), also 239.1.2.3.Das ist das Problem:Aufgrund dieser Quell-IP wird das Paket nicht an den ursprünglichen Absender des ersten Pakets übermittelt und der Absender denkt, das Paket sei nicht übermittelt worden. Dies führt zu mehreren unnötigen Wiederholungsversuchen und einem hohen Protokollierungsaufwand.
DerFrageist, wenn es möglich ist, zu befehlen openvpn-client,Schreiben Sie die Quelladresse der Antwort um in 10.8.0.2stattdessen. Genauer gesagt hätte ich gerne, dass es die Adresse ist, die mit der Schnittstelle verknüpft ist tun0, sodass die Ordnung erhalten bleibt, falls eine erneute VPN-Verbindung zu einer Änderung der IP-Adresse führt.
Ich vermute, dass dies möglich ist, da iptables MASQUERADE etwas Ähnliches tut (aber für Verbindungen, die von ausgehen application). Außerdem glaube ich, dass das Antwortpaket zugestellt wird, wenn ich dies konfiguriere. Ist das möglich?
Ich habe beobachtet, dass beim Pingen von 10.8.0.1 an 239.1.2.3 das Echopaket von 10.8.0.2 stammt (und nicht von 239.1.2.3). (Beachten Sie, dass es sich beim Pingen nicht um eine Portweiterleitung handelt.) Wie kann ich dasselbe Verhalten für meinen UDP-Fall erreichen?