Encamiñar unha subrede de sucursal pola saída a Internet do SonicWall da sede central

Os teléfonos da sucursal deberían saír pola sede central mentres os portátiles da sucursal seguen usando o WAN local, e a política de encamiñamento por si soa non o logrará. Unha ruta de sucursal pode seleccionar o túnel, pero a política do túnel ten que aceptar o tráfico, a sede central ten que reenvialo e traducilo, e a resposta ten que volver polo mesmo camiño. Falle calquera deses tres e o síntoma será un subconxunto de clientes que perden Internet xusto mentres o túnel está activo.

Comece polo selector, non pola ruta

A política de encamiñamento coincide por orixe, así que a orixe ten que ser estable antes ca nada. Poña os dispositivos escollidos nun grupo de enderezos que manteña un administrador ou, mellor, nun segmento dedicado cuxa pertenza siga o rol do dispositivo. Cando a rotación normal de DHCP pode mover un enderezo coincidente a outra máquina, a política selecciona en silencio o cliente incorrecto, e o primeiro informe adoita tratar de navegación lenta que en realidade é un desvío.

Nomee o grupo pola política á que serve, non por unha planta ou un departamento, porque a regra de encamiñamento sobrevivirá a ambos. Anote que dispositivos están nel e quen pode engadir un.

Engada a política da sucursal e despois defenda a súa orde

No SonicWall da sucursal, unha política de ruta selecciona o grupo de orixe, nomea os destinos previstos e establece a interface do túnel como pasarela, que é para o que existe o deseño de interface de túnel compatible. Manteña as regras de destinos locais e privados por riba da regra ampla de Internet, porque a primeira coincidencia gaña e un prefixo privado empurrado ao túnel chega á sede central só para ser descartado. Conserve tamén a ruta propia da devasa cara ao seu par VPN, ou o transporte do túnel seguirá a política da que depende. Nada disto lle obriga a converter cada túnel existente baseado en políticas; unha interface de túnel é unha opción compatible entre varias.

A orde é a parte que cambia por accidente. Quen engade unha excepción ten que inserila por riba da regra ampla, e quen edita a regra ampla pode inverter todo o deseño cun só gardado. Escriba a orde prevista xunto á política e volva comprobala tras as actualizacións de firmware, porque o nome das interfaces e a representación das políticas si cambian entre versións.

Remate o camiño na sede central

A política do túnel na sede central debe aceptar o tráfico que agora selecciona a ruta da sucursal. Un selector interoficinas limitado á LAN privada da sede central non é permiso para transportar destinos públicos arbitrarios, así que a política necesita a orixe da sucursal e o rango de destinos que realmente pretende. A sede central reenvía despois ese tráfico entrante ao seu enlace de Internet segundo as súas propias regras de acceso, e o exemplo de saída central de SonicWall inclúe a tradución de orixe para a rede remota no WAN central. Sen esa tradución, o lado remoto ve un enderezo privado de sucursal e non ten ruta de volta cara a el.

As respostas son a outra metade do contrato. Deben volver polo túnel ou pola tradución con estado creada para elas, e o tráfico de sitios privados pode necesitar un tratamento NAT distinto do da saída pública. Manteña esas regras distinguibles, porque unha regra de tradución ampla que oculta cada orixe interna fai que o rexistro e a resolución de problemas posteriores sexan moito máis difíciles de ler.

Decida que fai o grupo cando cae o túnel

Se a saída central é un requisito e non unha preferencia, volver ao WAN local é un fallo de cumprimento aínda que os usuarios sigan en liña. SonicOS documenta unha ruta de descarte da interface do túnel como a forma compatible de impedir que o tráfico seleccionado tome unha ruta alternativa non desexada.

Axuste o alcance e a prioridade desa ruta á versión instalada, e probea baixando o túnel en lugar de confiar na etiqueta. Un grupo que nunca debe saír localmente debería fallar pechado, mentres que un grupo onde a dispoñibilidade importa máis pode retroceder lexitimamente; ambas son decisións, e ningunha debería ocorrer por defecto.

Verifique desde tres clientes e despois reverta limpiamente

Un ping á pasarela central proba o incorrecto, porque se orixina na devasa e non nun cliente seleccionado. Probe desde dispositivos no seu lugar, e probe tres deles: un dispositivo seleccionado, un dispositivo ordinario que debería quedar local e un que depende de servizos locais.

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 onde xurdiu realmente a solicitude pública. Un cliente seleccionado debería chegar a Internet pola saída da sede central, e un cliente ordinario debería seguir presentando o enderezo propio da sucursal no lado remoto; 203.0.113.10 é un enderezo de documentación usado como substituto do destino que lle importa. Inclúa DNS na mesma pasada, porque un cliente que consulta o resolutor da sucursal pode producir unha consulta orixinada no router cunha orixe distinta e, polo tanto, unha ruta distinta.

A reversión é a orde de políticas gardada máis o grupo de enderezos. Restaure a orde anterior, retire o grupo da política e volva probar ambas as dúas clases de dispositivos. Conserve a configuración exportada co rexistro do cambio, porque o seguinte enxeñeiro necesita saber cal regra era a ampla antes de que alguén a editase.