Azure P2S VPN-ന് സ്വകാര്യ എൻഡ്‌പോയിന്റ് നാമം വിശകലനം ചെയ്യാനാകുന്നില്ല

നിങ്ങൾ point-to-site ടണൽ ബന്ധിപ്പിക്കുന്നു, സ്വകാര്യ വിലാസത്തിലേക്ക് ping ചെയ്യുന്നു, ആപ്പ് തുറക്കുന്നു, പകരം 403 അല്ലെങ്കിൽ സർട്ടിഫിക്കറ്റ് പിശക് ലഭിക്കുന്നു. രണ്ട് ലക്ഷണങ്ങളും DNS-ലേക്ക് വിരൽ ചൂണ്ടുന്നു, പക്ഷേ അവ വ്യത്യസ്ത തകരാറുകളാണ്: ഒന്ന് ക്ലയന്റ് പൊതു വിലാസം വിശകലനം ചെയ്തു എന്നർത്ഥം, മറ്റൊന്ന് സ്വകാര്യ വിലാസം വിശകലനം ചെയ്ത ശേഷം സർട്ടിഫിക്കറ്റ് ഉൾക്കൊള്ളാത്ത ഒരു നാമം നൽകി എന്നർത്ഥം. താഴെയുള്ള പരിശോധനകൾ ക്രമത്തിൽ ചെയ്യുക, ആദ്യ പരാജയത്തിൽ നിർത്തുക, കാരണം ഒരു hosts എൻട്രിയോ കാഷ് ചെയ്ത ഉത്തരമോ തുടർന്നുള്ള ഓരോ പരിശോധനയും തെറ്റായ കാരണത്താൽ വിജയിപ്പിക്കാം. ഈ ക്രമം ഞാൻ എന്റെ VPN പ്രൊഫൈലുകൾക്കൊപ്പം ഒരു ടെക്സ്റ്റ് ഫയലിൽ സൂക്ഷിക്കുന്നു, കാരണം പരിഹാരം ടണലിൽ ഒന്നും മാറ്റുന്നില്ല, ക്ലയന്റ് അറിയുന്നതിൽ എല്ലാം മാറ്റുന്നു.

ക്ലയന്റിന് യഥാർത്ഥത്തിൽ ലഭിക്കുന്ന വിലാസത്തിൽ തുടങ്ങുക

ആപ്ലിക്കേഷനെ വിശ്വസിക്കുന്നതിനു പകരം റിസോൾവറിനോട് നേരിട്ട് ചോദിക്കുക. Windows-ൽ, nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net ക്ലയന്റിന് ഏത് കാഴ്ച ലഭിച്ചു എന്ന് കാണിക്കുന്നു. പൊതു ഉത്തരം എന്നാൽ താഴേക്ക് ഒന്നും എൻഡ്‌പോയിന്റിൽ എത്തില്ല; എൻഡ്‌പോയിന്റിന്റെ സ്വകാര്യ വിലാസം എന്നാൽ DNS കഴിഞ്ഞു, അടുത്ത പരിശോധന കണക്ഷൻ തന്നെയാണ്.

സ്വകാര്യ എൻഡ്‌പോയിന്റ് സേവനത്തിന്റെ പേര് മാറ്റുന്നില്ല. അക്കൗണ്ടോ ആപ്പോ അതിന്റെ സാധാരണ പൂർണ്ണ യോഗ്യതയുള്ള പേര് നിലനിർത്തുന്നു, എൻഡ്‌പോയിന്റ് വെർച്വൽ നെറ്റ്‌വർക്കിനുള്ളിലെ ക്ലയന്റുകൾക്ക് ആ പേര് വിശകലനം ചെയ്യുന്ന വിലാസം മാത്രം മാറ്റുന്നു. അതുകൊണ്ടാണ് അതേ ഹോസ്റ്റ്‌നെയിം നെറ്റ്‌വർക്കിലെ VM-ൽ നിന്ന് സ്വകാര്യമായും സ്വകാര്യ കാഴ്ച ലഭിക്കാത്ത ലാപ്‌ടോപ്പിൽ നിന്ന് പൊതുവായും വിശകലനം ചെയ്യുന്നത്.

ടണലിന് മുൻപ് സോൺ, അതിന്റെ ലിങ്ക്, റെക്കോർഡ് എന്നിവ പരിശോധിക്കുക

