Cloud VPN നില: IKE ലോഗിന് മുമ്പ് റിസോഴ്‌സിന്റെ നില വായിക്കുക

ഒരു Cloud VPN ടണൽ ഒരേ സമയം രണ്ട് ലൈഫ് സൈക്കിളുകൾ പ്രവർത്തിപ്പിക്കുന്നു, അവ ഒരേ ഘടികാരത്തിൽ അല്ല. ടണലിന് ചർച്ച നടത്താൻ കഴിയുന്നതിന് മുമ്പ് റിസോഴ്സ് അനുവദിക്കുകയും കോൺഫിഗർ ചെയ്യുകയും വേണം, അതിനുശേഷം പ്രോട്ടോക്കോളിന് സ്വന്തം IKE സന്ദേശക്രമമുണ്ട്. ഒന്നാമത്തേത് റിപ്പോർട്ട് ചെയ്യുമ്പോൾ രണ്ടാമത്തേതിനെക്കുറിച്ച് ഉപയോഗപ്രദമായി ഒന്നും പറയാതിരിക്കാം ഒരു സ്റ്റാറ്റസ് ഫീൽഡിന്. രണ്ടിനെയും ഒരു കാര്യമായി വായിക്കുന്നതാണ് കീ പൊരുത്തക്കേടിന് പ്രൊവിഷനിംഗ് കാലതാമസത്തിന്റെ കുറ്റം ലഭിക്കുന്ന വഴി.

ഒരു ടണൽ ഒബ്ജക്റ്റും ഒരു സമയ-വിൻഡോയും കൊണ്ട് തുടങ്ങുക.

രണ്ട് ലൈഫ് സൈക്കിളുകൾ, ഒരു ടണൽ ഒബ്ജക്റ്റ്

റിസോഴ്സിന്റെ ലൈഫ് സൈക്കിൾ എന്നത് ദാതാവ് ടണൽ തയ്യാറാക്കുന്നതാണ്: വിലാസങ്ങൾ, കോൺഫിഗറേഷൻ, ശേഷി. പ്രോട്ടോക്കോളിന്റെ ലൈഫ് സൈക്കിൾ ആരംഭിക്കുന്നത് ഇരു വശങ്ങൾക്കും IKE_SA_INIT, പിന്നീട് IKE_AUTH, പിന്നീട് ചൈൽഡ് സുരക്ഷാ അസോസിയേഷനുകൾ കൈമാറാൻ മതിയായ കോൺഫിഗറേഷൻ ഉള്ളപ്പോഴാണ്. ആദ്യ ഘട്ടത്തിൽ നിൽക്കുന്ന ടണൽ ഓതന്റിക്കേഷനിൽ പരാജയപ്പെട്ടിട്ടില്ല, കാരണം ഓതന്റിക്കേഷൻ ഇതുവരെ പരീക്ഷിച്ചിട്ടില്ല.

ആ വ്യത്യാസമാണ് മുഴുവൻ പ്രശ്നം. ബാക്കിയെല്ലാം ബന്ധമില്ലാത്ത സന്ദേശങ്ങൾ ചേർക്കാതെ അത് നിരീക്ഷിക്കുന്നതെങ്ങനെ എന്നതാണ്.

ഒബ്ജക്റ്റ് വായിക്കുക, കൺസോൾ സംഗ്രഹമല്ല

API-യോട് പ്രധാനമായ രണ്ട് ഫീൽഡുകൾ മാത്രം ആവശ്യപ്പെടുക, മറ്റൊന്നുമല്ല, അപ്പോൾ ഉത്തരം രാത്രി മൂന്ന് മണിക്ക് വായിക്കാൻ മതിയായ ചെറുതായിരിക്കും: gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)". status ഫീൽഡ് ലൈഫ് സൈക്കിളിന്റെ ഘട്ടം പേരിടുന്നു, detailedStatus അതിനോട് ബന്ധിപ്പിച്ച വായിക്കാവുന്ന കാരണം വഹിക്കുന്നു. പൂർണ്ണ കോൺഫിഗറേഷൻ ഡംപ് മറ്റ് ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു, ടിക്കറ്റിൽ ഒട്ടിക്കാൻ ബുദ്ധിമുട്ടാണ്. ഇത്തരം വായന-മാത്ര കോളുകൾക്ക് ടണൽ മാറ്റാൻ കഴിയില്ല, സംഭവം ഇപ്പോഴും സജീവമായിരിക്കുമ്പോൾ ഇത് പ്രധാനമാണ്.

കോളിന്റെ സമയമുദ്ര മൂല്യങ്ങൾക്കൊപ്പം രേഖപ്പെടുത്തുക, കാരണം രണ്ട് ഫീൽഡുകളും നീങ്ങുന്നു.

ALLOCATING_RESOURCES കീ പൊരുത്തക്കേടല്ല

