Instradare una sottorete di filiale tramite l'uscita Internet del SonicWall della sede centrale

I telefoni della filiale dovrebbero uscire attraverso la sede centrale mentre i portatili della filiale continuano a usare il WAN locale, e la politica di routing da sola non lo garantirà. Una rotta di filiale può selezionare il tunnel, ma la politica del tunnel deve accettare il traffico, la sede centrale deve inoltrarlo e tradurlo, e la risposta deve tornare per la stessa strada. Se manca uno di questi tre, il sintomo sarà un sottoinsieme di client che perdono Internet proprio mentre il tunnel è attivo.

Partite dal selettore, non dalla rotta

La politica di routing corrisponde per origine, quindi l'origine deve essere stabile prima di ogni altra cosa. Mettete i dispositivi scelti in un gruppo di indirizzi mantenuto da un amministratore o, meglio, su un segmento dedicato la cui appartenenza segue il ruolo del dispositivo. Quando il normale ricambio DHCP può spostare un indirizzo corrispondente su un'altra macchina, la politica seleziona silenziosamente il client sbagliato, e la prima segnalazione riguarda di solito una navigazione lenta che in realtà è un percorso tortuoso.

Nominate il gruppo in base alla politica che serve, non a un piano o a un reparto, perché la regola di routing sopravviverà a entrambi. Annotate quali dispositivi ne fanno parte e chi può aggiungerne uno.

Aggiungete la politica della filiale, poi difendetene l'ordine

Sul SonicWall della filiale una politica di rotta seleziona il gruppo di origine, nomina le destinazioni previste e imposta l'interfaccia del tunnel come gateway, ed è esattamente a questo che serve il progetto di interfaccia tunnel supportato. Tenete le regole per destinazioni locali e private sopra la regola Internet ampia, perché vince la prima corrispondenza e un prefisso privato spinto nel tunnel arriva alla sede centrale solo per essere scartato. Conservate anche la rotta del firewall stesso verso il suo peer VPN, altrimenti il trasporto del tunnel seguirà la politica da cui dipende. Niente di tutto ciò vi obbliga a convertire ogni tunnel esistente basato su politica; un'interfaccia tunnel è una scelta supportata tra diverse.

L'ordine è la parte che cambia per errore. Chi aggiunge un'eccezione deve inserirla sopra la regola ampia, e chi modifica la regola ampia può invertire l'intero progetto con un solo salvataggio. Scrivete l'ordine previsto accanto alla politica e ricontrollatelo dopo gli aggiornamenti del firmware, perché la denominazione delle interfacce e la resa delle politiche cambiano davvero tra le versioni.

Completate il percorso presso la sede centrale

La politica del tunnel presso la sede centrale deve accettare il traffico che ora la rotta della filiale seleziona. Un selettore inter-ufficio limitato alla LAN privata della sede centrale non è un permesso per trasportare destinazioni pubbliche arbitrarie, quindi la politica necessita dell'origine della filiale e dell'intervallo di destinazioni che intendete davvero. La sede centrale inoltra poi quel traffico in arrivo al proprio collegamento Internet secondo le proprie regole di accesso, e l'esempio di uscita centrale di SonicWall include la traduzione dell'origine per la rete remota presso il WAN centrale. Senza quella traduzione il lato remoto vede un indirizzo privato di filiale e non ha una rotta di ritorno.

Le risposte sono l'altra metà del contratto. Devono tornare attraverso il tunnel o attraverso la traduzione con stato creata per loro, e il traffico verso siti privati può richiedere un trattamento NAT diverso da quello dell'uscita pubblica. Mantenete quelle regole distinguibili, perché un'unica regola di traduzione ampia che nasconde ogni origine interna rende la registrazione e la risoluzione dei problemi successive molto più difficili da leggere.

Decidete cosa fa il gruppo quando il tunnel cade

Se l'uscita centrale è un requisito e non una preferenza, tornare al WAN locale è un inadempimento di conformità anche se gli utenti restano online. SonicOS documenta una rotta di scarto dell'interfaccia tunnel come il modo supportato per impedire al traffico selezionato di prendere un percorso alternativo indesiderato.

Allineate l'ambito e la priorità di quella rotta alla versione installata, e testatela abbattendo il tunnel invece di fidarvi dell'etichetta. Un gruppo che non deve mai uscire localmente dovrebbe fallire chiuso, mentre un gruppo in cui la disponibilità conta di più può legittimamente tornare indietro; entrambe sono decisioni, e nessuna dovrebbe avvenire per impostazione predefinita.

Verificate da tre client, poi tornate indietro in modo pulito

Un ping al gateway centrale verifica la cosa sbagliata, perché parte dal firewall e non da un client selezionato. Testate invece dai dispositivi, e testatene tre: un dispositivo selezionato, un dispositivo ordinario che deve restare locale e uno che dipende da servizi locali.

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

Confrontate dove è emersa davvero la richiesta pubblica. Un client selezionato dovrebbe raggiungere Internet tramite l'uscita della sede centrale, e un client ordinario dovrebbe continuare a mostrare l'indirizzo proprio della filiale sul lato remoto; 203.0.113.10 è un indirizzo di documentazione usato come sostituto della destinazione che vi interessa. Includete il DNS nella stessa passata, perché un client che interroga il resolver della filiale può produrre una ricerca originata dal router con un'origine diversa e quindi una rotta diversa.

Il rollback è l'ordine delle politiche salvato più il gruppo di indirizzi. Ripristinate l'ordine precedente, rimuovete il gruppo dalla politica e ritestate entrambe le classi di dispositivi. Conservate la configurazione esportata con il registro delle modifiche, perché il prossimo ingegnere deve sapere quale regola era quella ampia prima che qualcuno la modificasse.