VPN ആരംഭിച്ചതിന് ശേഷം Azure VM-ന് IMDS അല്ലെങ്കിൽ WireServer-ൽ എത്താൻ കഴിയുന്നില്ല

VM പ്രവർത്തിക്കുന്നു, VPN ക്ലയന്റ് കണക്റ്റുചെയ്തതായി പറയുന്നു, കുറച്ച് മിനിറ്റുകൾ കഴിഞ്ഞ് Azure ഏജന്റ് അനാരോഗ്യകരമായ അവസ്ഥ റിപ്പോർട്ട് ചെയ്യാൻ തുടങ്ങുന്നു. ചിലപ്പോൾ SSH നിലനിൽക്കും, പോർട്ടലിലെ Run Command നിലനിൽക്കില്ല; ഇത് ആളുകളെ റൂട്ട് ടേബിളിനു പകരം ഏജന്റിലേക്ക് തിരിക്കുന്നു. ടണൽ ഉയർന്നപ്പോൾ അതിഥിയുടെ സ്വന്തം ഫോർവേഡിംഗ് തീരുമാനങ്ങൾ മാറി, സാധാരണയായി രണ്ട് പ്ലാറ്റ്ഫോം വിലാസങ്ങളാണ് ആദ്യ ഇരകൾ. ഏജന്റ് തകരാർ എന്നു കരുതുന്നതിന് മുമ്പ് ഞാൻ ഇതിനെ റൂട്ടിംഗ് ലക്ഷണമായി കാണുന്നു.

ലക്ഷണം തകർന്ന ഏജന്റിനെപ്പോലെ തോന്നുന്നു

താഴെയുള്ള രണ്ട് വിലാസങ്ങളും പരിഹാരമായി നിർദ്ദേശിക്കപ്പെടുന്നു, പക്ഷേ അവ ഒരേ സേവനമല്ല. ഒന്നിന് /32 പകർത്തുന്നത്, അത് മറ്റൊന്നിന് പ്രവർത്തിച്ചതിനാൽ, താൽക്കാലിക പരിഹാരം ആരും നീക്കാൻ ധൈര്യപ്പെടാത്ത സ്ഥിരമായ കോൺഫിഗറേഷനാകുന്ന വഴിയാണ്.

പ്രവർത്തിക്കുന്ന ക്രമം: ആദ്യം പരാജയപ്പെട്ട കോൾ യഥാർത്ഥത്തിൽ ഏത് വിലാസത്തെ ലക്ഷ്യമിടുന്നുവെന്ന് ഉറപ്പാക്കുക, തുടർന്ന് അതിഥി അത് എങ്ങനെ പരിഹരിക്കുന്നുവെന്ന് വായിക്കുക. ബാക്കിയെല്ലാം അധിക ഘട്ടങ്ങളുള്ള ഊഹവും നീളമേറിയ മാറ്റ വിൻഡോയുമാണ്.

168.63.129.16 പൊതു ലക്ഷ്യസ്ഥാനമല്ല

168.63.129.16 Azure-ന്റെ പ്രത്യേക വെർച്വൽ പ്ലാറ്റ്ഫോം വിലാസമാണ്, അതിന്റെ ഒരു പങ്ക് WireServer ആണ്; VM ഏജന്റ് ഫാബ്രിക്കുമായി സംസാരിക്കാൻ അത് ഉപയോഗിക്കുന്നു. TCP 80, 32526 പോർട്ടുകളിലേക്കുള്ള ഏജന്റ് ട്രാഫിക് ലഭ്യമായിരിക്കണമെന്ന് Microsoft രേഖപ്പെടുത്തുന്നു. ഇത് സാധാരണ ഇന്റർനെറ്റ് ഹോസ്റ്റല്ല, പൂർണ്ണ-ടണൽ VPN അത് വിദൂര എക്സിറ്റിലേക്ക് കൊണ്ടുപോകേണ്ടതുമില്ല. അതുകൊണ്ടാണ് ആരോഗ്യകരമായി തോന്നുന്ന ടണലിനും ഏജന്റിനെ പട്ടിണിക്കിടാൻ കഴിയുന്നത്.

