Mga limitasyon ng Cloud VPN na hindi maaaring i-tune: ang IKE lifetime at peer NAT

Bigyan ang remote na aparato ng 24-oras na lifetime ng phase 1 at mananatiling down ang Cloud VPN tunnel, kahit tama ang lahat ng configuration sa panig ng Google. Isang halaga ang ipinapanukala ng peer na hindi tatanggapin ng responder, kaya mabibigo nang tuluyan ang negosasyon o paulit-ulit na magsisimula. Nililimitahan ng Cloud VPN ang phase 1 sa 36,000 segundo, sampung oras, at ang hangganang iyon ay hindi setting na maaaring itaas. Ang pagbabago ay dapat sa remote na aparato.

Nagtatanong ang peer, nagpapasya ang responder

Ang IKE ay pagsasanay sa pagtutugma ng dalawang set ng panukala. Nabubuo lamang ang tunnel sa bahaging nagsasapawan ang mga set sa loob ng hangganang tinatanggap ng responder, kaya ang lifetime na wala sa saklaw ay walang nabubuong bahagyang tunnel. Ang karaniwang pagkakamali ay ituring ang configuration ng peer na listahan ng hiling at hindi panukala. Ang walang laman na intersection ay nag-iiwan ng tunnel na down, gaano man katama ang routing at mga selector.

Basahin ang sariling estado ng tunnel bago magbukas ng kaso, dahil karaniwang tinutukoy ng detalyadong estado ang phase na bigo:

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

Ihambing ang bumabalik sa sinusuportahang set para sa uri ng gateway at bersyon ng IKE, at itala ang dalawang traffic selector habang naroon ka. Ang mismatch ng selector ay nagbibigay ng parehong sintomas ng down na tunnel tulad ng mismatch ng algorithm, at hindi tulad ng algorithm, ito ay ikaw ang dapat mag-ayos.

36,000 segundo ang pinakamataas

Humihinto ang phase 1 sa 36,000 segundo. Ang aparatong nakatakda sa 86,400 ay humihiling ng bagay na hindi kailanman papayagan ng responder, at hindi binabago ng pag-uulit ang isip nito. Ibalik ang remote na panukala sa loob ng saklaw at mabubuo ang parehong configuration; ang asimetriya ang buong aral, dahil maaari mong ibaba ang sarili mong halaga ngunit hindi mo maaaring itaas ang sa Google.

Isulat ang piniling halaga sa mga tala ng disenyo. Kung hindi, uulitin ng susunod na inhinyero ang 24-oras na eksperimento at matatamaan ang parehong pader.

Inilalathala ang sinusuportahang set ayon sa uri ng gateway at bersyon ng IKE sa pangkalahatang-ideya ng Cloud VPN, kaya basahin ang seksyon para sa iyong topolohiya sa halip na pangkalahatang gabay sa IKE.

Isang tunnel na bumabagsak ayon sa iskedyul

Iba ang pag-uugali ng phase 2: kapag hindi nagkakasundo ang dalawang dulo, sinusunod ng key renewal ang mas maikling agwat. Ang peer na itinuturing na mortal ang mismatch ay pinababagsak ang tunnel, kaya ang isang mismatch ay maaaring magmukhang dalawang hiwalay na sira. Panoorin ang ritmo ng key renewal, hindi lamang ang unang koneksyon. Ang tunnel na tumataas at pagkatapos ay bumabagsak sa regular na tiyempo ay mas madalas na mismatch ng lifetime kaysa depekto sa routing.

Iugnay ang mga timestamp ng pagbagsak sa sariling log ng peer bago baguhin ang anuman, dahil ang pagbabago ng selector o ruta ay maaaring gayahin ang parehong ritmo. Kung tumutugma ang tiyempo sa timer ng phase 2, natagpuan ang dahilan nang hindi ginalaw ang panukala.

Ang mga set ay nagmumula sa uri ng gateway

Ang mga cipher at integrity set ay hindi profile bawat tunnel na iyong ine-edit tulad ng pinapayagan ng strongSwan. Pinipili mo ang mga ito ayon sa uri ng gateway at bersyon ng IKE, at ang paghahanap ng profile na wala ay nagsasayang ng isang hapon.

Ang lumang aparatong walang iniaalok sa loob ng sinusuportahang set ay nag-iiwan ng dalawang tapat na landas: palitan ang aparato, o tapusin sa isang software gateway na kontrolado mo at rutahe papasok sa VPC mula roon. Anumang iba pa ay sudsod na babagsak sa susunod na pagsusuri.

Isang panlabas na address bawat aparato

Ang panlabas na address ng peer ay dapat tumugma nang isa-sa-isa sa panloob nitong address. Hindi maaaring gumana ang overloaded na PAT pool, dahil ang maraming host sa likod ng isang pampublikong address ay walang ibinibigay na paraan sa responder upang paghiwalayin sila. Kung saan kailangang maghati ng maraming host sa isang address, dapat magtapos ang tunnel sa lugar na kayang makilala sila.

Panatilihin ding matatag ang panlabas na address. Ilipat ang aparato sa likod ng ibang NAT at masisira ang ugnayan kahit tumutugma pa ang bawat panukala. Sulit isulat kung aling halaga ang sa Google at alin ang sa iyo: ang mga lifetime, set at one-to-one NAT ay nakatakda sa panig nila, habang ang mga panukala, selector, routing at prayoridad ng BGP ay sa iyo.