Profilo WireGuard per un gateway IPsec: cosa chiedere invece

I timeout dell'handshake con un gateway silenzioso di solito significano due protocolli che non si incontrano mai. Un peer WireGuard parla Noise mentre un gateway IPsec attende IKE. Indirizzo e porta corretti non cambiano questo.

Riusare l'endpoint in un profilo non collega i due. Il passo successivo è una richiesta a chi gestisce il gateway.

Prima richiesta: la versione del protocollo

IPsec indica una famiglia e non un unico flusso di lavoro. IKEv2 e IKEv1 differiscono nei loro scambi, nelle opzioni di autenticazione e nel comportamento durante un cambio di rete. Un gateway che termina solo IKEv1 si comporterà in modo molto diverso da uno che offre IKEv2. La configurazione del client cambia di conseguenza.

Chiedete quale versione termina il servizio e se esegue un'implementazione basata su standard o una variante del fornitore con un client proprio. I menu dei sistemi operativi spesso nascondono quella risposta dietro una sola etichetta. L'etichetta non è il protocollo.

Seconda richiesta: il metodo di autenticazione del client

L'autenticazione è dove si trova la maggior parte del lavoro reale. Il servizio può attendersi un certificato macchina con un uso esteso della chiave particolare, un certificato utente, un metodo EAP su IKEv2 o una chiave precondivisa legata a un'identità. Quale si applica decide di cosa ha bisogno il client.

Una chiave privata WireGuard non è nessuna di queste cose. È una chiave Curve25519 usata in un handshake specifico. Nessuna conversione la trasforma in un certificato o in una credenziale EAP. Uno strumento che afferma il contrario sta rinominando il file o generando qualcosa di non correlato.

La specifica di IKEv2 nell'RFC 7296 descrive cosa deve supportare un'implementazione di quella versione. È un riferimento per una risposta vaga dell'operatore, non una guida alla configurazione del client.

Terza richiesta: l'identità attendibile e le destinazioni

Chiedete l'identità del gateway come il client deve vederla, più l'ancora di fiducia che la convalida. Poi chiedete quali intervalli privati e resolver il servizio spinge. Quelle due risposte decidono cosa trasporta davvero il tunnel.

Senza di esse una connessione funzionante può comunque fallire il compito. Un tunnel attivo senza resolver spinto lascia i nomi interni senza risposta. Un selettore di traffico mancante lascia la destinazione fuori dal tunnel anche se l'handshake è riuscito.

Una sonda dell'endpoint risponde a una domanda diversa dall'errore del client. Una porta raggiungibile senza associazione indica l'autenticazione, mentre una porta irraggiungibile indica il percorso.

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

Eseguite quella sonda prima di cambiare qualsiasi cosa nel client. Se le porte rispondono e l'associazione continua a fallire, il problema sono le credenziali o la policy. Se non rispondono affatto, nessuna modifica al profilo aiuterà.

Quando entrambi i protocolli devono coesistere

Amministrare entrambe le reti è un motivo legittimo per mantenere entrambi i protocolli. Il progetto abituale termina WireGuard e IPsec su interfacce separate o gateway separati. Il traffico approvato viene poi instradato tra di essi.

Quel progetto introduce un confine di fiducia e autorizzazione, e dovrebbe essere annotato come tale. Quali peer possono attraversare, in quale direzione e sotto la policy di chi è una decisione di routing e firewall. Nessuno dei due protocolli la fornisce.

Ciò che non è è una conversione trasparente. Il traffico che arriva tramite WireGuard viene rioriginato nel tunnel IPsec, e ogni policy intermedia si applica ad esso.

Chiarite prima i requisiti di protocollo e autenticazione del server. Poi usate il client e il percorso di registrazione supportati dall'operatore, e tenete le chiavi private fuori dai convertitori web mentre accade.