Cloud VPN verso Cisco ASA: ricostruire dopo una discrepanza di proposta

NEGOTIATION_FAILURE su un tunnel Cloud VPN con un Cisco ASA all'altro capo è quasi sempre una discrepanza di proposta o di selettori, e il primo fatto utile è che nessuna modifica lo risolverà. Cloud VPN fissa la proposta IKE quando viene creato l'oggetto del tunnel. Non c'è alcun campo per cambiare un algoritmo sul posto, quindi la riparazione è una cancellazione e una ricreazione con un punto di partenza annotato. Trattala come una ricostruzione e il lavoro diventa una lista di controllo invece di un pomeriggio di supposizioni.

Leggi l'errore prima di cancellare qualsiasi cosa

Un errore di negoziazione è un problema di fase, e il registro del peer di solito nomina la fase. Un errore della fase 1 significa che gli estremi non sono riusciti a concordare una proposta o non hanno potuto autenticarsi. Un errore della fase 2 significa che il tunnel è salito e i selettori protetti non coincidevano. Sono riparazioni diverse, e vale la pena estrarre la riga di registro prima che qualcuno tocchi una configurazione.

L'errore esclude anche alcune cose. Non è una route VPC, non è una regola del firewall sull'interfaccia del tunnel e non è un guasto di risoluzione dei nomi dentro la rete. Inseguirle produce modifiche sicure di sé che non possono cambiare l'esito, e rendono la correzione finale più difficile da attribuire.

Cattura entrambe le configurazioni finché esistono

Cancellare un tunnel richiede mezzo minuto e distrugge l'unica prova che avevi. Prima, annota i selettori locale e remoto, l'indirizzo del peer, chi possiede il segreto condiviso e la crypto map o il profilo IKEv2 dell'ASA. L'ASA risponde a due domande separate: che cosa è configurato e che cosa è attivo adesso:

show running-config crypto ikev2
show crypto ikev2 sa
show crypto ipsec sa | include local ident|remote ident|status

Sul lato Google leggi l'oggetto del tunnel invece del riepilogo della console, perché l'indirizzo del peer e i campi dei selettori sono i valori che devi riprodurre esattamente:

gcloud compute vpn-tunnels describe tunnel-to-asa --region europe-west1 \
  --format="yaml(peerIp,localTrafficSelector,remoteTrafficSelector,ikeVersion,sharedSecret)"

Metti quei valori nel ticket prima della prima cancellazione. La ricostruzione qui sotto funziona solo perché puoi ricreare lo stesso oggetto con una differenza deliberata.

Gli algoritmi su cui un lato rifiuta di negoziare

Cloud VPN non sceglie da una gamma di algoritmi IKEv1 come fa un peer tradizionale. Le impostazioni del peer che si aspetta sono fisse: aes-cbc-128 per la crittografia, sha1-96 sia per l'integrità sia per il PRF, gruppo Diffie-Hellman 2, 36,600 secondi per la fase 1 e 10,800 secondi per la fase 2. La politica dell'ASA deve offrire esattamente questo insieme. Una seconda proposta sull'ASA non fa male purché quella corrispondente sia anch'essa nell'elenco.

IKEv2 dà più margine a entrambi i lati, ma le regole mantengono la stessa forma: abilita PFS, scegli un gruppo DH supportato dal tunnel e mantieni l'elenco delle proposte abbastanza corto da rendere evidente una discrepanza. Un peer ASA su Cloud VPN implica anche routing statico, quindi i prefissi protetti vanno pianificati ed elencati invece di lasciarli a BGP.

Una durata copiata dal modello di un altro fornitore è la deviazione sbagliata abituale qui. Google pubblica questi valori come impostazioni obbligatorie del peer, quindi impostali; un valore più corto non viene negoziato verso l'alto fino a ciò che vuole l'ASA.

Cancella, ricrea e pulisci lo stato vecchio

Cancella il tunnel, non il gateway, e annota il nome che Cloud VPN assegna al sostituto, perché i nomi vengono assegnati e non riutilizzati. Ricrealo con i valori annotati e lo stesso indirizzo del peer, poi aggiungi la proposta corrispondente all'elenco delle politiche dell'ASA.

Pulisci le associazioni di sicurezza dopo la modifica sull'ASA e prima di leggere il risultato. Un ASA può continuare a offrire una politica obsoleta finché la SA corrente non scade, quindi una configurazione corretta sembra rotta per tutta la durata della vecchia durata e l'osservatore conclude che la ricostruzione è fallita quando non era ancora iniziata:

clear crypto ikev2 sa
clear crypto ipsec sa

Verifica che la fase 1 salga prima di guardare la fase 2. Finché la fase 1 è giù, la proposta o la chiave precondivisa sono sbagliate, e il lavoro sui selettori non lo cambierà.

I selettori si rispecchiano, poi decidono i contatori

La fase 2 funziona solo quando entrambi gli estremi concordano sugli indirizzi protetti, e l'accordo è a specchio e non condiviso. Il selettore locale di Google deve corrispondere al selettore che l'ASA chiama remoto, e il selettore remoto di Google a ciò che l'ASA chiama locale. Un tunnel con 0.0.0.0/0 su un lato e una sola sottorete sull'altro supera la fase 1 e poi fallisce la fase 2 con lo stesso errore principale. Nessun lato può allargare l'elenco dell'altro.

Per i selettori basati su politiche, elenca ogni coppia di prefissi e conserva l'elenco nel ticket. Una sottorete aggiunta in sede più tardi richiede una modifica su entrambi gli estremi, perché una nuova route sull'ASA non allarga un selettore, e il risultato è un tunnel attivo che passa traffico solo per i prefissi esistenti il primo giorno.

Chiudi con un solo flusso da host a host e leggi i contatori di byte su entrambi i lati. Contatori che salgono sull'ASA mentre restano piatti su Google di solito significano che la risposta esce da un'altra interfaccia, o che il selettore non copre il prefisso di ritorno. Annota gli algoritmi, le durate, i selettori e il nuovo nome del tunnel, perché il prossimo cambio di proposta ripete questa ricostruzione e quei valori la rendono un lavoro breve.