Encamineu una subxarxa de sucursal per la sortida a Internet del SonicWall de la seu central

Els telèfons de la sucursal haurien de sortir per la seu central mentre els portàtils de la sucursal continuen utilitzant el WAN local, i la política d’encaminament sola no ho aconseguirà. Una ruta de sucursal pot seleccionar el túnel, però la política del túnel ha d’acceptar el trànsit, la seu central l’ha de reenviar i traduir, i la resposta ha de tornar pel mateix camí. Si falla qualsevol d’aquests tres, el símptoma serà un subconjunt de clients que perden Internet just mentre el túnel està actiu.

Comenceu pel selector, no per la ruta

La política d’encaminament coincideix per origen, així que l’origen ha de ser estable abans que res. Posa els dispositius escollits en un grup d’adreces que mantingui un administrador o, millor, en un segment dedicat el membres del qual segueixi el rol del dispositiu. Quan la rotació normal de DHCP pot moure una adreça coincident a una altra màquina, la política selecciona silenciosament el client equivocat, i el primer informe sol tractar-se de navegació lenta que en realitat és un desviament.

Anomena el grup per la política a la qual serveix, no per una planta o un departament, perquè la regla d’encaminament sobreviurà a tots dos. Anota quins dispositius hi ha i qui pot afegir-ne un.

Afegiu la política de la sucursal i defenseu-ne l’ordre

Al SonicWall de la sucursal, una política de ruta selecciona el grup d’origen, nomena les destinacions previstes i estableix la interfície del túnel com a passarel·la, que és per a què existeix el disseny d’interfície de túnel compatible. Mantingueu les regles de destinacions locals i privades per sobre de la regla àmplia d’Internet, perquè la primera coincidència guanya i un prefix privat empès dins del túnel arriba a la seu central només per ser descartat. Preserveu també la ruta pròpia del tallafoc cap al seu parell VPN, o el transport del túnel seguirà la política de la qual depèn. Res d’això no us obliga a convertir tots els túnels existents basats en polítiques; la interfície de túnel és una opció compatible entre diverses.

L’ordre és la part que canvia per accident. Qui afegeix una excepció l’ha d’inserir per sobre de la regla àmplia, i qui edita la regla àmplia pot invertir tot el disseny amb un sol desament. Escriviu l’ordre previst al costat de la política i torneu-lo a comprovar després d’actualitzacions de microprogramari, perquè el nom de les interfícies i la representació de les polítiques sí que canvien entre versions.

Acabeu el camí a la seu central

La política del túnel a la seu central ha d’acceptar el trànsit que ara selecciona la ruta de la sucursal. Un selector interoficines limitat a la LAN privada de la seu central no és permís per transportar destinacions públiques arbitràries, així que la política necessita l’origen de la sucursal i el rang de destinacions que realment voleu. La seu central reenvia després aquest trànsit entrant al seu enllaç d’Internet segons les seves pròpies regles d’accés, i l’exemple de sortida central de SonicWall inclou la traducció d’origen per a la xarxa remota al WAN central. Sense aquesta traducció, el costat llunyà veu una adreça privada de sucursal i no té ruta de tornada cap a ella.

Les respostes són l’altra meitat del contracte. Han de tornar pel túnel o per la traducció amb estat creada per a elles, i el trànsit de llocs privats pot necessitar un tractament NAT diferent del de la sortida pública. Mantingueu aquestes regles distingibles, perquè una regla de traducció àmplia que amagui cada origen intern fa que el registre i la resolució de problemes posteriors siguin molt més difícils de llegir.

Decidiu què fa el grup quan cau el túnel

Si la sortida central és un requisit i no una preferència, tornar al WAN local és un incompliment normatiu encara que els usuaris continuïn en línia. SonicOS documenta una ruta de descart d’interfície de túnel com la manera compatible d’evitar que el trànsit seleccionat prengui un camí alternatiu no previst.

Feu coincidir l’abast i la prioritat d’aquesta ruta amb la versió instal·lada, i proveu-la abaixant el túnel en lloc de confiar en l’etiqueta. Un grup que no ha de sortir mai localment hauria de fallar tancat, mentre que un grup on la disponibilitat importa més pot tornar enrere legítimament; totes dues són decisions, i cap no hauria de passar per defecte.

Verifiqueu des de tres clients i després revertiu net

Un ping a la passarel·la central prova la cosa equivocada, perquè s’origina al tallafoc i no en un client seleccionat. Proveu des dels dispositius, i proveu-ne tres: un dispositiu seleccionat, un dispositiu ordinari que hauria de quedar-se local, i un que depèn de serveis locals.

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

Compareu on va sorgir realment la sol·licitud pública. Un client seleccionat hauria d’arribar a Internet per la sortida de la seu central, i un client ordinari hauria de continuar presentant l’adreça pròpia de la sucursal al costat llunyà; 203.0.113.10 és una adreça de documentació utilitzada com a substituta de la destinació que us interessa. Incloeu el DNS en la mateixa passada, perquè un client que consulta el resolutor de la sucursal pot produir una consulta originada al router amb un origen diferent i, per tant, una ruta diferent.

La reversió és l’ordre de polítiques desat més el grup d’adreces. Restaureu l’ordre anterior, traieu el grup de la política i torneu a provar les dues classes de dispositius. Conserveu la configuració exportada amb el registre del canvi, perquè el pròxim enginyer ha de saber quina regla era l’àmplia abans que algú l’edités.