മൂന്ന് വ്യവസ്ഥകൾ ഒരുമിച്ച് പാലിക്കണം: സ്വകാര്യ സോൺ നിലവിലുണ്ട്, VPN ഗേറ്റ്‌വേയും ക്ലയന്റുകളും Azure-ലേക്ക് പ്രവേശിക്കുന്ന വെർച്വൽ നെറ്റ്‌വർക്കിലേക്ക് അത് ലിങ്ക് ചെയ്തിരിക്കുന്നു, അതിൽ എൻഡ്‌പോയിന്റിനായി സ്വകാര്യ വിലാസത്തിലേക്ക് ചൂണ്ടുന്ന A റെക്കോർഡ് ഉണ്ട്. സോൺ ബന്ധമില്ലാത്ത നെറ്റ്‌വർക്കിലേക്ക് ലിങ്ക് ചെയ്താൽ ഗേറ്റ്‌വേ പൊതു റെക്കോർഡ് വിശകലനം ചെയ്യുന്നത് തുടരും, ടണലിലെ എല്ലാം ആരോഗ്യകരമായി കാണപ്പെടും.

സോൺ നാമങ്ങൾ സേവനങ്ങളുടേതാണ്, പൊതുവായി സ്വകാര്യ ലിങ്കുകളുടേതല്ല. App Service സാധാരണയായി privatelink.azurewebsites.net ഉപയോഗിക്കുന്നു, സ്‌റ്റോറേജിനും SQL-നും സ്വന്തം നെയിംസ്‌പേസുകളുണ്ട്, മറ്റൊരു സേവനത്തിന്റെ സോൺ കടം വാങ്ങിയാൽ നിലവിലുള്ളതും എന്നാൽ ഉപയോഗപ്രദമായി ഒന്നും ഉത്തരം നൽകാത്തതുമായ സോൺ ഉണ്ടാകും.

ക്ലയന്റിന് യഥാർത്ഥത്തിൽ എത്തിച്ചേരാവുന്ന ഒരു റിസോൾവർ നൽകുക

168.63.129.16 Azure വെർച്വൽ മെഷീനുകളിൽ നിന്ന് ഉത്തരം നൽകുന്നു, point-to-site ടണലിന്റെ മറുവശത്തുള്ള ലാപ്‌ടോപ്പിനുള്ള DNS സെർവറല്ല. ക്ലയന്റിന് ടണലിലൂടെ എത്തിച്ചേരാവുന്ന റിസോൾവർ വേണം: Azure DNS Private Resolver-ന്റെ ഇൻബൗണ്ട് എൻഡ്‌പോയിന്റ്, വെർച്വൽ നെറ്റ്‌വർക്കിനുള്ളിലെ ഫോർവേഡർ, അല്ലെങ്കിൽ VPN ക്ലയന്റ് പ്രൊഫൈലിൽ കൊണ്ടുപോകുന്ന DNS സെർവർ എൻട്രികൾ, അതുവഴി ക്ലയന്റ് വെർച്വൽ നെറ്റ്‌വർക്കിനോട് നേരിട്ട് ചോദിക്കും.

കോൺഫിഗർ ചെയ്തതെങ്കിലും എത്തിച്ചേരാനാകാത്ത റിസോൾവർ റിസോൾവർ ഇല്ലാത്തതുപോലെ തന്നെ പ്രവർത്തിക്കുന്നു, ലക്ഷണം തെറ്റായ ഉത്തരമല്ല, ടൈംഔട്ടാണ്, അതുകൊണ്ടാണ് ഇതിനെ ഫയർവാൾ പ്രശ്നമായി തെറ്റായി വായിക്കുന്നത്. ടണൽ കൊണ്ടുപോകേണ്ട ഒരു ക്വറിയിൽ പരീക്ഷിക്കുക, ലോക്കൽ ലിങ്കിലൂടെ എന്തായാലും വിജയിക്കുമായിരുന്ന പൊതു നാമത്തിൽ അല്ല.

സെറ്റിംഗുകൾ തള്ളുന്നതിനു പകരം ഫോർവേഡ് ചെയ്യുന്നുവെങ്കിൽ, സ്വകാര്യ സോണിന് ഉള്ള നെയിംസ്‌പേസ് ഫോർവേഡ് ചെയ്യുക, മുഴുവൻ azurewebsites.net-ന് പകരം privatelink.azurewebsites.net. മുഴുവൻ പേരന്റ് സഫിക്സും വിഴുങ്ങുന്ന കണ്ടീഷണൽ ഫോർവേഡർ സേവനത്തിന്റെ എല്ലാ തിരച്ചിലുകളും Azure-ലേക്ക് അയയ്ക്കുന്നു, ലോക്കലായി നിലനിൽക്കേണ്ടവ ഉൾപ്പെടെ.

സർട്ടിഫിക്കറ്റ് നൽകിയ നാമം ഉപയോഗിക്കുക

