Peer IPsec in ingresso senza profilo? Controllate quattro campi

Il vostro peer segnala che il tunnel è attivo, il vostro lato non mostra alcuna associazione di sicurezza e il file di configurazione contiene chiaramente un nome di connessione corrispondente. Le tre affermazioni possono essere vere contemporaneamente. Una negoziazione in ingresso viene confrontata con la configurazione in esecuzione, usando l'indirizzo del peer, l'identità che presenta e il traffico che propone. Un file su disco mai caricato, un'identità che non corrisponde al valore atteso o una coppia di selettori sfalsata di un prefisso produrranno ciascuno un silenzio. Percorrete i quattro gruppi di campi nell'ordine seguito dal responder.

Partite dal pacchetto, non dal file

Il responder riceve una richiesta IKE, cerca una definizione che possa accettare questo peer e poi prosegue con l'autenticazione e la selezione del traffico. Se al primo passo nessuna definizione caricata corrisponde, la negoziazione termina prima che un errore utile raggiunga l'utente.

Perciò «la configurazione sembra corretta» non è una prova. La domanda è che cosa ha caricato il servizio in esecuzione e quale voce ha selezionato per questo tentativo. Un elenco di stato risponde con un solo comando, mentre il buffer dell'editor risponde a un'altra domanda. Controllate l'elenco prima di modificare di nuovo il file.

Primo gruppo di campi: la definizione realmente caricata

Controllate lo stato in esecuzione con lo strumento che possiede il demone: un comando di stato che elenca le connessioni caricate, non il buffer dell'editor. Confermate che la voce attesa sia presente, sia abilitata per il comportamento di avvio desiderato e sia stata caricata dopo la vostra ultima modifica. Un file salvato ma non ricaricato è la causa più frequente di «l'ho corretto e non è cambiato nulla».

Confermate anche quale file legge il servizio. Le distribuzioni differiscono, e una connessione scritta nell'inclusione sbagliata viene ignorata in silenzio invece di essere rifiutata. Se l'elenco di stato non mostra affatto la vostra voce, sospettate il percorso di inclusione prima della sintassi.

Secondo gruppo di campi: gli estremi non sono identità

L'indirizzo da cui il peer si connette e l'identità con cui si autentica sono campi separati. Un nome host, un nome distinto, un identificatore di chiave e un indirizzo possono tutti servire come identità IKE a seconda della configurazione, e non devono affatto somigliare all'indirizzo pubblico.

La corrispondenza degli estremi può comportare anche una vista NAT: l'indirizzo visto sulla rete può differire da quello che il peer crede di avere. Nel modello di connessioni di libreswan, left e right sono etichette dei due partecipanti e non un ordine fisso di locale e remoto, ed è per questo che copiare una configurazione funzionante da un altro sito scambiando gli indirizzi non è una traduzione affidabile.

Annotate l'identità attesa di ciascun lato e la credenziale che la convalida. Se queste due righe non concordano, nessuna quantità di ritocco degli indirizzi produrrà una corrispondenza.

Terzo gruppo di campi: il traffico protetto

I selettori descrivono gli intervalli interni di origine e destinazione, la loro famiglia di indirizzi e qualsiasi restrizione di protocollo o porta. Una proposta per l'indirizzo di un singolo host non è la stessa richiesta di una sottorete intera, e un responder configurato per la sottorete può rifiutarla o restringerla.

Quando i due estremi non concordano, confrontate il flusso previsto da entrambi i punti di vista invece di allargare ogni selettore perché qualcosa si connetta. Chiedete a ciascun amministratore quale flusso ritiene di proteggere, poi confrontate le due risposte. La discrepanza di solito è un prefisso di host da un lato e una sottorete dall'altro. Un tunnel che corrisponde perché ora protegge tutto è una decisione di sicurezza diversa, e che nessuno ha approvato.

Quarto gruppo di campi: state leggendo un'implementazione

Libreswan, il vecchio Openswan e strongSwan hanno strumenti di gestione diversi, sintassi di configurazione diversa e ordine di corrispondenza diverso. Un esempio funzionante di uno non dice nulla di preciso sulla priorità di selezione del profilo o sulla formulazione degli errori dell'altro, quindi verificate con la documentazione del demone su questo host.

Correlate un tentativo da un capo all'altro: l'indirizzo di origine dell'iniziatore, l'identità offerta e i selettori proposti, rispetto al messaggio di selezione del responder e alla voce caricata che nomina. I contatori di incapsulamento e decapsulamento a zero dicono solo che le associazioni osservate non hanno trasportato quei pacchetti; non nominano l'estremo che ha rifiutato la proposta né provano che in quel momento esistesse una voce corrispondente.

Dopo una correzione coordinata, confermate il profilo e l'associazione selezionati, poi provate il servizio effettivamente consentito e il suo percorso di risposta. Una corrispondenza di profilo abilita la negoziazione, e la negoziazione non è l'ultimo controllo di accesso.