Limite Cloud VPN pe care nu le puteți regla: durata IKE și NAT-ul peerului
Cloud VPN negociază durate IKE în limite fixe și are nevoie de NAT unu-la-unu la peer. Proiectați dispozitivul la distanță în funcție de asta, nu de partea Google.
Dați dispozitivului de la distanță o durată de fază 1 de 24 de ore și tunelul Cloud VPN rămâne jos, chiar dacă totul din partea Google este configurat corect. Peerul propune o valoare pe care responderul nu o va accepta, așa că negocierea fie eșuează complet, fie repornește la nesfârșit. Cloud VPN limitează faza 1 la 36,000 de secunde, adică zece ore, iar acest plafon nu este o setare pe care o puteți ridica. Schimbarea aparține dispozitivului de la distanță.
Peerul întreabă, responderul decide
IKE este un exercițiu de potrivire între două seturi de propuneri. Tunelul se formează doar acolo unde seturile se suprapun în limitele pe care responderul le acceptă, de aceea o durată în afara intervalului nu produce niciun tunel parțial. Greșeala obișnuită este să tratați configurația peerului ca pe o listă de dorințe, nu ca pe o propunere. O intersecție goală lasă tunelul jos, oricât de corecte ar fi rutarea și selectorii.
Citiți starea tunelului însuși înainte de a deschide un caz, pentru că starea detaliată numește de obicei faza care a eșuat:
gcloud compute vpn-tunnels describe office-tunnel \
--region europe-west1 \
--format="value(status,detailedStatus)"
Comparați ce se întoarce cu setul acceptat pentru tipul de gateway și versiunea IKE, și notați ambii selectori de trafic cât timp sunteți acolo. O nepotrivire de selector dă același simptom de tunel jos ca o nepotrivire de algoritm, iar spre deosebire de algoritm, aceasta este a dumneavoastră de reparat.
36,000 de secunde este plafonul
Faza 1 se oprește la 36,000 de secunde. Un dispozitiv setat la 86,400 cere ceva cu care responderul nu va fi niciodată de acord, iar reîncercarea nu îi schimbă părerea. Readuceți propunerea de la distanță în interval și aceeași configurație se stabilește; asimetria este întreaga lecție, fiindcă vă puteți coborî propria valoare și nu o puteți ridica pe cea a Google.
Scrieți valoarea aleasă în notele de proiectare. Altfel următorul inginer repetă experimentul de 24 de ore și ajunge la același zid.
Setul acceptat este publicat pe tip de gateway și versiune IKE în prezentarea generală Cloud VPN, așa că citiți secțiunea pentru topologia dumneavoastră, nu un ghid IKE general.
Un tunel care cade după un program
Faza 2 se comportă diferit: când cele două capete nu sunt de acord, reînnoirea cheilor urmează intervalul mai scurt. Un peer care tratează nepotrivirea ca fatală lasă tunelul să cadă, așa că o singură nepotrivire poate părea două defecțiuni fără legătură. Urmăriți ritmul reînnoirii cheilor, nu doar prima conexiune. Un tunel care urcă și apoi cade într-o cadență regulată este mai des o nepotrivire de durată decât un defect de rutare.
Corelați acele momente ale căderii cu jurnalele peerului însuși înainte de a schimba ceva, pentru că o modificare de selector sau de rută poate imita același ritm. Dacă ritmul se potrivește cu temporizatorul fazei 2, cauza este găsită fără să atingeți o propunere.
Seturile provin din tipul de gateway
Seturile de cifrare și integritate nu sunt un profil pe tunel pe care să îl editați cum permite strongSwan. Le alegeți după tipul de gateway și versiunea IKE, iar căutarea unui profil care nu există pierde o după-amiază.
Un dispozitiv vechi care nu oferă nimic în setul acceptat lasă două căi oneste: înlocuiți dispozitivul sau terminați pe un gateway software pe care îl controlați și rutați de acolo în VPC. Orice altceva este o soluție de ocol care va eșua la următoarea revizuire.
O adresă externă pe dispozitiv
Adresa externă a peerului trebuie să corespundă unu-la-unu adresei sale interne. Un pool PAT supraîncărcat nu poate funcționa, pentru că mai multe gazde în spatele unei singure adrese publice nu îi dau responderului nicio modalitate de a le demultiplexa. Acolo unde mai multe gazde trebuie să împartă o adresă, tunelul trebuie să se termine într-un loc care le poate distinge.
Păstrați stabilă și acea adresă externă. Mutați dispozitivul în spatele altui NAT și asocierea se rupe, deși fiecare propunere încă se potrivește. Merită să notați care valori sunt ale Google și care sunt ale dumneavoastră: duratele, seturile și NAT-ul unu-la-unu sunt fixe de partea lor, în timp ce propunerile, selectorii, rutarea și prioritățile BGP sunt ale dumneavoastră.