വിലാസം ശരിയാകുമ്പോൾ രണ്ടാം തകരാർ പുറത്തുവരുന്നു. സ്‌റ്റോറേജും App Service-ഉം privatelink അലിയാസ് പ്രസിദ്ധീകരിക്കുന്നു, ആ അലിയാസ് സർട്ടിഫിക്കറ്റിലെ നാമമായിരിക്കണമെന്നില്ല. privatelink.blob.core.windows.net-ലേക്കുള്ള AzCopy അപ്‌ലോഡ് സാധുതാ പരിശോധനയിൽ പരാജയപ്പെട്ടു; അതേ അപ്‌ലോഡ് <account>.blob.core.windows.net/<container>-ലേക്ക് സ്വകാര്യ വിലാസത്തിലേക്ക് വിശകലനം ചെയ്ത് വിജയിച്ചു, അതിനാൽ ഒരു ബൈപാസും ഇല്ലാതെ സ്വകാര്യ പാതയിൽ തുടർന്നു.

നിയമം ബ്രൗസറിലും App Service-നും ബാധകമാണ്: സർട്ടിഫിക്കറ്റ് ഉൾക്കൊള്ളുന്ന ഹോസ്റ്റ്‌നെയിമിനൊപ്പം ബന്ധിപ്പിക്കുക, സ്വകാര്യ വിലാസം DNS നൽകട്ടെ. സാധുതാ പരിശോധന ഒഴിവാക്കാൻ മുതിരരുത്, അത് നാമകരണ പിശകിനെ സുരക്ഷാ പിന്നോട്ടുപോക്കാക്കി മാറ്റുന്നു. വിജയകരമായ ping പാത തെളിയിക്കുന്നു, ഹാൻഡ്‌ഷെയ്ക്കിനുള്ളിലെ നാമത്തെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, അതുകൊണ്ടാണ് ഇവ വെവ്വേറെ പരിശോധനകളായി തുടരുന്നത്.

ഓരോ പാളിയെയും വേർതിരിക്കുന്ന നാല് ഘട്ട ക്രമം

1. VPN ക്ലയന്റിന് point-to-site പൂളിൽ നിന്നുള്ള വിലാസവും എൻഡ്‌പോയിന്റിന്റെ സ്വകാര്യ വിലാസത്തിലേക്കുള്ള റൂട്ടും ഉണ്ടെന്ന് ഉറപ്പാക്കുക.
2. ആപ്പ് ഉപയോഗിക്കുന്ന കൃത്യമായ നാമം വിശകലനം ചെയ്യുക, ഉത്തരം എൻഡ്‌പോയിന്റിന്റെ വിലാസവുമായി താരതമ്യം ചെയ്യുക.
3. സേവന പോർട്ടിൽ എൻഡ്‌പോയിന്റിലേക്ക് TCP കണക്ഷൻ തുറക്കുക, തുടർന്ന് ആ കണക്ഷനിൽ അവതരിപ്പിച്ച സർട്ടിഫിക്കറ്റ് നാമം വായിക്കുക.
4. ഇപ്പോൾ മാത്രം അധികാരപരിശോധന പരീക്ഷിക്കുക, പ്രവർത്തിക്കുന്ന പാതയും സാധുവായ സർട്ടിഫിക്കറ്റും ഇപ്പോഴും വിഭവത്തിലേക്ക് പ്രവേശനം നൽകുന്നില്ല.

വിലാസം ശരിയായിരിക്കെ നിരസിക്കപ്പെട്ട കണക്ഷൻ DNS-ലേക്കല്ല, നെറ്റ്‌വർക്ക് സുരക്ഷാ ഗ്രൂപ്പിലേക്കോ സ്വകാര്യ എൻഡ്‌പോയിന്റ് കണക്ഷൻ അവസ്ഥയിലേക്കോ ചൂണ്ടുന്നു, അതിനാൽ റിസോൾവർ ക്രമീകരണങ്ങൾ വീണ്ടും തിരുത്തുന്നതിന് മുൻപ് അവ പരിശോധിക്കുക. TLS നാമ പൊരുത്തക്കേട് നിങ്ങളെ URL-ലെ ഹോസ്റ്റ്‌നെയിമിലേക്കും സർട്ടിഫിക്കറ്റിന്റെ subject-ലേക്കും തിരികെ അയയ്ക്കുന്നു. വിശകലന ഔട്ട്‌പുട്ട്, സർട്ടിഫിക്കറ്റ് നാമം, കൃത്യമായ URL എന്നിവ ഒരുമിച്ച് സൂക്ഷിക്കുക; ഈ മൂന്ന് മൂല്യങ്ങൾ ഗേറ്റ്‌വേ തൊടാതെ ഈ കേസുകളിൽ ഭൂരിഭാഗവും വിശദീകരിക്കുന്നു.

