Contamos con conexiones VPN de sitio a sitio mediante Azure VPN Gateway y varios dispositivos de red locales en las respectivas ubicaciones de los clientes. Estamos intentando incorporar una nueva conexión, pero tenemos un conflicto de rango de IP con una red en el otro extremo. El siguiente diagrama, aunque es una interpretación vaga por parte del cliente, ya que no tengo todos los detalles, probablemente lo explica mejor, pero aquí están los hechos:
Conflicto de rango de IP en cualquier extremo del túnel S2S de Azure VPN
- La red A (192.168.1.0/24) se encuentra detrás de nuestra puerta de enlace VPN de Azure y es nuestra responsabilidad.
- La Red B (192.168.2.0/24) es una red de destino para paquetes que se originan en la Red A, es responsabilidad de nuestro cliente y está alojada en una nube privada.
- La red C (192.168.1.0/24) es otra red dentro de la nube privada que no es relevante para nuestro tráfico excepto que representa un conflicto de rango de IP dentro de la nube privada del cliente.
El soporte de Azure ha indicado que la única solución es volver a IP una de las redes en conflicto, ya que los rangos en conflicto no son compatibles en este momento. Según ellos, NAT no es una solución viable en ninguno de los extremos del túnel. Tampoco se admite agregar una nueva subred detrás de Azure VPN Gateway y reenviar/NAT el tráfico a la red A.
Debido a las consecuencias de volver a IP la Red A, no queremos volver a IP. Como era de esperar, el cliente tampoco quiere volver a IP su red, la Red C. Tal vez solo lo niego, pero ¿alguien más se ha encontrado con este escenario y lo ha solucionado o solucionado con éxito?sin¿Re-IP'ing? Si es así, se agradecería cualquier documentación o configuración que respalde la solución a la que se pueda hacer referencia.
Gracias de antemano por cualquier ayuda.
Respuesta1
- ruta específica
Usted ha escrito que está interesado en el enrutamiento entre las redes A y B, lo cual no está en conflicto... En caso de que SonicWall esté enrutando entre estas "redes de clientes internas" y es posible no usar IP específicas en la red C, puede realizar el enrutamiento a través de la red no para 192.168.1.0/24 completo sino para IP específicas como /32. En la decisión de enrutamiento "gana el mejor partido". En ese caso, el tráfico específico se enrutaría correctamente de B a A, mientras que el resto pasaría a la red C...
Depende del tipo de VPN, podría ser más fácil o más difícil (si es posible) configurar en SonicWall, pero técnicamente esa podría ser la forma sin NAT. En el peor de los casos, puede hacer que un dispositivo adicional termine la VPN en Azure y en SonicWall tenga una regla de ruta estática para dirigir estas IP a este nodo adicional.
De esta manera, nunca será posible acceder al lado de Azure desde C, pero no sería el problema según lo que haya escrito.
- NAT
Como escribió, Azure VPN GW no ofrece esta función, la única opción podría ser hacerlo en el otro lado del túnel: SonicWall Appliance. Desde el lado B, C puede dirigirse a un sitio "remoto" como cualquier rango de IP no utilizado (por ejemplo, 172.16.0.0/24) y una vez que llegue a SonicWall, podría enrutarse a VPN, mientras que antes de abandonar el nodo se le asignaría/mapearía. a 192.168.1.0/24 mientras, por ejemplo, se mantiene el valor del último octeto o se hace un mapa 1:1 que enumera todas las IP necesarias). De esta manera, para el tráfico VPN, la IP remota en el lado de Azure sería 192.168.0.0/24 "adecuada" y el lado de Azure no tendría idea sobre la NAT.
En caso de que no pueda hacer esto en SonicWall por algún motivo, la forma podría ser colocar otro dispositivo capaz de hacerlo/bajo su propia administración que terminaría el túnel VPN y desde la red local sería el destino del tráfico 172.16.0.0/24 (ruta en el enrutador local).
Las únicas cosas problemáticas serían los casos en los que utiliza DNS respondiendo con direcciones 192.168.1.0/24 y certificados que utilizan IP para identificación. En el caso de DNS, necesita una zona DNS local con valores "actualizados" para que los clientes se comuniquen con los puntos finales "correctos".