പ്ലാറ്റ്ഫോം വിലാസ രേഖ ഈ വിലാസം ഉപയോക്തൃ-നിർവചിത റൂട്ടുകൾക്ക് വിധേയമല്ലെന്നും പറയുന്നു; അത് Azure ഫാബ്രിക്കിന്റെ സ്വഭാവമാണ്, നിങ്ങളുടെ അതിഥിയെക്കുറിച്ചുള്ള വാഗ്ദാനമല്ല. പ്രാദേശിക ഫയർവാൾ നിയമമോ VPN ക്ലയന്റിന്റെ സ്വന്തം റൂട്ടിംഗ് നയമോ ഇപ്പോഴും വഴി തകർക്കാം, അവയൊന്നും VNet-ന്റെ റൂട്ട് ടേബിളിൽ ജീവിക്കുന്നില്ല.

പ്രശ്നം റിപ്പോർട്ട് ചെയ്യുന്നത് ഏജന്റാണെങ്കിൽ, എന്തെങ്കിലും പുനഃസ്ഥാപിക്കുന്നതിന് മുമ്പ് സേവനാവസ്ഥയും ആ വിലാസത്തിലേക്കുള്ള വഴിയും പരിശോധിക്കുക.

169.254.169.254-ന് സ്വന്തം നിയമങ്ങളുണ്ട്

169.254.169.254 Azure Instance Metadata Service-ന്റെ link-local വിലാസമാണ്. അതിലേക്കുള്ള അഭ്യർത്ഥനകൾക്ക് സ്വന്തം വ്യവസ്ഥകളുണ്ട്: പ്രാഥമിക NIC-യും പ്രാഥമിക IP-യും, വിലാസത്തെ പിന്തുണയ്ക്കുന്ന DHCP കോൺഫിഗറേഷനും, ഏതെങ്കിലും HTTP പ്രോക്സി ഒഴിവാക്കലും. വിദൂര VPN എക്സിറ്റിലൂടെയോ ഏകപക്ഷീയ ഇന്റർനെറ്റ് ഗേറ്റ്വേയിലൂടെയോ അയക്കുന്നത് Microsoft വിവരിക്കുന്ന ആക്സസ് മോഡലല്ല.

ആ പ്രോക്സി വ്യവസ്ഥ റൂട്ട് ശരിയാക്കിയിട്ടും പരാജയങ്ങൾ കാണുന്നവരെ പിടിക്കുന്നു. അതിഥി HTTP പ്രോക്സി IMDS തകർക്കാം, അതേസമയം ip route get നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന ഇന്റർഫേസ് കൃത്യമായി നൽകുന്നു, അതിനാൽ റൂട്ടുകൾക്കൊപ്പം പ്രോക്സി ഒഴിവാക്കലുകളും പരിശോധിക്കുക.

ഇത് ഡീബഗ് ചെയ്യുമ്പോൾ മെറ്റാഡാറ്റ പ്രതികരണങ്ങൾ സപ്പോർട്ട് ടിക്കറ്റിൽ പേസ്റ്റ് ചെയ്യരുത്. സംഭവത്തെക്കാൾ കാലം നിൽക്കുന്ന ക്രെഡൻഷ്യലുകളും ഇൻസ്റ്റൻസ് വിശദാംശങ്ങളും അവയിൽ ഉണ്ടാകാം.

അതിഥിയുടെ പോളിസി റൂട്ടിംഗ് വായിക്കുക, പ്രധാന ടേബിൾ മാത്രമല്ല

Linux അതിഥിയിൽ മൂന്ന് വായന-മാത്ര കമാന്റുകൾ പാളികളെ വേർതിരിക്കുന്നു: നയ നിയമങ്ങൾക്ക് ip -4 rule show, തുടർന്ന് കേർണൽ യഥാർത്ഥത്തിൽ എടുക്കുന്ന തീരുമാനങ്ങൾക്ക് ip -4 route get 168.63.129.16, ip -4 route get 169.254.169.254. VPN കണക്റ്റുചെയ്യുന്നതിന് മുമ്പും ശേഷവും അവ പ്രവർത്തിപ്പിക്കുക. ആ രണ്ട് ഔട്ട്പുട്ടുകളുടെ വ്യത്യാസമാണ് നിങ്ങളുടെ മാറ്റ-ഗണം, ക്ലയന്റ് എന്ത് ചെയ്തുവെന്നതിനെക്കുറിച്ചുള്ള ഏത് ഊഹത്തെക്കാളും അത് ഉപയോഗപ്രദമാണ്.