ടണൽ ALLOCATING_RESOURCES റിപ്പോർട്ട് ചെയ്യുമ്പോൾ, ദാതാവ് ഇപ്പോഴും ഒബ്ജക്റ്റ് കൂട്ടിച്ചേർക്കുകയാണ്. ആ ഘട്ടത്തിൽ മുൻകൂട്ടി പങ്കിട്ട കീയുടെ പൊരുത്തക്കേട് നിരീക്ഷിക്കാനാവില്ല, തടയപ്പെട്ട പിയർ പോർട്ടും അത്രതന്നെ തെളിയിക്കപ്പെട്ടിട്ടില്ല. പരിശോധിക്കാനാകുന്നത് വിശദമായ സന്ദേശം, പ്രോജക്റ്റും സേവനവും ആരോഗ്യകരമായി കാണപ്പെടുന്നുണ്ടോ, പിയറുമായി ആകെ ബന്ധപ്പെടാൻ ടണൽ കോൺഫിഗറേഷൻ മതിയായ പൂർണ്ണമാണോ എന്നിവയാണ്. ഇപ്പോൾ രഹസ്യം മാറ്റുന്നത് ഒരിക്കലും പരീക്ഷിക്കാത്ത ഒരു മൂല്യം മാറ്റുന്നു.

കോൺഫിഗറേഷനെക്കുറിച്ച് തീരുമാനത്തിൽ എത്തുന്നതിന് മുമ്പ് നില മാറുന്നതുവരെ കാത്തിരിക്കുക.

ESTABLISHED ആക്സസ് പരിശോധനകളുടെ തുടക്കമാണ്

സ്ഥാപിതമായ ടണൽ IKE പൂർത്തിയായി എന്നാണ് അർത്ഥമാക്കുന്നത്, ട്രാഫിക് ഒഴുകുന്നു എന്നല്ല. ടണൽ വഹിക്കുന്ന റൂട്ടുകൾ സ്ഥിരീകരിക്കുക, Cloud Router ഉൾപ്പെട്ടിടത്ത് BGP സെഷനും അത് പഠിച്ച പ്രിഫിക്സുകളും സ്ഥിരീകരിക്കുക. തുടർന്ന് അനുവദനീയമായ ഒരു ആപ്ലിക്കേഷൻ കൈമാറ്റം പരീക്ഷിക്കുക, കാരണം ഒരു ഫയർവാൾ നിയമമോ കാണാത്ത റൂട്ടോ പൂർണ്ണമായും ആരോഗ്യകരമായ ടണലിലൂടെയുള്ള ട്രാഫിക് തടയാം. അവയോരോന്നും വെവ്വേറെ നിരീക്ഷണവും വെവ്വേറെ പരിഹാരവുമാണ്.

അടുത്തതായി ഏത് ചോദ്യം ചോദിക്കണമെന്ന് നില പറയുന്നു. ആക്സസ് ചോദ്യത്തിന് അത് ഒരിക്കലും നിങ്ങൾക്ക് പകരം ഉത്തരം നൽകുന്നില്ല.

ഒരു ഒബ്ജക്റ്റും ഒരു സമയ-വിൻഡോയും പരസ്പരം ബന്ധിപ്പിക്കുക

ലോഗിലെ പഴയ ഓതന്റിക്കേഷൻ പരാജയം മുൻ ശ്രമത്തിന്റേതാണ്, അതിന്റെ സമയമുദ്ര നിങ്ങൾ അന്വേഷിക്കുന്ന വിൻഡോയ്ക്കുള്ളിൽ വീഴുന്നില്ലെങ്കിൽ. നിങ്ങൾ രേഖപ്പെടുത്തിയ നിലയുടെ അതേ മിനിറ്റുകൾക്കുള്ള ടണൽ റിസോഴ്സിന്റെ ലോഗുകൾ എടുക്കുക, ഐഡന്റിഫയറുകൾ ഒരുമിച്ച് സൂക്ഷിക്കുക. പിന്നീടുള്ള ഒരു IKE സംഭവം ചർച്ച ആരംഭിച്ചു എന്ന് കാണിക്കാം, അതേസമയം നിങ്ങൾ നോക്കുന്ന കൺസോൾ സന്ദേശം ഇതിനകം കാലഹരണപ്പെട്ടതാണ്.

എന്തെങ്കിലും ശേഖരിക്കുന്നതിന് മുമ്പ് ടണൽ സുഖപ്പെട്ടാൽ അത് പറയുക. നിർണ്ണയിക്കാത്ത കാരണം ബന്ധമില്ലാത്ത വരികൾ കൂട്ടിച്ചേർത്ത ആത്മവിശ്വാസമുള്ള കഥയേക്കാൾ നല്ല രേഖയാണ്.

അടുത്ത ചുവട് എപ്പോഴും ഒരേ രൂപമാണ്: ഒരു ഒബ്ജക്റ്റ്, ഒരു വിൻഡോ, ഒരു ഘട്ടം. ഇതിലും വിശാലമായത് സംഗ്രഹമാണ്, രോഗനിർണ്ണയമല്ല.