Tengo una configuración de enrutamiento de multidifusión con reenvío en el lado receptor, de la siguiente manera (todo 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
En esta configuración, el openvpn-serverlado envía paquetes UDP al grupo de multidifusión 239.1.2.3 en el puerto 53. Específicamente, los paquetes son mensajes de NOTIFICACIÓN DNS, pero no creo que esto sea relevante aquí. (Hay varios casos en openvpn-clientlos que se utiliza la multidifusión).
openvpn-clientluego reenvía el tráfico a application. Este host acusa recibo del paquete respondiendo con otro paquete UDP.
El paquete de respuesta se envía de regreso a openvpn-clientdondeLinux traduce la IP de origen a la dirección IP de destino del paquete inicial tal como estaba llegandodesde openvpn-server (suponiendo que el destino original ahora será el remitente de la respuesta), es decir, 239.1.2.3.Este es el problema:Debido a esta IP de origen, el paquete no se transmite al remitente original del primer paquete y el remitente cree que el paquete no se transmitió. Esto da como resultado varios reintentos innecesarios y una gran cantidad de registros.
Elpreguntaes si es posible instruir openvpn-clientareescribe la dirección de origen de la respuesta en 10.8.0.2su lugar. Más específicamente, me gustaría que fuera la dirección asociada con la interfaz tun0, de modo que todo permanezca en orden en caso de que una reconexión de VPN provoque un cambio de dirección IP.
Sospecho que esto es posible porque iptables MASQUERADE hace algo similar (pero para conexiones que se originan en application). Además, creo que si configuro esto, se entregará el paquete de respuesta. es posible?
Observé que cuando hago ping desde 10.8.0.1 a 239.1.2.3, el paquete de eco se origina en 10.8.0.2 (y no en 239.1.2.3). (Tenga en cuenta que el caso de ping no implica reenvío de puertos). ¿Cómo puedo lograr el mismo comportamiento para mi caso de UDP?