Il NAT di origine nasconde gli indirizzi dei client a un firewall successivo

Una regola scritta per i client dello staff e del laboratorio viene applicata al nuovo firewall di bordo, e corrisponde silenziosamente a tutto o a nulla. La ragione sta più a monte: un gateway ha già riscritto gli indirizzi dei client, quindi la regola vede un solo indirizzo di transito invece di due gruppi. Aggiungere un apparato non ripristina l'informazione che il percorso ha rimosso. Trovate l'ultimo punto in cui la distinzione esiste ancora prima di scrivere la politica.

Perché la regola di bordo vede un solo indirizzo

La traduzione molti-a-uno mappa ogni coppia interna di indirizzo e porta su un indirizzo esterno condiviso con una porta assegnata. Le conversazioni restano distinguibili per il traduttore grazie a quei binding di porta, ma un dispositivo più a valle che esegue una semplice corrispondenza di prefisso di origine vede solo l'indirizzo condiviso. Questo basta a rendere due gruppi identici nella regola. I pacchetti arrivano ancora; il raggruppamento no.

Verificate ciò che l'interfaccia del firewall osserva davvero, non ciò che promette lo schema. I due differiscono più spesso di quanto chiunque si aspetti.

Trovate l'ultima identità applicabile

Partite dal punto di applicazione e tornate indietro finché non compare il prefisso originale. Due comandi di solito individuano il confine.

iptables -t nat -L POSTROUTING -n -v
conntrack -L -s 10.90.0.2 | head

La tabella NAT mostra quale traffico viene tradotto e da quale regola, mentre l'elenco conntrack mostra le tuple originali e tradotte dei flussi attivi. Dove il firewall a monte vede sempre e solo l'indirizzo tradotto, le regole di origine per gruppo non possono funzionare, per quanto ben scritte. Procedete avanti o indietro lungo il percorso fino a un dispositivo in cui i due prefissi dei client restano distinti. Annotate l'origine a ogni salto invece di fidarvi di un'etichetta interna o esterna.

Tre posizioni e quanto costa ciascuna

La politica può vivere sul gateway che traduce, dove le origini originali sono ancora visibili. Può vivere sul firewall a monte se il transito diventa instradato invece che tradotto, il che significa aggiungere rotte di ritorno e rimuovere la riscrittura dell'origine. Oppure può essere applicata sull'identità invece che sugli indirizzi, tramite un controllo autenticato che conosce l'utente o il dispositivo. Ogni scelta ha un proprietario e una modalità di guasto, e solo le prime due mantengono la regola puramente sulle origini.

Qualunque scegliate, documentate la regola insieme all'indirizzo con cui corrisponde. Una regola la cui ipotesi di indirizzo è cambiata silenziosamente è peggiore di nessuna regola, perché continua a corrispondere al traffico mentre protegge qualcosa di completamente diverso.

Accettazione: un client consentito e uno negato

Provate con una coppia di client, uno per gruppo, e catturate come ciascuno arriva al punto di applicazione. Conservate entrambe le tuple accanto al risultato della regola, così che la prova mostri che la distinzione è sopravvissuta e non che esiste un altro firewall. Ripetete il test dopo un cambio di NAT o di instradamento, perché l'indirizzo presentato è la parte che si rompe in silenzio. Mantenete l'autenticazione dove le persone vanno distinte, poiché un indirizzo di origine è un input della politica, non una prova d'identità.

Scrivete il punto di applicazione, l'origine osservata e la regola nel ticket. Altrimenti l'ingegnere successivo aggiunge un secondo firewall e la stessa regola.