Come modellare un flusso VPN con ASA packet-tracer

Packet-tracer su un ASA risponde a una domanda ristretta: questo pacchetto, che entra qui con questa tupla, sarebbe consentito, e dove andrebbe. Non risponde se l'estremità remota riceve qualcosa. L'errore abituale è fornire una tupla IKE esterna quando ciò che volete provare è l'applicazione che viaggia dentro il tunnel. Correggete prima la tupla, leggete le fasi, poi raccogliete prove reali per tutto ciò che il simulatore non può vedere.

La dimostrazione seguente presuppone che l'ACL, la regola NAT e il contesto tunnel-group siano davanti a voi. Senza di essi l'output descrive una politica che non potete verificare.

Passo 1: scrivete il flusso interno in parole semplici

Descrivete l'applicazione prima di digitare qualsiasi cosa. Un host interno che apre SSH verso un server dietro il gateway remoto è un flusso TCP interno con una porta sorgente specifica. È il flusso che ACL e filtro VPN valutano, quindi è il flusso che digitate.

Scrivetelo come una frase, poi traducetelo campo per campo:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

Passo 2: scegliete l'ingresso e la direzione

L'ingresso è l'interfaccia su cui arriva il pacchetto, non quella da cui esce. Per un host LAN che inizia, è l'interfaccia inside. Per il pacchetto di ritorno della stessa sessione è l'interfaccia outside, e la tupla si inverte. Scrivere la destinazione come sorgente è il secondo modo più comune di ottenere un ALLOW convincente ma irrilevante.

Anche le porte hanno una direzione. La porta del servizio appartiene al campo destinazione per una richiesta avviata, e la porta effimera del client appartiene al campo sorgente. Un modello con destinazione TCP 500 descrive un'applicazione TCP in ascolto sulla 500; non diventa un test IKE solo perché il numero compare nel comando.

Passo 3: leggete le fasi in ordine

Ogni fase nell'output è una decisione con un proprietario: ricerca della rotta, ACL, NAT, poi selezione VPN o tunnel. Leggetele nell'ordine stampato e fermatevi alla prima fase che non concorda con il progetto.

NAT coglie molti di sorpresa. Se la sorgente tradotta cade fuori dall'ACL crypto che seleziona il traffico per il tunnel, il flusso può essere consentito e mai incapsulato. La traccia stampa l'indirizzo tradotto, quindi confrontatelo con il traffico interessante del tunnel e non con l'indirizzo originale.

Passo 4: verificate quali aggiramenti avete selezionato

La forma detailed accetta opzioni che saltano controlli, e Cisco documenta un'opzione bypass-checks che copre ACL, filtro VPN, uRPF e controlli di spoofing IPsec. Un ALLOW ottenuto con quegli aggiramenti dice che rotta e NAT funzionerebbero, non che la politica ammetterebbe un pacchetto reale. Annotate le opzioni accanto al risultato.

Se vi serve la risposta di politica, eseguitelo senza gli aggiramenti. Se state isolando una questione di routing, eseguitelo con essi ed etichettate il risultato come risposta di routing.

Passo 5: colmate il divario con lo scambio reale

Un permesso simulato si ferma all'ASA. Se il gateway remoto ha decifrato il pacchetto, se il server ha accettato la connessione e se è tornata una risposta sono osservazioni separate. Usate contatori di endpoint o una cattura ristretta su un percorso approvato.

Alcune opzioni di trace e replay trasmettono pacchetti o conservano stato. Seguite il comportamento documentato per la vostra versione e la vostra procedura diagnostica approvata invece di trattare ogni variante come una consultazione in sola lettura.

Cosa la traccia ancora non può dirvi

Tenete quattro cose in una nota: la tupla, la regola NAT corrispondente, il tunnel o la politica che dovrebbe portare il flusso e l'osservazione specifica per la direzione. Senza di esse un ingegnere successivo non può separare una decisione locale di politica da un piano di controllo consolidato e da un servizio funzionante. Un primo fallimento seguito da un successo non è prova che il tunnel dovesse salire nel frattempo; annotate la fase e il cambio di stato.

Partite dalla tupla interna, fermatevi alla prima fase che contraddice il progetto e solo allora cercate prove di endpoint. La traccia è un oracolo di politica, non una ricevuta di consegna.