Enrutar una subred de sucursal por la salida a Internet del SonicWall de la sede central

Los teléfonos de la sucursal deberían salir por la sede central mientras los portátiles de la sucursal siguen usando el WAN local, y la política de enrutamiento por sí sola no lo logrará. Una ruta de sucursal puede seleccionar el túnel, pero la política del túnel tiene que aceptar el tráfico, la sede central tiene que reenviarlo y traducirlo, y la respuesta tiene que volver por el mismo camino. Falle cualquiera de esos tres y el síntoma será un subconjunto de clientes que pierden Internet justo mientras el túnel está activo.

Empiece por el selector, no por la ruta

La política de enrutamiento coincide por origen, así que el origen tiene que ser estable antes que nada. Coloque los dispositivos elegidos en un grupo de direcciones que mantenga un administrador o, mejor, en un segmento dedicado cuya pertenencia siga el rol del dispositivo. Cuando la rotación normal de DHCP puede mover una dirección coincidente a otra máquina, la política selecciona en silencio al cliente equivocado, y el primer informe suele tratar de navegación lenta que en realidad es un desvío.

Nombre el grupo por la política a la que sirve, no por una planta o un departamento, porque la regla de enrutamiento sobrevivirá a ambos. Anote qué dispositivos están en él y quién puede añadir uno.

Añada la política de la sucursal y luego defienda su orden

En el SonicWall de la sucursal, una política de ruta selecciona el grupo de origen, nombra los destinos previstos y establece la interfaz del túnel como puerta de enlace, que es para lo que existe el diseño de interfaz de túnel compatible. Mantenga las reglas de destinos locales y privados por encima de la regla amplia de Internet, porque la primera coincidencia gana y un prefijo privado empujado al túnel llega a la sede central solo para ser descartado. Conserve también la ruta propia del cortafuegos hacia su par VPN, o el transporte del túnel seguirá la política de la que depende. Nada de esto le obliga a convertir cada túnel existente basado en políticas; una interfaz de túnel es una opción compatible entre varias.

El orden es la parte que cambia por accidente. Quien añade una excepción tiene que insertarla por encima de la regla amplia, y quien edita la regla amplia puede invertir todo el diseño con un solo guardado. Escriba el orden previsto junto a la política y vuelva a comprobarlo tras las actualizaciones de firmware, porque el nombre de las interfaces y la representación de las políticas sí cambian entre versiones.

Termine el camino en la sede central

La política del túnel en la sede central debe aceptar el tráfico que ahora selecciona la ruta de la sucursal. Un selector interoficinas limitado a la LAN privada de la sede central no es permiso para transportar destinos públicos arbitrarios, así que la política necesita el origen de la sucursal y el rango de destinos que realmente pretende. La sede central reenvía después ese tráfico entrante a su enlace de Internet según sus propias reglas de acceso, y el ejemplo de salida central de SonicWall incluye la traducción de origen para la red remota en el WAN central. Sin esa traducción, el lado remoto ve una dirección privada de sucursal y no tiene ruta de vuelta hacia ella.

Las respuestas son la otra mitad del contrato. Deben volver por el túnel o por la traducción con estado creada para ellas, y el tráfico de sitios privados puede necesitar un tratamiento NAT distinto del de la salida pública. Mantenga esas reglas distinguibles, porque una regla de traducción amplia que oculte cada origen interno hace que el registro y la resolución de problemas posteriores sean mucho más difíciles de leer.

Decida qué hace el grupo cuando cae el túnel

Si la salida central es un requisito y no una preferencia, volver al WAN local es un fallo de cumplimiento aunque los usuarios sigan en línea. SonicOS documenta una ruta de descarte de la interfaz del túnel como la forma compatible de impedir que el tráfico seleccionado tome una ruta alternativa no deseada.

Ajuste el alcance y la prioridad de esa ruta a la versión instalada, y pruébela bajando el túnel en lugar de confiar en la etiqueta. Un grupo que nunca debe salir localmente debería fallar cerrado, mientras que un grupo donde la disponibilidad importa más puede retroceder legítimamente; ambas son decisiones, y ninguna debería ocurrir por defecto.

Verifique desde tres clientes y luego revierta limpiamente

Un ping a la puerta de enlace central prueba lo incorrecto, porque se origina en el cortafuegos y no en un cliente seleccionado. Pruebe desde dispositivos en su lugar, y pruebe tres de ellos: un dispositivo seleccionado, un dispositivo ordinario que debería quedarse local y uno que depende de servicios locales.

ip -4 route get 203.0.113.10
curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com
traceroute -n -m 6 203.0.113.10

Compare dónde surgió realmente la solicitud pública. Un cliente seleccionado debería llegar a Internet por la salida de la sede central, y un cliente ordinario debería seguir presentando la dirección propia de la sucursal en el lado remoto; 203.0.113.10 es una dirección de documentación usada como sustituto del destino que le importa. Incluya DNS en la misma pasada, porque un cliente que consulta al resolutor de la sucursal puede producir una consulta originada en el router con un origen distinto y, por tanto, una ruta distinta.

La reversión es el orden de políticas guardado más el grupo de direcciones. Restaure el orden anterior, quite el grupo de la política y vuelva a probar ambas clases de dispositivos. Conserve la configuración exportada con el registro del cambio, porque el siguiente ingeniero necesita saber qué regla era la amplia antes de que alguien la editara.