VPN da sito a sito: quale direzione ha davvero bisogno di una regola?

Entrambe le estremità segnalano un tunnel stabilito, la sede remota risponde dal gateway e l'applicazione va comunque in timeout per gli utenti su un lato. Il consiglio abituale dice di aggiungere una regola del firewall in entrambe le direzioni. A volte è corretto, a volte duplica una regola già esistente e a volte è la seconda regola a rompere lo stato. Quale caso si applichi dipende da dove il firewall vede il pacchetto.

Il traffico di ritorno con stato cambia il conteggio

Un firewall con stato registra la richiesta e ammette la risposta senza una seconda regola, quindi un progetto che richiede una sola regola è normale. Una lista di accesso senza stato non ha questa memoria e la risposta deve essere consentita esplicitamente. Entrambi sono corretti sulla propria piattaforma, ed è per questo che i consigli si contraddicono.

Leggete la documentazione di inoltro della piattaforma davanti a voi e verificate se la policy che state modificando è con stato dove vede il pacchetto. Un rifiuto esplicito per il traffico stabilito, o un ordine di regole che valuta la risposta prima della tabella degli stati, trasforma un progetto funzionante in uno enigmatico. Il numero di regole è un dettaglio implementativo, mentre il requisito è che entrambe le direzioni di una conversazione consentita possano completarsi.

Dove il firewall vede i pacchetti decifrati

In un tunnel basato su policy, il firewall può valutare il pacchetto cifrato prima della decifratura e il pacchetto decifrato dopo, su interfacce diverse. Una regola scritta per quella sbagliata è presente, corretta e non viene mai confrontata. È così che un insieme di regole copiato da un deployment funzionante può fallire su hardware identico.

L'IPsec basato su routing e la maggior parte delle implementazioni moderne presentano un'interfaccia di tunnel, quindi il pacchetto decifrato arriva lì e si applicano le normali regole di interfaccia. Confermate quale modello usa il deployment prima di copiare un insieme di regole da una guida scritta per l'altro. L'interfaccia di tunnel è anche il punto da guardare quando dovete sapere se un pacchetto è stato decifrato.

Il routing asimmetrico rompe l'assunzione

Un firewall con stato presume di vedere entrambe le metà della conversazione. Se la risposta torna attraverso un altro gateway, quel dispositivo non ha stato per la richiesta e la scarta secondo la propria policy. Il sintomo è un guasto unidirezionale che nessuna regola sul lato mittente può riparare. Tracciate il percorso della risposta prima di modificare qualsiasi cosa.

Controllate la rotta della risposta prima di aggiungere un'ampia regola di autorizzazione su entrambi i lati. Tollerare tutto su ogni interfaccia nasconde l'errore di routing e allarga l'accesso nello stesso tempo, che è la peggiore combinazione disponibile.

Verificate entrambe le direzioni con indirizzi di origine reali

Provate con l'indirizzo che il lato remoto osserva davvero, perché la traduzione può far sì che una regola di origine non corrisponda a nulla. Eseguite la cattura su entrambi i gateway contemporaneamente.

tcpdump -ni any 'host 10.30.8.15 and tcp port 443'
nft list ruleset | grep -A 8 'chain forward'
ip route get 10.30.8.15
conntrack -L | grep 10.30.8.15

Una richiesta che compare sul gateway remoto con un indirizzo di origine inatteso spiega una regola che non corrisponde mai, e una risposta che arriva sull'interfaccia sbagliata spiega un disallineamento di stato. Poi provate una destinazione dentro l'ambito approvato e una fuori, così il confine viene dimostrato invece che assunto.

Annotate l'indirizzo di origine dopo la traduzione, l'interfaccia usata dal pacchetto decifrato e la regola che ha corrisposto. Questi tre fatti rispondono al prossimo ticket senza ripetere tutta l'indagine.