Tenete due registri di rotte in un lab IPsec: sottostante e protetto
Due registri: uno raggiunge il peer, l’altro porta i prefissi privati. Seguite entrambi e trattate la ridistribuzione come una decisione di politica, non come una scorciatoia.
Due domande si intrecciano in un lab IPsec: come un pacchetto raggiunge l’indirizzo esterno del peer e come raggiunge le reti private dietro quel peer. Appartengono a registri separati, perché processi di routing diversi rispondono e falliscono con sintomi diversi. Tenete il registro sottostante per gli endpoint esterni e i next hop che li raggiungono. Tenete il registro sovrapposto per i prefissi protetti, i loro gateway e il percorso previsto nel tunnel. La maggior parte della confusione nel lab nasce dal leggere una rotta che esiste legittimamente in un registro come prova sull’altro.
Due registri, due domande
I registri restano abbastanza brevi da tenere a mano finché il lab è piccolo, ed è proprio allora che sono più utili. Due colonne bastano: che cosa è la voce e come la si raggiunge.
| Ledger | What it lists |
|---|---|
| Underlay | Each gateway's external address and the next hop that reaches it |
| Protected | Each private prefix, its local gateway and its intended path through the tunnel |
Scrivete entrambe le direzioni. Un prefisso che compare nel registro in uscita e non in quello di ritorno produce un tunnel che trasporta richieste e lascia cadere le risposte. Quello stato a metà funzionante è l’esito più comune nel lab, ed è facile scambiarlo per un problema di politica.
Scrivete la destinazione prima del protocollo
Cominciate dalle destinazioni, non dai protocolli. Per ogni gateway, annotate l’indirizzo esterno e il next hop che lo raggiunge. Poi annotate ogni prefisso privato, il suo gateway locale e il percorso che dovrebbe seguire nel tunnel.
Farlo prima di scegliere un protocollo di routing mantiene onesta la discussione. Il progetto arriva con requisiti, non con preferenze. Il dibattito su quale protocollo eseguire diventa allora una domanda su quale requisito sia davvero difficile.
Statico o dinamico, deciso per registro
Il routing statico sul lato trasporto è di solito giusto in un lab: due estremi, un next hop, niente da far convergere. Il lato privato può ragionevolmente essere dinamico, perché i prefissi vanno e vengono con l’esercizio. Eseguire un protocollo di routing sul lato trasporto e un altro sul lato privato non vi obbliga a ridistribuire tra i due, e trattare la ridistribuzione reciproca come prerequisito per IPsec è dove i lab iniziano a produrre risultati che nessuno sa spiegare.
Decidete i due registri separatamente e annotate quale è dinamico. Una sola risposta per entrambi i lati di solito significa che le due domande non sono mai state davvero separate.
La ridistribuzione è un confine di politica
Dove le rotte devono incrociarsi, fate dell’incrocio una politica con prefissi nominati, direzione, trattamento della metrica e protezione dai loop. Le liste di prefissi e le mappe di rotte vi danno tutte e quattro, e i tag mantengono identificabile una rotta ridistribuita dopo che ha perso il contesto originale. Leggete la semantica con attenzione, perché non sono intercambiabili: un deny ACL dentro una clausola di match significa che la rotta non corrisponde e la valutazione continua, mentre una sequenza di deny in una mappa di rotte impedisce del tutto la ridistribuzione della rotta. La guida alle mappe di rotte per la ridistribuzione copre quelle clausole e le modifiche agli attributi che le accompagnano.
Poi confrontate la tabella di routing risultante con entrambi i registri. Un lab che inizia a inoltrare dopo una ridistribuzione ampia ha dimostrato raggiungibilità, non intenzione. Qualsiasi voce della tabella che non compaia in nessuno dei due registri significa che l’export è più ampio del progetto, e ogni annuncio successivo eredita quell’ambiguità.
Tenete l’esempio di sicurezza aggiornato quanto il routing
Le vecchie guide che si basano su algoritmi deboli o su un segreto dimostrativo condiviso sono osservazioni storiche. Copiarle in un lab che intendete estendere è il modo in cui i default deboli sopravvivono in produzione. Usate la politica supportata dalla piattaforma e annotate la versione che avete testato, perché il lab sopravvive al tutorial.
Accettate un flusso host-to-host approvato, il suo traffico di ritorno e una destinazione che deve restare fuori dall’ambito di protezione. Salvate l’origine della rotta e i selettori negoziati con ogni risultato, così il verbale mostra quale strato è stato dimostrato invece di quale strato era attivo per caso.
Quando qualcosa si rompe, il registro dice quale strato aprire. Nessuna raggiungibilità verso il peer è trasporto, nessuna rotta interna è percorso privato, e una rotta che esiste senza un selettore corrispondente è politica. Tre frasi, una diagnosi, nessun indovinello.