Cloud VPN-perke wat jy nie kan verstel nie: IKE-leeftyd en eweknie-NAT

Gee die afgeleë toestel 'n 24-uur fase-1-leeftyd en die Cloud VPN-tonnel bly af, selfs al is alles aan die Google-kant korrek opgestel. Die eweknie stel 'n waarde voor wat die responder nie sal aanvaar nie, so die onderhandeling misluk heeltemal of herbegin onbepaald. Cloud VPN beperk fase 1 tot 36,000 sekondes, tien uur, en daardie perk is nie 'n instelling wat jy kan verhoog nie. Die verandering hoort op die afgeleë toestel.

Die eweknie vra, die responder besluit

IKE is 'n passingsoefening tussen twee stelle voorstelle. Die tonnel vorm net waar die stelle oorvleuel binne die grense wat die responder aanvaar, en daarom lewer 'n leeftyd buite die bereik glad geen gedeeltelike tonnel nie. Om die eweknie se opstelling as 'n wenslys eerder as as 'n voorstel te behandel, is die gewone fout. 'n Leë snyding laat die tonnel af bly, hoe korrek die roetering en die selektors ook al is.

Lees die tonnel se eie toestand voordat jy 'n saak oopmaak, want die gedetailleerde status noem gewoonlik die fase wat gefaal het:

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

Vergelyk wat terugkom met die ondersteunde stel vir jou poorttipe en IKE-weergawe, en teken albei verkeerselektors daar op. 'n Selektor-wanpassing gee dieselfde af-tonnel-simptoom as 'n algoritme-wanpassing, en anders as die algoritme is daardie een joune om reg te maak.

36,000 sekondes is die plafon

Fase 1 stop by 36,000 sekondes. 'n Toestel wat op 86,400 gestel is, vra iets wat die responder nooit sal aanvaar nie, en herprobeer verander nie sy mening nie. Draai die afgeleë voorstel terug binne die reeks en dieselfde opstelling vestig; die asimmetrie is die hele les, want jy mag jou eie waarde verlaag en kan nie Google s'n verhoog nie.

Skryf die gekose waarde in die ontwerpnotas. Anders herhaal die volgende ingenieur die 24-uur-eksperiment en tref dieselfde muur.

Die ondersteunde stel word per poorttipe en IKE-weergawe gepubliseer in die Cloud VPN-oorsig, so lees die afdeling vir jou topologie eerder as 'n algemene IKE-gids.

'n Tonnel wat volgens 'n skedule val

Fase 2 werk anders: wanneer die twee kante verskil, volg die hernuwing van sleutels die korter interval. 'n Eweknie wat die wanpassing as fataal beskou, laat die tonnel eerder val, so een wanpassing kan soos twee onverwante foute lyk. Let op die ritme van sleutelhernuwing, nie net die eerste verbinding nie. 'n Tonnel wat opkom en dan op 'n gereelde maat omval, is meer dikwels 'n leeftyd-wanpassing as 'n roeteringsdefek.

Korreleer daardie val-tydstempels met die eweknie se eie logs voordat jy iets wysig, want 'n selektor- of roeteverandering kan dieselfde ritme naboots. As die maat by die fase 2-tydhouer pas, is die oorsaak gevind sonder om 'n voorstel aan te raak.

Suites kom van die poorttipe

Sifer- en integriteitsuites is nie 'n profiel per tonnel wat jy wysig soos strongSwan jou toelaat nie. Jy kies hulle per poorttipe en IKE-weergawe, en om te soek vir 'n profiel wat nie bestaan nie, mors 'n middag.

'n Erfenistoestel wat niks binne die ondersteunde stel bied nie, laat twee eerlike weë: vervang die toestel, of termineer op 'n sagteware-poort wat jy beheer en roeteer van daar af in die VPC in. Enigiets anders is 'n ompad wat die volgende hersiening faal.

Een eksterne adres per toestel

Die eweknie se eksterne adres moet een-tot-een op sy interne adres karteer. 'n Oorlaaide PAT-poel kan nie werk nie, want verskeie gashere agter 'n enkele publieke adres gee die responder geen manier om hulle te demultiplekseer nie. Waar verskeie gashere 'n adres moet deel, moet die tonnel eindig op 'n plek wat hulle kan onderskei.

Hou daardie eksterne adres ook stabiel. Skuif die toestel agter 'n ander NAT en die assosiasie breek selfs al pas elke voorstel nog. Watter waardes Google s'n is en watter joune is, is die moeite werd om neer te skryf: leeftye, suites en een-tot-een NAT is aan hulle kant vas, terwyl voorstelle, selektors, roetering en BGP-prioriteite joune is.