Dove termina il VPN del sito decide cosa viene ispezionato

Un tunnel tra sedi nasconde un dettaglio che decide l’intera progettazione dell’ispezione: il dispositivo esatto in cui il pacchetto interno appare in chiaro. Tutto ciò che sta prima di quel punto vede ESP, e tutto ciò che sta dopo vede normale IP che una regola può intercettare. Metti il confine nel posto sbagliato e il firewall che hai pagato diventa un router con una licenza. La procedura che segue traccia prima la linea e solo dopo chiede quale apparato debba possederla.

Traccia la linea dove il pacchetto smette di essere cifrato

In modalità tunnel il pacchetto originale viene cifrato e avvolto in una nuova intestazione IP esterna indirizzata al gateway peer. Quel pacchetto esterno trasporta il protocollo 50 per ESP, così qualsiasi dispositivo tra i due gateway può instradarlo senza leggere gli indirizzi interni. Il primo dispositivo che decifra è il confine di sicurezza, ed è anche il primo che può applicare criteri al flusso interno. Tutto ciò che sta a valle di quel punto è instradamento ordinario.

Segna tre cose sul disegno: l’endpoint esterno che ammette ESP, le reti protette nominate nel criterio, e il next hop che il pacchetto decifrato compie. Se queste tre cose non stanno sullo stesso dispositivo, hai un passaggio da progettare invece di un unico punto di controllo.

La RFC 4301 chiama il dispositivo che decifra gateway di sicurezza e tratta il suo criterio come parte del confine. È una cornice più utile della categoria di prodotto, perché un dispositivo è un confine quando detiene il criterio, non quando la sua scheda tecnica dice firewall.

Firewall come terminazione: un dispositivo, un punto di criterio

Quando il firewall termina il tunnel, il router a monte deve solo consegnargli ESP. Il firewall autentica il peer, decifra e poi applica le sue regole normali al pacchetto interno verso la VLAN dei server. Così c’è un solo posto dove leggere il criterio e un solo posto dove leggere i log, che è di solito ciò che chiede un audit.

Verifica separatamente le due autorizzazioni. Consentire IKE ed ESP verso l’apparato non è la stessa regola che consentire a una sede remota di raggiungere un server, e un firewall che accetta il tunnel bloccando il flusso interno appare, dall’estremità remota, esattamente come un tunnel rotto.

Il costo è che il firewall ora sta sul percorso di tutto il traffico di sede, quindi throughput, limiti di sessione e comportamento di failover diventano il comportamento del tunnel stesso. Dimensionarlo per i flussi di sede combinati, non per il profilo di accesso remoto per cui forse è stato acquistato.

Router come terminazione: il salto di ispezione diventa opzionale

Quando il router decifra, il pacchetto è già in chiaro quando raggiunge la tabella di routing. Se un firewall separato deve ispezionare quel traffico, il router deve inviarlo attraverso il firewall e il percorso di ritorno deve tornare allo stesso modo. Una rotta diretta dal router alla VLAN dei server toglie silenziosamente il firewall dal percorso lasciandolo nel diagramma.

Questo è il guasto da cercare in una rete esistente: due rotte verso lo stesso prefisso, una attraverso il firewall e una diretta, con quella diretta che vince per lunghezza del prefisso o metrica. Il tunnel continua a far passare traffico e l’ispezione in cui credi non avviene.

I tunnel basati su rotte rendono tutto ciò visibile, perché il tunnel è un’interfaccia attraverso cui puoi instradare verso un altro dispositivo. I tunnel basati su criteri selezionano il traffico tramite selettore, il che può lasciare il pacchetto decifrato sul router senza altre destinazioni.

Poni le stesse cinque domande a entrambi i candidati

Un breve foglio di lavoro batte una matrice di funzioni, perché ogni domanda corrisponde a una linea del disegno. Chiedi a ciascun candidato:

• Quali versioni di IKE, quali metodi di autenticazione dei peer e quali modelli di routing questa release supporta davvero?
• Dove viene ammesso ESP e dove il flusso decifrato viene consentito o negato?
• Come apprendono gli host locali i prefissi remoti e come il lato remoto apprende i tuoi?
• Quali throughput, numero di sessioni e comportamento di failover deve sostenere l’endpoint per il carico reale?
• Chi possiede le credenziali dei peer, il criterio e il percorso di ripristino quando il guasto è il tunnel stesso?

pfSense documenta IPsec basato su criteri e IPsec basato su rotte come modelli separati con vincoli separati, e quella differenza conta più dell’etichetta sulla scatola. Verifica la modalità esatta e il filtraggio supportato del traffico decifrato nella release che distribuiresti davvero.

Se un candidato non sa rispondere alla seconda domanda con una regola che puoi leggere, non è il confine che vuoi, per quanto bene faccia il resto. Chiedi il testo della regola invece di un sì, e tratta una risposta vaga come un no.

Verifica il percorso con una cattura, non con il diagramma

Un diagramma descrive l’intenzione e una cattura descrive il comportamento, quindi conferma quale interfaccia trasporta ESP e quale il flusso interno prima di fidarti dell’uno o dell’altra.

tcpdump -ni wan0 esp
tcpdump -ni lan0 host 10.60.4.20
ip xfrm policy list

Se la prima cattura mostra ESP in arrivo e la seconda mostra il pacchetto interno sul lato LAN, il punto di decifratura è dove pensi che sia. Se il pacchetto interno appare su un segmento che aggira il firewall, l’instradamento è sbagliato qualunque cosa dica il testo del criterio. L’elenco xfrm mostra poi quali selettori sono installati e in quale direzione.

Ripeti la cattura sul percorso di ritorno, perché l’instradamento asimmetrico è comune quando una sede ha due uscite possibili. Un tunnel che funziona in una direzione e va in timeout nell’altra è quasi sempre questo, e nessuna modifica del criterio sul lato remoto lo risolverà.