Cloud VPN till Cisco ASA: bygg om efter ett avvikande förslag

Cloud VPN bakar in förslaget i tunnelobjektet, så avvikelse mot ASA:n innebär ombyggnad. Notera selectors, passa ihop båda faserna, rensa gamla SA.

NEGOTIATION_FAILURE på en Cloud VPN-tunnel med en Cisco ASA i andra änden är nästan alltid en oenighet om förslaget eller om selectors, och det första användbara faktumet är att ingen redigering rättar det. Cloud VPN låser IKE-förslaget när tunnelobjektet skapas. Det finns inget fält för att byta algoritm på plats, så reparationen är en borttagning och en återskapning med en noterad utgångspunkt. Behandla det som en ombyggnad och arbetet blir en checklista i stället för en eftermiddag av gissningar.

Läs felet innan du tar bort något

Ett förhandlingsfel är ett fasproblem, och peer-loggen namnger oftast fasen. Fas 1 som misslyckas betyder att ändarna inte kunde enas om ett förslag eller inte kunde autentisera varandra. Fas 2 som misslyckas betyder att tunneln kom upp och att de skyddade selectors inte stämde. Det är olika reparationer, och loggrader är värd att plocka ut innan någon rör en konfiguration.

Felet utesluter också saker. Det är inte en VPC-route, inte en brandväggsregel på tunnelgränssnittet och inte ett namnmatchningfel inne i nätet. Att jaga dem ger självsäkra ändringar som inte kan påverka resultatet, och de gör den slutliga rättelsen svårare att tillskriva.

Fånga båda konfigurationerna medan de finns kvar

Att ta bort en tunnel tar en halv minut och förstör det enda bevis du hade. Skriv först ned de lokala och avlägsna selectors, peer-adressen, vem som äger den delade hemligheten och ASA:ns crypto map eller IKEv2-profil. ASA:n svarar på två separata frågor: vad som är konfigurerat och vad som är uppe just nu:

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

På Google-sidan, läs tunnelobjektet i stället för konsolsammanfattningen, eftersom peer-adressen och selector-fälten är de värden du måste återge exakt:

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

Sätt in dessa värden i ärendet före den första borttagningen. Ombyggnaden nedan fungerar bara för att du kan återskapa samma objekt med en enda avsiktlig skillnad.

Algoritmerna som ena sidan vägrar förhandla om

Cloud VPN väljer inte från en rad IKEv1-algoritmer som en traditionell peer gör. Peer-inställningarna den förväntar sig är fasta: aes-cbc-128 för kryptering, sha1-96 för både integritet och PRF, Diffie-Hellman-grupp 2, 36,600 sekunder för fas 1 och 10,800 sekunder för fas 2. ASA-policyn måste erbjuda exakt den uppsättningen. Ett extra förslag på ASA:n skadar inte så länge det matchande också står i listan.

IKEv2 ger båda sidor mer utrymme, men reglerna behåller samma form: slå på PFS, välj en DH-grupp som tunneln stöder och håll förslagslistan kort nog för att en avvikelse ska vara uppenbar. En ASA-peer på Cloud VPN innebär också statisk routing, så de skyddade prefixen måste planeras och listas i stället för att lämnas till BGP.

En livstid kopierad från en annan leverantörs mall är den vanliga felaktiga svängen här. Google publicerar dessa värden som obligatoriska peer-inställningar, så sätt dem; ett kortare värde förhandlas inte upp till det ASA:n vill ha.

Ta bort, återskapa och rensa det gamla tillståndet

Ta bort tunneln, inte gatewayen, och notera namnet som Cloud VPN ger ersättaren, eftersom namn tilldelas och inte återanvänds. Återskapa den med de noterade värdena och samma peer-adress, och lägg sedan till det matchande förslaget i ASA:ns policylista.

Rensa säkerhetsassociationerna efter ändringen på ASA:n och innan du läser resultatet. En ASA kan fortsätta erbjuda en inaktuell policy tills den aktuella SA löper ut, så en korrekt konfiguration ser trasig ut under hela den gamla livstiden och den som övervakar drar slutsatsen att ombyggnaden misslyckades när den inte hade börjat:

clear crypto ikev2 sa
clear crypto ipsec sa

Bekräfta att fas 1 kommer upp innan du tittar på fas 2. Medan fas 1 är nere är förslaget eller den fördelade nyckeln fel, och selector-arbete ändrar inte det.

Selectors speglar, sedan avgör räknarna

Fas 2 fungerar bara när båda ändarna är överens om adresserna som skyddas, och enigheten är speglad, inte delad. Googles lokala selector måste matcha selectorn som ASA:n kallar avlägsen, och Googles avlägsna selector det som ASA:n kallar lokal. En tunnel med 0.0.0.0/0 på ena sidan och ett enda subnät på den andra passerar fas 1 och misslyckas sedan i fas 2 med samma huvudfel. Ingen sida kan utöka den andras lista.

För policybaserade selectors, lista varje prefixpar och håll listan i ärendet. Ett subnät som läggs till lokalt senare kräver en ändring i båda ändar, eftersom en ny route på ASA:n inte utökar en selector, och resultatet är en tunnel som är uppe och bara släpper igenom trafik för prefixen som fanns den första dagen.

Avsluta med ett enda flöde från värd till värd och läs byteräknarna på båda sidor. Räknare som stiger på ASA:n och står stilla på Google betyder oftast att svaret går ut genom ett annat gränssnitt, eller att selectorn inte täcker returprefixet. Notera algoritmerna, livstiderna, selectors och det nya tunnelnammet, eftersom nästa förslagsändring upprepar denna ombyggnad och de värdena gör den till en kort uppgift.

Relaterade artiklar