നിയന്ത്രണമായി വെർച്വൽ നെറ്റ്‌വർക്കിനുള്ളിലെ ഒരു VM ഉപയോഗിക്കുക. നാമം അവിടെ സ്വകാര്യമായും ടണലിൽ നിന്ന് പൊതുവായും വിശകലനം ചെയ്യുന്നുവെങ്കിൽ സോണും റെക്കോർഡും ശരിയാണ്, ഏക വ്യത്യാസം ക്ലയന്റിന്റെ റിസോൾവർ പാതയാണ്, അത് എൻഡ്‌പോയിന്റ് കോൺഫിഗറേഷനിൽ ഒരു റൗണ്ട് കൂടി നോക്കുന്നതിനേക്കാൾ വേഗത്തിൽ സ്ഥിരീകരിക്കാം.

ക്ലയന്റുകളും കാഷ് ചെയ്യുന്നു. പത്ത് മിനിറ്റ് മുൻപ് പൊതുവായി ഉത്തരം നൽകിയ റെക്കോർഡ് സോൺ ശരിയാക്കിയ ശേഷവും ഉത്തരം നൽകുന്നു, അതിനാൽ വീണ്ടും പരീക്ഷിക്കുന്നതിന് മുൻപ് കാഷ് ശൂന്യമാക്കുക. Windows-ൽ, ipconfig /flushdns ക്ലയന്റ് കാഷ് മായ്ക്കുന്നു; നാമ വിശകലന നയ നിയമങ്ങൾ നിലനിൽക്കുന്നു, ഏത് സഫിക്സ് ഏത് സെർവറിലേക്ക് പോകുന്നു എന്ന് തീരുമാനിക്കുന്നു, നിങ്ങൾ ഇപ്പോൾ മാറ്റിയ റിസോൾവറിലേക്ക് നെയിംസ്‌പേസ് അയയ്ക്കുന്നത് തുടരാം.

hosts എൻട്രി എവിടെ വേണം

എൻഡ്‌പോയിന്റ് വിലാസം hosts ഫയലിൽ ചേർക്കുന്നത് നല്ല രോഗനിർണയവും മോശം രൂപകൽപ്പനയുമാണ്. നാമം-വിലാസ മാപ്പിംഗാണ് കാണാത്ത ഭാഗം എന്ന് അത് തെളിയിക്കുന്നു, ആ ഘട്ടത്തിന് ശേഷമുള്ള എല്ലാം പരീക്ഷിക്കാൻ അനുവദിക്കുന്നു, പക്ഷേ അത് നിങ്ങളുടെ ഉപയോക്താക്കൾക്ക് അദൃശ്യമാണ്, എൻഡ്‌പോയിന്റ് വിലാസം മാറുമ്പോൾ തകരുന്നു, ഉത്തരം നൽകേണ്ട സോണിനെ മറയ്ക്കുന്നു.

അവശേഷിക്കുന്ന പരീക്ഷണ എൻട്രി പഴയ കാഷിനെക്കാൾ മോശമാണ്, കാരണം പിശകിന്റെ ദിശ അനുസരിച്ച് അത് ശരിയാക്കിയ പാതയെ തകർന്നതായോ തകർന്ന പാതയെ ശരിയാക്കിയതായോ കാണിക്കാം. അവസാന റണ്ണിന് മുൻപ് അത് നീക്കം ചെയ്യുക, ഉത്പാദന റിസോൾവർ ഉപയോഗിച്ച് മാത്രം വിശകലനം ചെയ്യുക.

ചെറിയ നാമങ്ങൾക്ക് തിരയൽ സഫിക്സ് ആവശ്യമാണ്, പൂർണ്ണ യോഗ്യതയുള്ള നാമങ്ങൾക്ക് ആവശ്യമില്ല, അതിനാൽ ആദ്യം പൂർണ്ണ യോഗ്യതയുള്ള നാമം പരീക്ഷിക്കുക, തുടർന്ന് വർക്ക്ഫ്ലോയ്ക്ക് ക്ലയന്റ് പ്രൊഫൈലിലൂടെ തള്ളുന്ന സഫിക്സ് വേണോ എന്ന് തീരുമാനിക്കുക. Microsoft തന്റെ സ്വകാര്യ എൻഡ്‌പോയിന്റ് DNS മാർഗ്ഗനിർദ്ദേശങ്ങളിൽ ഓരോ സേവനത്തിനുമുള്ള സോൺ നാമങ്ങളും റെക്കോർഡ് രൂപങ്ങളും രേഖപ്പെടുത്തുന്നു; മറ്റൊരു സേവനത്തിൽ നിന്ന് സോൺ പകർത്തുന്നതിനു പകരം നിങ്ങളുടെ സേവനത്തിന്റെ എൻട്രി വായിക്കുക.