Limiti di Cloud VPN che non si possono regolare: durata IKE e NAT del peer

Date al dispositivo remoto una durata di fase 1 di 24 ore e il tunnel Cloud VPN resta giù, anche se tutto sul lato Google è configurato correttamente. Il peer propone un valore che il responder non accetterà, quindi la negoziazione fallisce del tutto o riparte all’infinito. Cloud VPN limita la fase 1 a 36,000 secondi, dieci ore, e questo tetto non è un’impostazione che potete alzare. La modifica appartiene al dispositivo remoto.

Il peer chiede, il responder decide

IKE è un esercizio di abbinamento tra due insiemi di proposte. Il tunnel si forma solo dove gli insiemi si sovrappongono entro i limiti che il responder accetta, ed è per questo che una durata fuori intervallo non produce alcun tunnel parziale. L’errore abituale è trattare la configurazione del peer come una lista dei desideri invece che come una proposta. Un’intersezione vuota lascia il tunnel giù, per quanto corretti siano l’instradamento e i selettori.

Leggete lo stato del tunnel stesso prima di aprire un caso, perché lo stato dettagliato di solito nomina la fase che ha fallito:

gcloud compute vpn-tunnels describe office-tunnel \
  --region europe-west1 \
  --format="value(status,detailedStatus)"

Confrontate ciò che torna con l’insieme supportato per il vostro tipo di gateway e la vostra versione IKE, e annotate entrambi i selettori di traffico mentre siete lì. Una discrepanza di selettore dà lo stesso sintomo di tunnel giù di una discrepanza di algoritmo, e a differenza dell’algoritmo questa tocca a voi.

36,000 secondi è il tetto

La fase 1 si ferma a 36,000 secondi. Un dispositivo impostato a 86,400 chiede qualcosa che il responder non accetterà mai, e riprovare non gli cambia idea. Riportate la proposta remota dentro l’intervallo e la stessa configurazione si stabilisce; l’asimmetria è tutta la lezione, perché potete abbassare il vostro valore e non potete alzare quello di Google.

Scrivete il valore scelto nelle note di progettazione. Altrimenti l’ingegnere successivo ripete l’esperimento delle 24 ore e sbatte contro lo stesso muro.

L’insieme supportato è pubblicato per tipo di gateway e versione IKE nella panoramica di Cloud VPN, quindi leggete la sezione per la vostra topologia invece di una guida IKE generica.

Un tunnel che cade secondo un orario

La fase 2 si comporta diversamente: quando i due estremi non sono d’accordo, il rinnovo delle chiavi segue l’intervallo più breve. Un peer che tratta la discrepanza come fatale fa cadere il tunnel, così una discrepanza può sembrare due guasti non correlati. Guardate il ritmo di rinnovo delle chiavi, non solo la prima connessione. Un tunnel che sale e poi cade con un battito regolare è più spesso una discrepanza di durata che un difetto di instradamento.

Correlate quelle marche temporali di caduta con i log del peer stesso prima di modificare qualsiasi cosa, perché un cambio di selettore o di rotta può imitare lo stesso ritmo. Se il battito coincide con il timer della fase 2, la causa è trovata senza toccare una proposta.

Le suite vengono dal tipo di gateway

Le suite di cifratura e integrità non sono un profilo per tunnel che modificate come consente strongSwan. Le scegliete per tipo di gateway e versione IKE, e cercare un profilo che non esiste spreca un pomeriggio.

Un dispositivo vecchio che non offre nulla dentro l’insieme supportato lascia due strade oneste: sostituire il dispositivo, oppure terminare su un gateway software che controllate e instradare da lì nella VPC. Qualunque altra cosa è un giro che fallirà la prossima revisione.

Un indirizzo esterno per dispositivo

L’indirizzo esterno del peer deve corrispondere uno-a-uno al suo indirizzo interno. Un pool PAT sovraccarico non può funzionare, perché più host dietro un solo indirizzo pubblico non danno al responder alcun modo di demultiplessarli. Dove più host devono condividere un indirizzo, il tunnel deve terminare in un punto che possa distinguerli.

Mantenete stabile anche quell’indirizzo esterno. Spostate il dispositivo dietro un altro NAT e l’associazione si rompe anche se ogni proposta corrisponde ancora. Vale la pena annotare quali valori sono di Google e quali vostri: durate, suite e NAT uno-a-uno sono fissi dalla loro parte, mentre proposte, selettori, instradamento e priorità BGP sono vostri.