Límits de Cloud VPN que no es poden ajustar: vida útil d'IKE i NAT del peer
Cloud VPN negocia les vides útils d'IKE dins de límits fixos i necessita NAT un-a-un al peer. Planifiqueu el dispositiu remot segons això, no segons el costat de Google.
Doneu al dispositiu remot una vida útil de fase 1 de 24 hores i el túnel de Cloud VPN es queda caigut, encara que tot al costat de Google estigui ben configurat. El peer proposa un valor que el responedor no acceptarà, així que la negociació o falla del tot o es reinicia indefinidament. Cloud VPN limita la fase 1 a 36,000 segons, deu hores, i aquest límit no és un paràmetre que pugueu apujar. El canvi correspon al dispositiu remot.
El peer pregunta, el responedor decideix
IKE és un exercici d'encaix entre dos conjunts de propostes. El túnel només es forma on els conjunts se superposen dins dels límits que el responedor accepta, i per això una vida útil fora de rang no produeix cap túnel parcial. L'error habitual és tractar la configuració del peer com una llista de desitjos i no com una proposta. Una intersecció buida deixa el túnel caigut per correctes que siguin l'encaminament i els selectors.
Llegiu l'estat propi del túnel abans d'obrir un cas, perquè l'estat detallat normalment indica l'etapa que ha fallat:
gcloud compute vpn-tunnels describe office-tunnel \
--region europe-west1 \
--format="value(status,detailedStatus)"
Compareu el que torna amb el conjunt admès per al vostre tipus de passarel·la i versió d'IKE, i anoteu tots dos selectors de trànsit mentre hi sou. Una discrepància de selector dóna el mateix símptoma de túnel caigut que una discrepància d'algorisme, i a diferència de l'algorisme aquesta us toca a vosaltres.
36,000 segons és el sostre
La fase 1 s'atura als 36,000 segons. Un dispositiu configurat a 86,400 demana una cosa que el responedor no acceptarà mai, i reintentar-ho no li canvia el parer. Torneu la proposta remota dins del rang i la mateixa configuració s'estableix; l'asimetria és tota la lliçó, perquè podeu baixar el vostre valor i no podeu apujar el de Google.
Escriviu el valor triat a les notes de disseny. Si no, el següent enginyer repeteix l'experiment de 24 hores i arriba a la mateixa paret.
El conjunt admès es publica per tipus de passarel·la i versió d'IKE a la visió general de Cloud VPN, així que llegiu la secció de la vostra topologia en lloc d'una guia general d'IKE.
Un túnel que cau segons un horari
La fase 2 es comporta diferent: quan els dos extrems no es posen d'acord, la renovació de claus segueix l'interval més curt. Un peer que tracta la discrepància com a fatal fa caure el túnel, així que una discrepància pot semblar dos defectes no relacionats. Mireu el ritme de renovació de claus, no només la primera connexió. Un túnel que puja i després cau amb un compàs regular sol ser una discrepància de vida útil més que un defecte d'encaminament.
Correlacioneu aquelles marques de temps de caiguda amb els registres propis del peer abans de tocar res, perquè un canvi de selector o de ruta pot imitar el mateix ritme. Si el compàs coincideix amb el temporitzador de la fase 2, la causa és trobada sense tocar cap proposta.
Els conjunts venen del tipus de passarel·la
Els conjunts de xifratge i integritat no són un perfil per túnel que editeu com us permet strongSwan. Els trieu per tipus de passarel·la i versió d'IKE, i buscar un perfil que no existeix malbarata una tarda.
Un dispositiu antic que no ofereix res dins del conjunt admès deixa dos camins honestos: substituir el dispositiu o acabar en una passarel·la de programari que controleu i encaminar cap a la VPC des d'allà. Qualsevol altra cosa és una solució improvisada que fallarà la propera revisió.
Una adreça externa per dispositiu
L'adreça externa del peer ha de correspondre un-a-un amb la seva adreça interna. Un pool de PAT sobrecarregat no pot funcionar, perquè diversos amfitrions darrere d'una sola adreça pública no donen al responedor cap manera de desmultiplexar-los. On diversos amfitrions han de compartir una adreça, el túnel ha d'acabar en un lloc que els pugui distingir.
Manteniu també estable aquesta adreça externa. Moveu el dispositiu darrere d'un altre NAT i l'associació es trenca encara que cada proposta continuï encaixant. Val la pena anotar quins valors són de Google i quins són vostres: les vides útils, els conjunts i el NAT un-a-un són fixos al seu costat, mentre que les propostes, els selectors, l'encaminament i les prioritats BGP són vostres.