Una rotta predefinita VPN nella tabella 200 nasconde la tua rotta LAN

Quattro controlli separano un guasto della tabella di policy da un guasto di instradamento: quale regola ha corrisposto, quale tabella quella regola ha nominato, cosa contiene quella tabella e quale rotta al suo interno ha vinto. La tabella principale non viene più consultata quando una tabella precedente produce una rotta, quindi una voce LAN visibile lì può essere irrilevante per il pacchetto che stai testando. Esegui i controlli in ordine, e la rotta mancante comparirà al terzo passo anziché al quarto.

La corrispondenza del prefisso più lungo avviene dentro una sola tabella; non confronta le rotte di tutte le tabelle come un unico elenco.

La ricerca termina alla prima tabella che risponde

Prendi una policy in cui il traffico da una sottorete consulta prima la tabella 200, la tabella 200 contiene una rotta predefinita attraverso il tunnel e la tabella principale contiene il prefisso LAN. Un pacchetto verso un indirizzo LAN può corrispondere a quella rotta predefinita nella tabella 200 e fermarsi lì. Poiché la ricerca ha prodotto una rotta, la regola successiva della tabella principale non ha mai la possibilità di offrire la sua voce più specifica. Il risultato è un pacchetto che entra nel tunnel mentre una rotta LAN perfettamente valida resta inutilizzata.

Le regole precedenti e la ricerca degli indirizzi locali della macchina si applicano ancora, quindi il test deve usare la sorgente, il marchio e l’interfaccia che porta il flusso reale. Interroga con qualcos’altro e la LAN potrebbe essere selezionata correttamente, il che nasconde proprio il guasto che stai cercando.

Metti l’eccezione LAN dove deve stare

La tabella scelta può portare le rotte LAN, connesse e verso l’endpoint di cui ha bisogno, il che mantiene la policy autosufficiente. Un altro progetto usa una regola precedente esplicita per il prefisso LAN, o una rotta di scarto deliberata che consegna un prefisso a una ricerca successiva. Ognuno è uno schema legittimo con un proprietario diverso. Scegli in base alla policy prevista e a chi mantiene le rotte, non a quale è più breve da digitare.

Qualunque sia lo schema, l’eccezione deve essere visibile dove è definita la policy. Una rotta aggiunta a mano e non registrata scomparirà al prossimo riavvio e porterà con sé la diagnosi.

Non copiare la tabella principale per intero

Copiare ogni rotta dalla principale alla tabella di policy sembra una correzione e crea un’istantanea. Un amministratore può aggiungere o rimuovere indirizzi e interfacce in modo dinamico, e la copia diventa obsoleta senza che nessuno se ne accorga. Mantieni il ciclo di vita delle rotte presso il suo proprietario di configurazione e rigenera la tabella dalla configurazione, non da un momento nel tempo.

Una tabella copiata vanifica anche lo scopo, perché riproduce il comportamento di riserva che la policy doveva limitare.

Controlla le risposte separatamente dalle rotte

Una volta che la ricerca ha scelto il percorso voluto, le risposte possono comunque fallire per motivi che non hanno nulla a che fare con la tabella. La traduzione può essere applicata sull’interfaccia sbagliata, la validazione del percorso inverso può rifiutare un pacchetto arrivato da un percorso inatteso, o l’endpoint può semplicemente non rispondere. Sono guasti distinti con prove distinte, e nessuno di essi si ripara modificando le voci di rotta.

Salva la ricerca per quello stesso flusso ai due lati della modifica, così la correzione resta visibile. Disattivare globalmente i controlli del percorso inverso o svuotare le regole non fornisce alcuna rotta mancante e indebolisce controlli non correlati.

Annota la regola, la tabella, la rotta vincente e il percorso della risposta. Quella registrazione separa un errore di policy da un servizio guasto.