നയ നിയമങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്യുന്ന VPN ക്ലയന്റിന് പ്രധാന ടേബിൾ തൊടാതെ ആ ലുക്കപ്പുകൾ വഴിതിരിച്ചുവിടാം. അതുകൊണ്ടാണ് പ്രധാന ടേബിൾ മാത്രം ശരിയാക്കുന്ന പരിഹാരം ഒരു ഹോസ്റ്റിൽ പ്രവർത്തിക്കുന്നതായി തോന്നുന്നത്, അടുത്തതിൽ ഒന്നും ചെയ്യുന്നില്ല. ഒന്നിലധികം NIC ഉള്ള അതിഥികൾ അതേ പ്രശ്നം മറുവശത്തുനിന്ന് ചേർക്കുന്നു, കാരണം ഉത്തരം നിയമം ഏത് NIC-യും സ്രോതസ്സ് വിലാസവും തിരഞ്ഞെടുക്കുന്നുവെന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു.

പഴയ ഗേറ്റ്വേയിലൂടെ രണ്ട് /32 റൂട്ടുകളും ചേർക്കുന്ന പാചകക്കുറിപ്പിനെ എതിർക്കുക. link-local പ്ലാറ്റ്ഫോം പാതയും സാധാരണ WAN അടുത്ത ഹോപ്പും വ്യത്യസ്ത വസ്തുക്കളാണ്, സർവവ്യാപി ഒഴിവാക്കൽ യഥാർത്ഥ നയ സംഘർഷം മറയ്ക്കുന്നു.

ഭരണവും വീണ്ടെടുപ്പും വേർതിരിച്ച് വയ്ക്കുക

നിങ്ങളുടെ SSH അല്ലെങ്കിൽ RDP മറുപടിയും പൂർണ്ണ-ടണൽ ഡിഫോൾട്ട് പിടിച്ചെടുക്കാം, പക്ഷേ അത് പ്ലാറ്റ്ഫോം എൻഡ്പോയിന്റിനെയല്ല, അഡ്മിനിസ്ട്രേറ്ററുടെ നിരീക്ഷിച്ച വിലാസത്തെയാണ് ലക്ഷ്യമിടുന്നത്. അതിന്റെ സ്വന്തം അഭ്യർത്ഥന-മറുപടി ജോടിയിൽ നിന്ന് രോഗനിർണയം ചെയ്യുക, VPN നയം മാറ്റുന്നതിന് മുമ്പ് സീരിയൽ കൺസോൾ പോലുള്ള സ്വതന്ത്ര വീണ്ടെടുപ്പ് ചാനൽ സൂക്ഷിക്കുക. വിന്യാസം VM പുനരാരംഭിച്ച് ഏജന്റ് അനാരോഗ്യം റിപ്പോർട്ട് ചെയ്താൽ, റൂട്ട് മാറ്റമാണ് പുനരാരംഭത്തിന് കാരണമെന്ന് കരുതുന്നതിനുപകരം രേഖപ്പെടുത്തിയ പ്രവർത്തനവും ഉത്തരവാദ സേവനവും പരിശോധിക്കുക.

തുടർന്ന് മൂന്ന് പ്രവാഹങ്ങൾ വെവ്വേറെ പരിശോധിക്കുക: നിങ്ങൾ യഥാർത്ഥത്തിൽ ആഗ്രഹിച്ച സ്വകാര്യ വിഭവം, പിന്തുണയ്ക്കുന്ന ഏജന്റ്-പ്ലാറ്റ്ഫോം ആശയവിനിമയം, ഭരണ പാത. ഒന്ന് പുനഃസ്ഥാപിക്കുന്നത് ബാക്കി രണ്ടും അതിജീവിച്ചു എന്നതിന്റെ തെളിവല്ല.

അംഗീകരിച്ച ഒഴിവാക്കൽ അതിഥി നെറ്റ്വർക്കിന്റെയും VPN കോൺഫിഗറേഷന്റെയും ഉടമയുടെ പേരിൽ എഴുതുക, വീണ്ടും കണക്റ്റുചെയ്യുമ്പോഴും പുനരാരംഭിക്കുമ്പോഴും എന്ത് സംഭവിക്കുന്നു എന്നതും ഉൾപ്പെടുത്തുക. Azure UDR-കൾ അതിഥിയുടെ റൂട്ട് ടേബിളല്ല, അവ എഡിറ്റുചെയ്യുന്നത് പ്രാദേശിക നയ നിയമം ശരിയാക്കില്ല.