Check Point VSX VPN: selezione del collegamento o disallineamento del peer?

Due modifiche diverse producono lo stesso sintomo quando un tunnel site-to-site di Check Point smette di alzarsi: il peer vede un indirizzo esterno diverso, oppure rifiuta l'identità IKE che ora riceve. Su una cattura presa da un solo lato, le due cose sembrano identiche. Per stabilire quale delle due avete servono tre verifiche, e nessuna di esse è il pannello di selezione del collegamento.

Se sbagliate l'ordine, regolate la selezione dell'origine per correggere un disallineamento dell'identità. È così che lo stesso tunnel viene riparato due volte e si rompe di nuovo dopo il successivo cambio di rotta.

Tre condizioni che separano i due casi

Prima condizione: l'endpoint configurato del peer corrisponde all'indirizzo che arriva davvero? Se i pacchetti raggiungono il gateway remoto da un indirizzo che esso non associa al vostro oggetto peer, la negoziazione fallisce prima che venga scambiata qualsiasi identità. Seconda condizione: l'identità IKE nella proposta corrisponde al valore atteso dal peer? Quella è autenticazione, non trasporto. Terza condizione: l'opzione che volete cambiare è supportata per questo sistema virtuale su questa release? Nessuna impostazione visibile risponde a queste domande.

Se fallisce la prima condizione, avete un problema di routing o di traduzione. Se fallisce la seconda, avete un problema di contratto con il peer. Se la terza è sconosciuta, smettete di configurare.

Costruite prima il registro del peer esterno

Annotate il sistema virtuale, la release del software e il livello di aggiornamento installato prima di toccare qualsiasi cosa. Poi registrate le interfacce esterne, la rotta verso il peer remoto, gli indirizzi di origine attesi prima e dopo il NAT e l'endpoint configurato del peer remoto.

Tenete i prefissi protetti interni in una parte separata di quel registro. Cambiare un'origine esterna e cambiare un indirizzo LAN protetto sono operazioni diverse che per caso vivono nella stessa policy.

Aggiungete la direzione a ogni cattura che conservate. Una negoziazione avviata localmente e una risposta al peer remoto possono selezionare in modo diverso, quindi una cattura senza etichetta è una prova debole. Etichettate il file con il sistema virtuale e l'iniziatore.

Leggete che cosa separa davvero la selezione del collegamento

La guida di Check Point alla selezione del collegamento in R81.20 separa tre cose che le persone fondono in una: come il peer remoto risolve l'indirizzo di un gateway, quale rotta trasporta il traffico in uscita e quale IP di origine viene usato. Ognuna risponde a una domanda diversa. Nessuna di esse cambia l'identità che il peer autentica.

Quella separazione spiega perché un cambio di rotta può alterare l'indirizzo esterno visibile senza toccare l'identità IKE, e perché un cambio di identità può rompere un tunnel il cui routing è perfetto.

La RFC 7296 traccia la stessa linea per IKE stesso: il payload di identificazione non è l'indirizzo di trasporto. I fornitori implementano questa separazione, non la ridefiniscono.

Decidete con le prove, non con il pannello delle impostazioni

Se il peer segnala un'identità sconosciuta o non corrispondente, correggete l'oggetto peer o la configurazione dell'identità, non la selezione dell'origine. Se il peer non segnala nulla e la vostra cattura mostra pacchetti in uscita da un indirizzo inatteso, correggete prima il routing o la traduzione. Se entrambi sembrano corretti e il tunnel continua a fallire, catturate sul lato remoto e confrontate che cosa ha ricevuto. Solo quando indirizzo e identità concordano e il percorso è ancora sbagliato, un'opzione di selezione del collegamento diventa candidata.

Prima di configurare quell'opzione su VSX, procuratevi le indicazioni sulle funzioni supportate della release corrispondente o una dichiarazione esplicita del fornitore per il contesto del sistema virtuale. Un vecchio rapporto secondo cui una funzione non era disponibile è storia, non un divieto attuale, e un pannello di impostazioni non è una dichiarazione di supporto.

Riconciliate le due estremità e conservate il registro

Una volta che avete un progetto supportato, riesaminate insieme la raggiungibilità esterna, la configurazione dell'endpoint del peer e l'accordo sull'identità, come un unico contratto. Poi pianificate il collaudo per tre casi: la connessione iniziale, la connessione avviata dal lato remoto e il guasto che vi aspettate quando il percorso si interrompe.

Salvate gli indirizzi esterni osservati accanto al contesto del sistema virtuale attivo. Il prossimo cambio di rotta si confronterà così con un contratto documentato invece che con la memoria che qualcuno ha del valore predefinito.