Limoj de Cloud VPN, kiujn vi ne povas agordi: IKE-daŭro kaj NAT de la peer

Donu al la malproksima aparato daŭron de fazo 1 de 24 horoj kaj la tunelo Cloud VPN restas malsupre, eĉ kiam ĉio ĉe la flanko de Google estas ĝuste agordita. La peer proponas valoron, kiun la respondanto ne akceptos, do la intertraktado aŭ tute fiaskas aŭ rekomenciĝas senfine. Cloud VPN limigas fazon 1 al 36,000 sekundoj, do dek horoj, kaj tiu limo ne estas agordo, kiun vi povas altigi. La ŝanĝo apartenas al la malproksima aparato.

La peer demandas, la respondanto decidas

IKE estas ekzerco de kongruigo inter du aroj de proponoj. La tunelo formiĝas nur tie, kie la aroj interkovriĝas ene de la limoj, kiujn la respondanto akceptas, kaj tial daŭro ekster la gamo tute ne produktas partan tunelon. La kutima eraro estas trakti la agordon de la peer kiel deziroliston anstataŭ kiel proponon. Malplena komunaĵo lasas la tunelon malsupre, kiom ajn ĝustaj estas la enkursigado kaj la selektiloj.

Legu la propran staton de la tunelo antaŭ ol malfermi kazon, ĉar la detala stato kutime nomas la etapon, kiu fiaskis:

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

Komparu tion, kio revenas, kun la subtenata aro por via enporda tipo kaj IKE-versio, kaj notu ambaŭ trafikselektilojn dum vi estas tie. Miskongruo de selektilo donas la saman simptomon de malsupra tunelo kiel miskongruo de algoritmo, kaj malkiel la algoritmo, ĉi tiu estas via por ripari.

36,000 sekundoj estas la plafono

Fazo 1 haltas ĉe 36,000 sekundoj. Aparato agordita al 86,400 petas ion, al kio la respondanto neniam konsentos, kaj reprovo ne ŝanĝas ĝian opinion. Returnu la malproksiman proponon en la gamon kaj la sama agordo establiĝas; la nesimetrio estas la tuta leciono, ĉar vi povas malaltigi vian propran valoron kaj ne povas altigi tiun de Google.

Skribu la elektitan valoron en la dezajnajn notojn. Alie la sekva inĝeniero ripetas la 24-horan eksperimenton kaj atingas la saman muron.

La subtenata aro estas publikigata laŭ enporda tipo kaj IKE-versio en la superrigardo de Cloud VPN, do legu la sekcion por via topologio anstataŭ ĝenerala IKE-gvidilo.

Tunelo, kiu falas laŭ horaro

Fazo 2 kondutas alie: kiam la du finoj ne konsentas, ŝlosilrenovigo sekvas la pli mallongan intervalon. Peer, kiu traktas la miskongruon kiel fatala, faligas la tunelon anstataŭe, do unu miskongruo povas aspekti kiel du nerilataj paneoj. Observu la ritmon de ŝlosilrenovigo, ne nur la unuan konekton. Tunelo, kiu leviĝas kaj poste falas en regula takto, estas pli ofte miskongruo de daŭro ol difekto de enkursigado.

Korelaciu tiujn falajn tempomarkojn kun la propraj protokoloj de la peer antaŭ ol ŝanĝi ion, ĉar ŝanĝo de selektilo aŭ itinero povas imiti la saman ritmon. Se la takto kongruas kun la tempigilo de fazo 2, la kaŭzo estas trovita sen tuŝi proponon.

La aroj venas de la enporda tipo

Ĉifraj kaj integrecaj aroj ne estas profilo por unuopa tunelo, kiun vi redaktas kiel strongSwan permesas. Vi elektas ilin laŭ enporda tipo kaj IKE-versio, kaj ĉasi profilon, kiu ne ekzistas, malŝparas posttagmezon.

Malnova aparato, kiu ofertas nenion ene de la subtenata aro, lasas du honestajn vojojn: anstataŭigu la aparaton, aŭ finu ĉe programara enpordo, kiun vi kontrolas, kaj enkursigu de tie en la VPC-on. Io ajn alia estas ĉirkaŭvojo, kiu malsukcesos en la sekva revizio.

Unu ekstera adreso por aparato

La ekstera adreso de la peer devas mapiĝi unu-al-unu al ĝia interna adreso. Troŝarĝita PAT-puto ne povas funkcii, ĉar pluraj gastigantoj malantaŭ unu publika adreso ne donas al la respondanto manieron apartigi ilin. Kie pluraj gastigantoj devas dividi adreson, la tunelo devas finiĝi ie, kio povas distingi ilin.

Tenu ankaŭ tiun eksteran adreson stabila. Movu la aparaton malantaŭ alian NAT kaj la ligo rompiĝas, kvankam ĉiu propono ankoraŭ kongruas. Indas skribi, kiuj valoroj estas de Google kaj kiuj estas viaj: daŭroj, aroj kaj unu-al-unu NAT estas fiksaj ĉe ilia flanko, dum proponoj, selektiloj, enkursigado kaj BGP-prioritatoj estas viaj.