Windows-ൽ VPN പിശക് 720: വിലാസ പൂൾ അല്ലെങ്കിൽ ക്ലയന്റ് ബൈൻഡിംഗ്?
പിശക് 720 എന്നാൽ കണക്ഷന് ഒരിക്കലും ഉപയോഗയോഗ്യമായ വിലാസം ലഭിച്ചില്ല എന്നാണ്. അഡാപ്റ്റർ വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്നതിന് മുമ്പ് ഒരു ഹോസ്റ്റിലെ പരാജയങ്ങളെ പല ഹോസ്റ്റുകളിലെ പരാജയങ്ങളിൽ നിന്ന് വേർതിരിക്കുക.
പിശക് 720 ക്രെഡൻഷ്യലുകൾ സ്വീകരിച്ചതിന് ശേഷം പ്രത്യക്ഷപ്പെടുന്നു, അതുകൊണ്ടാണ് ഇത് ആളുകളെ പാസ്‌വേഡ് ഫീൽഡിലേക്ക് തിരികെ അയയ്ക്കുന്നത്. ഒരു വിലാസത്തെക്കുറിച്ച് ചർച്ച നടക്കുന്ന ഘട്ടത്തിലെത്തി കണക്ഷന് ഒന്നും ലഭിച്ചില്ല. രണ്ട് തികച്ചും വ്യത്യസ്തമായ പരാജയങ്ങൾ ഒരേ സംഭാഷണം സൃഷ്ടിക്കുന്നു: സെർവറിന് വിതരണം ചെയ്യാൻ ഒന്നുമില്ലായിരുന്നു, അല്ലെങ്കിൽ ഈ ക്ലയന്റിന് ചർച്ച പൂർത്തിയാക്കാൻ കഴിഞ്ഞില്ല. എന്തെങ്കിലും സ്പർശിക്കുന്നതിന് മുമ്പ് ഇവ രണ്ടും വേർതിരിക്കുന്നതാണ് പരിഹാരത്തിന്റെ ഭൂരിഭാഗം, ഈ വ്യത്യാസം Microsoft-ന്റെ പിശക് 720 പ്രശ്നപരിഹാര പേജിൽ രേഖപ്പെടുത്തിയിട്ടുണ്ട്.
സംഭാഷണം പറയാത്തത്
സന്ദേശം PPP ചർച്ചയിലെ പരാജയം വിവരിക്കുന്നു, സെർവർ എന്തുകൊണ്ട് നിരസിച്ചുവെന്ന് ക്ലയന്റിന് കാണാൻ കഴിയാത്തതിനാൽ ഇത് ബോധപൂർവ്വം അവ്യക്തമാണ്. ഇത് ക്രെഡൻഷ്യലുകളുടെ പിശകല്ല, ടണലിന്റെ എൻക്രിപ്ഷനെക്കുറിച്ചുള്ള പ്രസ്താവനയുമല്ല. വിലാസമോ ചർച്ചാ പാരാമീറ്ററുകളോ എത്തിച്ചില്ല എന്നാണ് അർത്ഥം.
സെർവർ ഭാഗത്ത് സാധാരണ കാരണം അനുവദനമാണ്: ഒഴിവുള്ള വിലാസങ്ങളില്ലാത്ത സ്ഥിര RRAS പൂൾ, അല്ലെങ്കിൽ പരിധി തീർന്നതോ എത്തിച്ചേരാൻ കഴിയാത്തതോ ആയ DHCP കോൺഫിഗറേഷൻ, ശ്രമിക്കുന്ന ഓരോ ക്ലയന്റിലും കൃത്യമായി ഈ ലക്ഷണം ഉണ്ടാക്കുന്നു. ക്ലയന്റ് ഭാഗത്ത് സാധാരണ കാരണം ബൈൻഡിംഗാണ്. PPP വഹിക്കുന്ന WAN Miniport ശരിയായ ഘടകങ്ങളുമായി ബന്ധിപ്പിച്ചിരിക്കണം, പ്രവർത്തനരഹിതമായ ബൈൻഡിംഗോ ചേർത്ത നെറ്റ്‌വർക്ക് ഫിൽട്ടറോ ഏതെങ്കിലും ദൃശ്യ ഉപകരണ പ്രശ്നമില്ലാതെ ചർച്ച നിർത്താം. ഈ രണ്ട് കുടുംബങ്ങൾക്ക് വ്യത്യസ്ത തെളിവുകൾ വേണം, അവയ്ക്കിടയിൽ തിരഞ്ഞെടുക്കാനുള്ള വേഗമേറിയ മാർഗം എത്ര ക്ലയന്റുകൾ ബാധിക്കപ്പെട്ടു എന്ന് എണ്ണുന്നതാണ്.
ആദ്യം ജനസംഖ്യ വേർതിരിക്കുക, പിന്നെ പൂൾ
ഏതെങ്കിലും കോൺഫിഗറേഷൻ വായിക്കുന്നതിന് മുമ്പ് ബാധിക്കപ്പെട്ട ക്ലയന്റുകൾ എണ്ണുക. എല്ലാവരെയും ഒരുമിച്ച് ബാധിക്കുന്ന പരാജയം സെർവർ അവസ്ഥയാണ്, ഒരു യന്ത്രത്തെ നെറ്റ്‌വർക്കുകൾക്കിടയിൽ പിന്തുടരുന്ന പരാജയം ക്ലയന്റ് അവസ്ഥയാണ്. ആ എണ്ണം ഒരു ചാറ്റ് ചാനലിൽ ഒരു സന്ദേശത്തിന്റെ വിലയേ ഉള്ളൂ, ഒരു ഉച്ചയ്ക്ക് ലാഭിക്കുന്നു.
| Artifact | How you get it | What it rules out | What it cannot rule out |
|---|---|---|---|
| Affected-client count | One message to the people who failed, or a search of today's tickets | A client-only fault, when every client failed within minutes | Which server-side component stopped allocating |
| RRAS event for one attempt | Get-WinEvent on the System log, filtered to the allocation event id | An allocation failure, when no event matches that attempt | A binding fault that appears later in the same negotiation |
| Hidden WAN Miniport bindings | Get-NetAdapter with hidden adapters, then the binding list on the returned name | A disabled ms_wanarp binding or an inserted filter on this client | Pool exhaustion that would also have hit other clients |
| Free-address count | The RRAS pool view, or the DHCP scope statistics | A committed static range or an exhausted scope | Why the address was not delivered to one specific client |
പിന്നീട് ഒരു പരാജയപ്പെട്ട ശ്രമത്തെ സെർവറിന്റെ സ്വന്തം രേഖയുമായി ബന്ധിപ്പിക്കുക, കാരണം RRAS അനുവദിക്കാൻ കഴിയാത്തപ്പോൾ ഒരു സംഭവം രേഖപ്പെടുത്തുന്നു, ആ സംഭവം ലക്ഷണത്തെയല്ല പരാജയത്തെയാണ് പേരിടുന്നത്. പരാജയം ഒരു നിർദ്ദിഷ്ട ക്ലയന്റിനെ പിന്തുടരുന്നുവെങ്കിൽ, സെർവർ ലോഗ് ആ ശ്രമത്തിന് ഒന്നും കാണിക്കില്ല, അത് തന്നെ വിവരപ്രദമാണ്. അനുവദന പിശക് ഇല്ലാതിരിക്കുന്നത് പ്രശ്നം ആ ക്ലയന്റിലെ ചർച്ചയിലേക്ക് ചുരുക്കുകയും അടുത്തതായി ഏത് കമാൻഡുകൾ പ്രവർത്തിപ്പിക്കണം എന്ന് പറയുകയും ചെയ്യുന്നു.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }സെർവറിന്റെ അനുവദന സ്ഥിതി വായിക്കുക
RRAS ഭാഗത്ത് ഡോക്യുമെന്റേഷൻ അനുമാനിക്കുന്നതല്ല, യഥാർത്ഥത്തിൽ ഏത് അനുവദന രീതിയാണ് കോൺഫിഗർ ചെയ്തിരിക്കുന്നതെന്ന് സ്ഥിരീകരിക്കുക. സ്ഥിര പൂളും DHCP വഴി അയയ്ക്കുന്ന കോൺഫിഗറേഷനും വ്യത്യസ്ത രീതികളിൽ പരാജയപ്പെടുന്നു, തിരുത്തൽ ഉപയോഗത്തിലുള്ളതിനാണ്. സ്ഥിര പൂളിൽ ഒഴിവുള്ള വിലാസങ്ങൾ എണ്ണി, ആർക്കും ഓർമ്മയില്ലാത്ത പാട്ടം കൈവശം വയ്ക്കുന്ന ഉപയോക്താവ് തിരിച്ചുള്ള അനുവദനങ്ങൾ അന്വേഷിക്കുക, കാരണം വലുതായി തോന്നുന്ന പൂൾ പൂർണ്ണമായി നിറഞ്ഞിരിക്കാം. DHCP-യിൽ റിലേ ഒരു സെർവറിൽ എത്തുന്നുണ്ടോ, പരിധിയിൽ ഒഴിവുള്ള പാട്ടങ്ങൾ ഉണ്ടോ എന്ന് പരിശോധിക്കുക.
സാധാരണ ക്ലയന്റുകൾ തീർത്ത പരിധി തെറ്റായി കോൺഫിഗർ ചെയ്ത പൂളിനെപ്പോലെ അതേ 720 ഉത്പാദിപ്പിക്കുന്നു, RRAS കൺസോൾ രണ്ട് സന്ദർഭങ്ങളിലും തികച്ചും ആരോഗ്യകരമായി കാണപ്പെടും. പൂൾ ചെറിയ പരിധികളായി വിഭജിക്കുന്ന പാരമ്പര്യ പരിഹാരത്തെ എതിർക്കുക: യഥാർത്ഥ ഉപദേശം ഒരു അഡ്മിനിസ്ട്രേറ്ററുടെ ഫലം വിവരിച്ചിരുന്നു, സെർവറിന്റെ സ്വന്തം സംഭവങ്ങൾക്ക് നേരിട്ട് പേരിടാൻ കഴിയുന്ന അനുവദന പരാജയം അത് പരിഹരിക്കുന്നില്ല.
ക്ലയന്റിന്റെ ബൈൻഡിംഗുകൾ തകർക്കാതെ വായിക്കുക
തെളിവുകൾ ഒരു ക്ലയന്റിനെ ചൂണ്ടിക്കാണിക്കുന്നുവെങ്കിൽ, സ്റ്റാക്ക് വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്നതിന് പകരം മറഞ്ഞിരിക്കുന്ന അഡാപ്റ്റർ പരിശോധിക്കുക. ആദ്യ കമാൻഡ് WAN Miniport ഇന്റർഫേസുകളും അവയുടെ പേരുകളും ലിസ്റ്റ് ചെയ്യുന്നു; രണ്ടാമത്തേത് അത് തിരികെ നൽകിയ പേര് എടുക്കുന്നു, ഒരു ഗൈഡിൽ നിന്ന് പകർത്തിയ പേരല്ല.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsലിസ്റ്റ് വിലാസ പരിഹാര ബൈൻഡിംഗിനും തൃതീയ കക്ഷി ഫിൽട്ടറുകൾക്കുമായി വായിക്കുക. പ്രവർത്തനരഹിതമായ ബൈൻഡിംഗ് ലക്ഷ്യബോധത്തോടെയുള്ള പരിഹാരമാണ്, എന്നാൽ ഒരു ഫിൽട്ടറിന്റെ സാന്നിധ്യം ആ സോഫ്റ്റ്‌വെയറിന്റെ ഉടമസ്ഥനോടുള്ള ചോദ്യമാണ്, സുരക്ഷാ ഉൽപ്പന്നം പ്രവർത്തനരഹിതമാക്കാനുള്ള അനുമതിയല്ല. എല്ലാ അഡാപ്റ്ററുകളും ഇല്ലാതാക്കുന്നതാണ് പരാജയം തിരികെ വന്നാൽ ആവശ്യമായ തെളിവുകൾ നശിപ്പിക്കുന്ന ഒരേയൊരു നടപടി.
തിരുത്തലിന് ശേഷം അതേ പ്രൊഫൈൽ വീണ്ടും ശ്രമിക്കുക, അത് യഥാർത്ഥ ലക്ഷണമായിരുന്നെങ്കിൽ രണ്ട് ക്ലയന്റ് കേസ് ആവർത്തിക്കുക, കാരണം വിജയകരമായ ആദ്യ കണക്ഷൻ രണ്ടാം ക്ലയന്റ് വെളിപ്പെടുത്തുന്ന അനുവദന പ്രശ്നം മറയ്ക്കുന്നു. കുറിപ്പ് നാല് ഫീൽഡുകളിൽ സൂക്ഷിക്കുക: ഏത് ക്ലയന്റ്, ഏത് ബൈൻഡിംഗ്, ഏത് സംഭവം, എന്ത് മാറി. ഓരോ ശ്രമത്തിലും ഒരു പാളി മാറ്റുക, കാരണം ക്ലയന്റ് തിരുത്തലും പൂൾ മാറ്റവും ഒരുമിച്ച് പ്രയോഗിച്ചാൽ അവ ആരോപിക്കാൻ കഴിയില്ല, അടുത്ത പരാജയം അതുതന്നെയാണെങ്കിലും പുതിയതായി തോന്നും.