Passaggi dell’handshake VPN: cosa succede prima che il traffico scorra

Premere Connetti avvia quattro attività separate che riescono o falliscono in modo indipendente. Il client deve raggiungere un ascoltatore, concordare chi è il peer, derivare le chiavi e poi consegnare un tunnel funzionante al resto del sistema. La maggior parte delle connessioni fallite viene diagnosticata nell’attività sbagliata. Per questo il primo errore conta più del terzo tentativo.

Raggiungete prima l’ascoltatore

Prima che venga scambiata qualsiasi identità, il client risolve un nome, sceglie una rotta e apre un trasporto verso una porta. Un portale captive che risponde a tutto, una porta chiusa e un nome host errato falliscono tutti qui, e nessuno dei tre è un problema di autenticazione. Cambiare una password non può correggere nessuno dei tre. Leggete la prima riga dell’errore prima di toccare le credenziali.

Un timeout, il rifiuto di un certificato e un account rifiutato sono tre guasti diversi con tre controlli diversi. Classificarli per primi è ciò che impedisce a un problema di rete di essere sottoposto a debug come problema di credenziali.

Dimostrate il peer, poi derivate le chiavi

Ogni protocollo ha bisogno di un modo per riconoscere il server previsto, tramite una chiave pubblica configurata o una catena di certificati. L’accesso utente si aggiunge a quel controllo, non lo sostituisce. Un server che accetta la vostra password non ha dimostrato nulla sulla propria identità. Per questo un segreto condiviso digitato in un client non sostituisce la verifica di chi ha risposto.

Lo scambio deriva poi le chiavi di traffico dagli input del protocollo stesso, e la password di accesso generalmente non è la chiave impressa su ogni pacchetto. Il materiale identitario a lungo termine e le chiavi di sessione a breve termine hanno durate e compiti diversi. È di questa separazione che parla la segretezza in avanti.

Tenete attiva la verifica durante la risoluzione dei problemi, perché un tunnel che si connette dopo che avete disattivato un controllo non ha dimostrato altro se non che il controllo faceva qualcosa. Annotate cosa avete cambiato e rimettetelo prima del test successivo.

Tre protocolli, tre conversazioni

In un’implementazione OpenVPN basata su TLS il canale di controllo negozia i parametri di sicurezza mentre il canale dati trasporta il traffico del tunnel, quindi un’opzione del canale dati e un problema di certificato vivono in posti diversi. IKEv2 autentica entrambi i partecipanti e poi stabilisce associazioni di sicurezza IPsec con durate proprie. WireGuard deriva le chiavi tramite il suo scambio basato su Noise e mantiene la macchina a stati deliberatamente piccola. Sapere quale dei tre eseguite decide quale registro vale la pena leggere.

Client dall’aspetto simile non implicano messaggi intercambiabili sotto, e un campo di configurazione che esiste in un prodotto può non avere equivalente in un altro. Copiare un profilo tra loro è una supposizione e non una migrazione.

Cosa non fa l’handshake

Rotte, risoluzione dei nomi e politica di destinazione restano tutte dopo. Un sito interno può rimanere irraggiungibile perché manca la rotta della sua sottorete, anche se il peer è stato autenticato correttamente e il tunnel è attivo. Trattarlo come cifratura debole vi manda a cercare nello strato sbagliato, e di solito finisce con un cambio di cifratura che non corregge nulla.

Il rinnovo delle chiavi e la riconnessione si somigliano anche nella maggior parte delle schermate di stato, e nessuno dei due vi dice se il traffico ordinario è stato bloccato durante l’interruzione. Solo la politica di errore del client risponde a quella domanda, quindi leggete la politica e non l’icona.

Lavorate le fasi nell’ordine sopra e fermatevi alla prima che produce un errore. Ogni fase successiva eredita lo stato delle precedenti, quindi un guasto alla terza fase non dice nulla sulla quarta.

ip -brief address show tun0
ip route get 10.60.7.15
resolvectl query intranet.corp.internal