Cloud VPN-grenzen die u niet kunt bijstellen: IKE-levensduur en peer-NAT
Cloud VPN onderhandelt IKE-levensduren binnen vaste grenzen en vereist één-op-één NAT aan de peer. Ontwerp het externe apparaat daarop, niet op de kant van Google.
Geef het externe apparaat een fase 1-levensduur van 24 uur en de Cloud VPN-tunnel blijft neer, ook al is alles aan de kant van Google correct geconfigureerd. De peer stelt een waarde voor die de responder niet accepteert, dus de onderhandeling mislukt volledig of herstart eindeloos. Cloud VPN begrenst fase 1 tot 36,000 seconden, tien uur, en die bovengrens is geen instelling die u kunt verhogen. De wijziging hoort op het externe apparaat.
De peer vraagt, de responder beslist
IKE is een oefening in het op elkaar afstemmen van twee voorstellensets. De tunnel komt alleen tot stand waar de sets overlappen binnen de grenzen die de responder accepteert, en daarom levert een levensduur buiten het bereik helemaal geen gedeeltelijke tunnel op. De gebruikelijke fout is de configuratie van de peer als verlanglijstje te behandelen in plaats van als voorstel. Een lege doorsnede laat de tunnel neer, hoe correct de routing en de selectors ook zijn.
Lees de eigen status van de tunnel voordat u een zaak opent, want de gedetailleerde status noemt meestal de fase die is mislukt:
gcloud compute vpn-tunnels describe office-tunnel \
--region europe-west1 \
--format="value(status,detailedStatus)"
Vergelijk wat terugkomt met de ondersteunde set voor uw gatewaytype en IKE-versie, en noteer beide verkeersselectors terwijl u er toch bent. Een selectorverschil geeft hetzelfde symptoom van een neerliggende tunnel als een algoritmeverschil, en anders dan bij het algoritme is dit aan u om te verhelpen.
36,000 seconden is het plafond
Fase 1 stopt bij 36,000 seconden. Een apparaat dat op 86,400 staat, vraagt iets wat de responder nooit zal accepteren, en opnieuw proberen verandert zijn mening niet. Draai het externe voorstel terug binnen het bereik en dezelfde configuratie komt tot stand; de asymmetrie is de hele les, want u kunt uw eigen waarde verlagen en die van Google niet verhogen.
Schrijf de gekozen waarde in de ontwerpnotities. Anders herhaalt de volgende engineer het experiment van 24 uur en loopt tegen dezelfde muur.
De ondersteunde set wordt per gatewaytype en IKE-versie gepubliceerd in het Cloud VPN-overzicht, dus lees de sectie voor uw topologie in plaats van een algemene IKE-gids.
Een tunnel die volgens een schema wegvalt
Fase 2 gedraagt zich anders: als de twee uiteinden het oneens zijn, volgt sleutelvernieuwing het kortste interval. Een peer die het verschil als fataal ziet, laat de tunnel juist vallen, zodat één verschil op twee losse storingen kan lijken. Let op het ritme van sleutelvernieuwing, niet alleen op de eerste verbinding. Een tunnel die opkomt en daarna in een regelmatig tempo omvalt, is vaker een levensduurverschil dan een routingdefect.
Correleer die valtijdstippen met de eigen logs van de peer voordat u iets wijzigt, want een selector- of routewijziging kan hetzelfde ritme nabootsen. Als het tempo bij de fase 2-timer past, is de oorzaak gevonden zonder een voorstel aan te raken.
De suites komen van het gatewaytype
Cipher- en integriteitssuites zijn geen profiel per tunnel dat u bewerkt zoals strongSwan u toestaat. U kiest ze op gatewaytype en IKE-versie, en het zoeken naar een profiel dat niet bestaat kost een middag.
Een oud apparaat dat niets binnen de ondersteunde set biedt, laat twee eerlijke wegen: vervang het apparaat, of terminer op een softwaregateway die u beheert en routeer van daaruit de VPC in. Al het andere is een omweg die de volgende beoordeling niet haalt.
Eén extern adres per apparaat
Het externe adres van de peer moet één-op-één op zijn interne adres worden afgebeeld. Een overbelaste PAT-pool kan niet werken, omdat meerdere hosts achter één openbaar adres de responder geen manier geven om ze te scheiden. Waar meerdere hosts een adres moeten delen, moet de tunnel eindigen op een plek die ze kan onderscheiden.
Houd dat externe adres ook stabiel. Verplaats het apparaat achter een andere NAT en de associatie breekt, ook al past elk voorstel nog. Het loont om op te schrijven welke waarden van Google zijn en welke van u: levensduren, suites en één-op-één NAT liggen aan hun kant vast, terwijl voorstellen, selectors, routing en BGP-prioriteiten van u zijn.