Azure P2S: VNet മാറ്റത്തിന് ശേഷം ഒരു Windows ക്ലയന്റിന്റെ റൂട്ടുകൾ നഷ്ടമായി
ഒരു Windows P2S ക്ലയന്റ് പുതിയ VNet-ൽ എത്താത്തപ്പോൾ, അതിന്റെ തിരഞ്ഞെടുത്ത റൂട്ടുകൾ താരതമ്യം ചെയ്ത് TTL ക്രമീകരണങ്ങൾ തൊടുന്നതിന് മുമ്പ് ഗേറ്റ്വേ പാക്കേജ് വീണ്ടും സൃഷ്ടിക്കുക.
രണ്ട് ലാപ്ടോപ്പുകൾ ഒരേ Azure point-to-site ഗേറ്റ്വേയിൽ പ്രാമാണീകരിക്കുന്നു, പുതുതായി ബന്ധിപ്പിച്ച VNet-ൽ എത്തുന്നത് ഒന്ന് മാത്രം. രണ്ടും Connected കാണിക്കുന്നു, അതിനാൽ പ്രാമാണീകരണം വ്യത്യാസമല്ല; അവ സൂക്ഷിക്കുന്ന ലക്ഷ്യ റൂട്ടുകളാണ് വ്യത്യാസം. പരാജയപ്പെടുന്ന ക്ലയന്റിൽ നിന്ന് തുടങ്ങുക, ഒരു ലക്ഷ്യം താരതമ്യം ചെയ്യുക, അതിനുശേഷം മാത്രം വിടവ് ഗേറ്റ്വേ പാക്കേജിന്റേതാണോ പ്രാദേശിക റൂട്ട് പട്ടികയുടേതാണോ എന്ന് തീരുമാനിക്കുക.
ഗേറ്റ്വേയിൽ നിന്നല്ല, പരാജയപ്പെടുന്ന ക്ലയന്റിൽ നിന്ന് തുടങ്ങുക
ലാപ്ടോപ്പിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് ടോപ്പോളജി സ്ഥിരീകരിക്കുക. ഏത് VNet-ഉകൾ ഗേറ്റ്വേ VNet-മായി ബന്ധിപ്പിച്ചിരിക്കുന്നു, പുതിയ നെറ്റ്വർക്ക് നേരിട്ട് പിയർ ചെയ്തതാണോ അല്ലെങ്കിൽ വേറിട്ട site-to-site ടണലിലൂടെ എത്തുന്നതാണോ എന്ന് പരിശോധിക്കുക. പുതിയ VNet ഗേറ്റ്വേ VNet-മായി ഒട്ടും ബന്ധിപ്പിച്ചിട്ടില്ലെങ്കിൽ, ഒരു ക്ലയന്റ് പാക്കേജിനും അങ്ങോട്ട് റൂട്ട് ചെയ്യാനാകില്ല, പ്രവർത്തിക്കുന്ന ലാപ്ടോപ്പാണ് വിശദീകരിക്കേണ്ട അസാധാരണത. ഉത്തരം എഴുതിവയ്ക്കുക, കാരണം അതാണ് ക്ലയന്റിനെയാണോ ഗേറ്റ്വേയെയാണോ ഡീബഗ് ചെയ്യുന്നതെന്ന് തീരുമാനിക്കുന്നത്.
ടോപ്പോളജി ശരിയായാൽ രണ്ട് ലാപ്ടോപ്പുകളും അടുത്തടുത്ത് വയ്ക്കുക. ഒരേ ഗേറ്റ്വേ, ഒരേ വിലാസ പൂൾ, ഒരേ പ്രോട്ടോക്കോൾ, ഒരേ ക്ലയന്റ് ബിൽഡ് എന്നിവയാണ് ആവശ്യമായ താരതമ്യം; മറ്റെല്ലാം പിന്നീട് ഒഴിവാക്കേണ്ട രണ്ടാമത്തെ ചരമാണ്.
route print ഉപയോഗിച്ച് ഒരു ലക്ഷ്യം താരതമ്യം ചെയ്യുക
അനുവദനീയമായ ഒരു റിസോഴ്സ് IP തിരഞ്ഞെടുത്ത് രണ്ട് ലാപ്ടോപ്പുകളും രണ്ടുതവണ താരതമ്യം ചെയ്യുക: വിച്ഛേദിച്ച അവസ്ഥയിൽ, പിന്നീട് ബന്ധിപ്പിച്ച അവസ്ഥയിൽ. Windows-ൽ route print -4 ലക്ഷ്യ പ്രിഫിക്സ്, ഇന്റർഫേസ്, അടുത്ത ഹോപ്പ്, മെട്രിക് എന്നിവയോടെ IPv4 റൂട്ടുകൾ പട്ടികപ്പെടുത്തുന്നു. VPN എന്ന വാക്കുള്ള എൻട്രികൾ എണ്ണുന്നതിനുപകരം ആ ലക്ഷ്യത്തിന് യഥാർത്ഥത്തിൽ ജയിക്കുന്ന വരി രേഖപ്പെടുത്തുക.
തിരഞ്ഞെടുപ്പ് ആദ്യം ഏറ്റവും നീളമുള്ള പ്രിഫിക്സ്, പിന്നീട് മെട്രിക് എന്ന ക്രമത്തിലാണ്, അതിനാൽ കൂടുതൽ നിർദ്ദിഷ്ട പ്രാദേശിക റൂട്ടിന് തെറ്റായി തോന്നാതെ തന്നെ ടണൽ റൂട്ടിനെ മറികടക്കാനാകും. ഉദ്ദേശിച്ച ലക്ഷ്യം 10.24.0.0/16-നുള്ളിൽ ആണെങ്കിൽ, ആരോഗ്യകരമായ ക്ലയന്റ് VPN ഇന്റർഫേസിൽ പൊരുത്തപ്പെടുന്ന റൂട്ട് കാണിക്കും, പരാജയപ്പെടുന്ന ക്ലയന്റ് അതേ വിലാസം അതിന്റെ ഡിഫോൾട്ട് ഗേറ്റ്വേയിലേക്ക് അയയ്ക്കും.
പരസ്പരവിരുദ്ധമായ പ്രാദേശിക പ്രിഫിക്സിനും അതേ ലക്ഷണം ഉണ്ടാകാം. എന്തെങ്കിലും ചേർക്കുന്നതിന് മുമ്പ് രണ്ട് കേസുകളിൽ ഏതാണെന്ന് തീരുമാനിക്കുക: ടണൽ റൂട്ട് ഒട്ടുമില്ലേ, അതല്ലെങ്കിൽ ടണൽ റൂട്ട് കൂടുതൽ നിർദ്ദിഷ്ട റൂട്ടിനോട് തോൽക്കുന്നുണ്ടോ.
TTL expired റൂട്ട് വിതരണത്തിന്റെ ബഗ് അല്ല
TTL expired in transit തിരികെ നൽകുന്ന ping പാക്കറ്റ് അതിന്റെ ഹോപ്പ് കോട്ട തീർത്തു എന്ന് പറയുന്നു, ഇത് സാധാരണയായി ഫോർവേഡിംഗ് ലൂപ്പാണ്, കേടായ VPN ഡ്രൈവർ അല്ല. Windows ping 255 വരെ TTL സ്വീകരിക്കുന്നു, മൂല്യം ഉയർത്തുന്നത് ലൂപ്പ് നന്നാക്കുന്നില്ല; അതേ പിശക് വൈകിപ്പിക്കുക മാത്രം ചെയ്യുന്നു. സന്ദേശത്തെ പാതയുടെ ലക്ഷണമായി കാണുക, റൂട്ട് വിതരണത്തെക്കുറിച്ചുള്ള തെളിവായി അല്ല.
പാത എവിടെ ആവർത്തിക്കുന്നു എന്ന് കാണാൻ tracert -4 10.24.1.10 ഉപയോഗിക്കുക. അതേ രണ്ട് ഹോപ്പുകൾ വീണ്ടും വീണ്ടും കാണുന്നുണ്ടെങ്കിൽ, ടണലിലേക്കുള്ള ട്രാഫിക് തിരികെ ടണലിലേക്കോ അത് തിരികെ അയയ്ക്കുന്ന പ്രാദേശിക റൂട്ടറിലേക്കോ അയയ്ക്കുന്ന റൂട്ട് തിരയുക.
പാക്കേജ് അതിന്റെ ഉടമസ്ഥതയിലുള്ള ഗേറ്റ്വേയിൽ വീണ്ടും സൃഷ്ടിക്കുക
പ്രസക്തമായ ടോപ്പോളജി മാറ്റങ്ങൾക്ക് ശേഷം Windows ക്ലയന്റ് പാക്കേജുകൾ വീണ്ടും ഡൗൺലോഡ് ചെയ്ത് ഇൻസ്റ്റാൾ ചെയ്യണമെന്ന് Microsoft രേഖപ്പെടുത്തുന്നു. ഈ പ്രൊഫൈൽ സേവിക്കുന്ന Azure ഗേറ്റ്വേയിൽ നിന്ന് നിലവിലെ പാക്കേജ് എടുത്ത്, ആ ക്ലയന്റിനുള്ള പിന്തുണയുള്ള നടപടിക്രമത്തിൽ പ്രയോഗിക്കുക. ബന്ധമില്ലാത്ത ഒരു VPN ആപ്ലിക്കേഷന്റെ എക്സിക്യൂട്ടബിൾ മാറ്റിസ്ഥാപിക്കുന്നത് ഗേറ്റ്വേ-നിർദ്ദിഷ്ട ക്രമീകരണങ്ങൾ വീണ്ടും സൃഷ്ടിക്കുന്നതിന് തുല്യമായ പ്രവർത്തനമല്ല. പാക്കേജ് വീണ്ടും ഡൗൺലോഡ് ചെയ്യുന്നത് വിലകുറഞ്ഞതാണ്; പ്രാദേശിക റൂട്ടുകൾ ഊഹിക്കുന്നത് അല്ല.
വീണ്ടും ബന്ധിപ്പിച്ച് യഥാർത്ഥ ലക്ഷ്യത്തിന്റെ റൂട്ട് വീണ്ടും വായിക്കുക. മാറ്റ രേഖയോടൊപ്പം മുമ്പത്തെയും ശേഷത്തെയും വരികൾ സൂക്ഷിക്കുക, അതിലൂടെ ഫലം ക്ലയന്റ് വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്തു എന്നതിനേക്കാൾ കൃത്യമാകും.
Azure P2S റൂട്ടിംഗ് സാഹചര്യങ്ങൾ നേരിട്ട് പിയർ ചെയ്ത VNet-കളെ മറ്റ് ടണലുകളിലൂടെ എത്തുന്ന നെറ്റ്വർക്കുകളിൽ നിന്ന് വേർതിരിക്കുന്നു, പുതിയ പാക്കേജിന് പിയറിംഗ് ട്രാൻസിറ്റീവ് ആക്കാനാവില്ല. ചില Windows site-to-site അല്ലെങ്കിൽ BGP സാഹചര്യങ്ങൾക്ക് കൈകൊണ്ട് ക്രമീകരിച്ച റിമോട്ട് റൂട്ടുകളും വേണം, അതിനാൽ പാക്കേജ് പുതുക്കൽ സാർവത്രിക റൂട്ട് വിതരണ സംവിധാനമല്ല.
താൽക്കാലിക റൂട്ട് താൽക്കാലികമായി നിലനിർത്തുക
കൈകൊണ്ടുള്ള റൂട്ടിന് നഷ്ടമായ ക്ലയന്റ് റൂട്ടിനെ വേർതിരിക്കാം, പക്ഷേ യഥാർത്ഥ രൂപകൽപ്പനയിൽ നിന്ന് നിർമ്മിക്കുക: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, സ്ഥിരമായ ഫ്ലാഗ് ഇല്ലാതെ, അതുവഴി റീബൂട്ടിൽ അത് അപ്രത്യക്ഷമാകും. ഇന്റർഫേസ് ഇൻഡക്സും അടുത്ത ഹോപ്പും ബന്ധിപ്പിച്ച VPN അഡാപ്റ്ററിൽ നിന്ന് തിരഞ്ഞെടുക്കുക, ഊഹത്തിൽ നിന്നല്ല.
പരീക്ഷണാത്മക റൂട്ട് സ്ഥിരമായ മത്സര ഉടമയായി വിടരുത്. ഭാവിയിലെ പ്രൊഫൈൽ അപ്ഡേറ്റുകൾ അതേ പ്രിഫിക്സ് മറ്റൊരു മെട്രിക്കോടെ ചേർത്തേക്കാം, അപ്പോൾ കൈകൊണ്ടുള്ള എൻട്രി ഏത് പാത ജയിക്കുമെന്ന് നിശബ്ദമായി തീരുമാനിക്കും. നീക്കം ചെയ്യാനുള്ള ഘട്ടം മാറ്റത്തിൽ രേഖപ്പെടുത്തുക.
ശരിയായ റൂട്ട് സജീവമായാൽ ping അല്ല, ലക്ഷ്യ ആപ്ലിക്കേഷൻ പരിശോധിക്കുക. പാക്കറ്റുകൾ Azure-ൽ എത്തിയിട്ടും സേവനം ഇപ്പോഴും പരാജയപ്പെടുന്നുവെങ്കിൽ, നെറ്റ്വർക്ക് സെക്യൂരിറ്റി ഗ്രൂപ്പും തിരികെയുള്ള പാതയും പരിശോധിക്കുക, കാരണം അവ ലാപ്ടോപ്പ് പ്രിഫിക്സ് പഠിച്ചോ ഇല്ലയോ എന്നതിൽ നിന്ന് വേറിട്ടതാണ്.