Cosa registrare per una VPN da sito a sito: selettori e ambito

Sei mesi dopo la messa in servizio di un tunnel, una nuova sottorete smette di corrispondere alla politica e l'unico documento sulla condivisione dice VPN di ufficio. È il guasto che un registro dei selettori previene, ed è specifico: un insieme di indirizzi è cambiato mentre le carte no. Scrivere bene il registro significa sapere quale di diversi insiemi di indirizzi si sta descrivendo, e annotare quello che il peer applica davvero invece di quello configurato.

Configurato non è negoziato

In un tunnel IPsec basato su politiche, ciascun lato propone selettori di traffico: intervalli di origine e destinazione per l'associazione figlia. Il lato che risponde può restringere quella proposta , quindi l'associazione installata può coprire meno di quanto elenca la configurazione. Un registro che copia la configurazione descrive quindi un'intenzione, non l'ambito di protezione attuale. I due divergono in silenzio, e nulla nella pagina di stato del tunnel lo segnala.

Conservi entrambe le colonne, con la data in cui le ha osservate. Il selettore configurato è ciò che si intendeva; quello negoziato è ciò che il kernel sta applicando adesso. Quando differiscono, quella differenza spiega un guasto sorprendente molto più spesso di un errore di routing.

Un'associazione inoltre non rappresenta ogni coppia configurata. Un tunnel con diverse combinazioni di selettori può finire con diverse associazioni figlie, e un registro che ne elenca una è un inventario parziale. Le elenchi invece di riassumerle.

I tunnel basati su rotte selezionano diversamente

Con un'interfaccia basata su rotte, la tabella di routing decide cosa entra nel tunnel e i selettori possono essere volutamente ampi. È una progettazione legittima e non una trascuratezza, e il registro deve descriverla come tale. Annoti la rotta, l'interfaccia a cui punta e la politica del firewall che limita quali servizi sono raggiungibili. L'ambito di protezione è ampio di proposito, e l'ambito del servizio opera il restringimento.

Copiare un modello basato su politiche su un tunnel basato su rotte produce un documento che descrive un meccanismo che la distribuzione non usa. L'ingegnere successivo cerca allora selettori che non avrebbero mai dovuto esserci, e conclude che il tunnel è configurato male quando è solo documentato male.

La traduzione appartiene alla stessa tabella

Quando il NAT presenta un intervallo diverso al peer, registri insieme i prefissi originali e tradotti. Annoti la fase in cui i selettori e le regole di accesso li fanno corrispondere, perché l'ordine decide se il lato remoto vedrà mai l'indirizzo annotato. Una tabella con uno solo dei due intervalli è peggiore di nessuna tabella, perché sembra completa.

È il dettaglio che rompe un tunnel funzionante dopo un cambio di NAT: il selettore corrisponde ancora al prefisso originale, il peer riceve ora uno tradotto e la sua rotta di ritorno punta a un indirizzo che non esiste più. Nulla registra un errore nel momento in cui i due smettono di concordare.

Il DNS privato appartiene allo stesso posto. Un nome che risolve in un indirizzo inutilizzabile dal sito in questione è un errore di documentazione con un ticket di assistenza allegato, e se ne accuserà il tunnel.

Alleghi il requisito di servizio

Un intervallo protetto non è un elenco di autorizzazioni. Annoti quali servizi devono essere raggiungibili da quale origine, e chi possiede l'applicazione dietro di essi. Quei due campi rispondono a domande diverse, e confonderli è il modo in cui una revisione di sicurezza finisce per discutere di routing invece che di accesso.

Poi nomini l'amministratore di rete che mantiene la regola. Un inventario dei selettori senza proprietario invecchia in silenzio, e l'obsoleto non si distingue dallo sbagliato quando il tunnel si rompe alle due del mattino. Il proprietario è anche la persona che può confermare che un cambiamento è stato deliberato.

Trasformi il registro in un piano di test

Per ogni percorso richiesto, scelga un host di origine e uno di destinazione rappresentativi e annoti la rotta, il servizio e il gateway di risposta attesi. Questo trasforma il documento in un piano di test invece che in una descrizione. Rilegga l'associazione attiva con il comando qui sotto, e la confronti con la riga negoziata annotata.

swanctl --list-sas

Uno scheletro di cinque righe di solito basta a mantenere onesto il registro. La versione qui sotto entra in un ticket di cambiamento senza troncamenti:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

Un ping solo al gateway non è il test di accettazione. Non esercita mai il percorso di transito, quindi può passare mentre ogni flusso inoltrato fallisce. Provi da un host di un lato a un servizio dell'altro e confermi che la risposta arrivi attraverso il tunnel. Se passa solo il ping, il registro ha appena trovato il problema di inoltro che doveva prevenire. documentazione sull'inoltro di strongSwan spiega come selettori, rotte e inoltro interagiscano su un peer Linux.