PPTP പാസ്ത്രൂ ഇല്ല: Windows VPN പിശക് 807 പരിഹരിക്കുക

TCP 1723 ഫോർവേഡ് ചെയ്യുന്നത് പലപ്പോഴും PPTP യുടെ ആദ്യ ഭാഗം തുറക്കുകയും ബാക്കി പൊട്ടിയ നിലയിൽ വിടുകയും ചെയ്യുന്നു, അതിനാൽ ശ്രമിക്കുമ്പോൾ Windows ഇപ്പോഴും പിശക് 807 നൽകുന്നു. അടുത്ത പ്രവണത പോർട്ട് 47 ന് ഒരു നിയമം ചേർക്കുക എന്നതാണ്, ആ ഘട്ടം തന്നെയാണ് ഒരു ഉച്ചയ്ക്ക് ശേഷം പാഴാക്കുന്നത്: GRE എന്നത് IP ഹെഡറിലെ ഒരു പ്രോട്ടോക്കോൾ നമ്പറാണ്, ഫോർവേഡിംഗ് ടേബിളിന് ഒത്തുനോക്കാൻ കഴിയുന്ന പോർട്ടല്ല. റൂട്ടർ പ്രോട്ടോക്കോൾ 47 കടത്തിവിട്ട് അതിനെ അതേ കോളുമായി ബന്ധിപ്പിക്കുന്നതുവരെ ടണൽ തുടങ്ങാനാവില്ല. താഴെയുള്ള ഭാഗങ്ങൾ രണ്ട് ചാനലുകളെ വേർതിരിച്ച് പിന്നീട് ഓരോന്നായി പരിശോധിക്കുന്നു.

പോർട്ട് ടേബിളിൽ പ്രോട്ടോക്കോൾ നമ്പറിന് ഒരു വരി ഇല്ല

PPTP വ്യത്യസ്ത രീതികളിൽ പരാജയപ്പെടുന്ന രണ്ട് സംഭാഷണങ്ങൾ ഉപയോഗിക്കുന്നു. TCP 1723 ലേത് കോൾ ആരംഭിച്ച് ലിങ്ക് വിവരങ്ങൾ കൈമാറി ഉപയോക്താവ് വിച്ഛേദിക്കുമ്പോൾ അത് അവസാനിപ്പിക്കുന്നു. പേലോഡ് ഭാഗം GRE യുടെ ഉള്ളിൽ പ്രവർത്തിക്കുന്നു, അതിനെ IP ഹെഡർ പ്രോട്ടോക്കോൾ നമ്പർ 47 കൊണ്ട് അടയാളപ്പെടുത്തുന്നു, ആ ടണലിനുള്ളിൽ PPP ലിങ്കിനെക്കുറിച്ച് ചർച്ച ചെയ്യുമ്പോൾ MS-CHAPv2 ക്രെഡൻഷ്യലുകൾ പരിശോധിക്കുന്നു.

GRE ഒരു ട്രാൻസ്പോർട്ട് ഹെഡറും വഹിക്കാത്തതിനാൽ അത് പോർട്ടുകളൊന്നും വെളിപ്പെടുത്തുന്നില്ല, അതിനാൽ പോർട്ടുകൾക്കായി എഴുതിയ നിയമത്തിന് ഒത്തുനോക്കാൻ ഒന്നുമില്ല. 1723 ഫോർവേഡ് ചെയ്യുന്ന റൂട്ടർ ആ TCP സെഷന് ഒരു മാപ്പിംഗ് സൃഷ്ടിച്ച് അവിടെ നിൽക്കുന്നു. രണ്ടാം പകുതി കൈകാര്യം ചെയ്യുന്ന ഫേംവെയർ ഈ സൗകര്യത്തെ PPTP പാസ്ത്രൂ അല്ലെങ്കിൽ PPTP ALG എന്ന് വിളിക്കുന്നു, ചില ഫേംവെയറുകൾ രണ്ടും വാഗ്ദാനം ചെയ്യാതെ ആ വിടവ് ഒരിക്കലും പരാമർശിക്കുന്നുമില്ല. ചെക്ക്ബോക്സിലെ ലേബലിനെക്കാൾ പ്രധാനം പ്രോട്ടോക്കോൾ 47 എങ്കിലും തിരിച്ചറിയപ്പെടുന്നുണ്ടോ എന്നതാണ്.

ഡാറ്റാ പാത മരിക്കുമ്പോൾ Windows എന്ത് റിപ്പോർട്ട് ചെയ്യുന്നു

പിശക് 807 കണക്ഷൻ പൂർത്തിയാക്കാനായില്ല എന്ന് പറയുന്നു, പ്രായോഗികമായി കോൾ സെർവറിലെത്തി ഡാറ്റാ ചാനൽ ഉയർന്നില്ല എന്നാണ് അതിന്റെ അർഥം. ഇത് ഗതാഗതത്തെക്കുറിച്ചുള്ള വിധിയാണ്, അക്കൗണ്ടിനെക്കുറിച്ചുള്ളതല്ല. ക്രെഡൻഷ്യലുകളിലേക്കോ ഓതന്റിക്കേഷൻ പ്രോട്ടോക്കോളിന്റെ പൊരുത്തക്കേടിലേക്കോ വിരൽ ചൂണ്ടുന്നത് പിശക് 691 ആണ്, അതിനാൽ അത് നിങ്ങളെ തികച്ചും മറ്റൊരിടത്തേക്ക് അയക്കുന്നു.

പാസ്വേഡിൽ തൊടുന്നതിന് മുമ്പ് ഗതാഗതത്തിൽ പ്രവർത്തിക്കുക. 807 ന് പിന്നാലെ ക്രെഡൻഷ്യലുകൾ മാറ്റുന്നത് യഥാർത്ഥ തകരാർ അതിന്റെ സ്ഥാനത്ത് നിർത്തുകയും അടുത്ത ശ്രമം വായിക്കാൻ ബുദ്ധിമുട്ടാക്കുകയും ചെയ്യുന്നു.

രണ്ടാമത്തെ ക്ലയന്റ് പ്രവർത്തിക്കുന്ന ടണൽ എന്തുകൊണ്ട് തകർക്കുന്നു

അവയെ വേർതിരിക്കാൻ പോർട്ടുകൾ ഇല്ലാത്തതിനാൽ, NAT ഉപകരണത്തിന് രണ്ട് HTTPS സെഷനുകളെ വേർതിരിക്കുന്നതുപോലെ രണ്ട് PPTP ക്ലയന്റുകളെ വേർതിരിക്കാനാവില്ല. അതിനാൽ പല ഉപഭോക്തൃ ഉപകരണങ്ങളും ഒരു PPTP കോൾ മാത്രം അനുവദിച്ച് അത് ഉറവിട വിലാസം പ്രകാരം ട്രാക്ക് ചെയ്യുന്നു. ഒറ്റയ്ക്ക് പ്രവർത്തിച്ചിരുന്ന ലാപ്ടോപ്പ് രണ്ടാമത്തെ യന്ത്രം ഡയൽ ചെയ്യുമ്പോൾ പൂർത്തിയാക്കുന്നത് നിർത്തുന്നു, ക്ലയന്റ് ഭാഗത്തുനിന്ന് പരാജയം യാദൃച്ഛികമായി തോന്നുന്നു. ഈ മാതൃക ഫേംവെയറിന്റേതാണ്, ഒരു പ്രൊഫൈൽ മാറ്റവും അത് മാറ്റില്ല.

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

ഏത് പകുതിയാണ് പരാജയപ്പെടുന്നതെന്ന് തെളിയിക്കുക

റൂട്ടറിൽ എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് TCP 1723 എത്തുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക, കാരണം ആ ഉത്തരമാണ് നിങ്ങൾ ഏത് പകുതി പരിശോധിക്കുന്നു എന്ന് തീരുമാനിക്കുന്നത്. ഇവ Windows ക്ലയന്റിൽ നിന്ന് നിങ്ങളുടെ സ്വന്തം സെർവർ നാമത്തിനെതിരെ പ്രവർത്തിപ്പിക്കുക. ആദ്യത്തേത് പോർട്ട് ഉത്തരം നൽകിയോ എന്ന് പ്രിന്റ് ചെയ്യുന്നു, രണ്ടാമത്തേത് സംഭാഷണമില്ലാതെ ഡയൽ ചെയ്യുന്നു, ഇത് ആവർത്തിച്ചുള്ള ശ്രമങ്ങളെ താരതമ്യപ്പെടുത്താനാകുന്നതാക്കുന്നു.

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

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

tcpdump -ni any proto 47

Wireshark ലെ തത്തുല്യം ഡിസ്പ്ലേ ഫിൽട്ടർ ip proto 47 ആണ്, കമാൻഡ് ലൈനിൽ സുഖമില്ലാത്ത ഒരാൾക്ക് അത് കൈമാറാൻ എളുപ്പമാണ്. മറുപടിയിൽ ഒന്നും പുറത്തുപോകാതെ GRE വന്നാൽ തിരിച്ചുള്ള പാത ശരിയാക്കണം എന്നാണ് അർഥം.

പിശക് യഥാർത്ഥത്തിൽ പരിഹരിക്കുന്നത് എന്താണ്

റൂട്ടർ ക്രമീകരണം കാണിക്കുന്നിടത്ത് PPTP പാസ്ത്രൂ പ്രവർത്തനക്ഷമമാക്കുക, അല്ലെങ്കിൽ നിയമങ്ങൾ സ്വീകരിക്കുന്ന ഫേംവെയറിൽ പ്രോട്ടോക്കോൾ 47 വ്യക്തമായി അനുവദിക്കുക. RouterOS ൽ ഫോർവേഡിംഗ് നിയമം നേരിട്ട് പ്രോട്ടോക്കോളുമായി ഒത്തുപോകുന്നു, പോർട്ട് അടിസ്ഥാനമാക്കിയ ഫോർവേഡിംഗിന് അത് ഒരിക്കലും ചെയ്യാനാവില്ലായിരുന്നു. ഉപഭോക്തൃ ഫേംവെയർ സാധാരണയായി അതേ തീരുമാനം ഒരു ചെക്ക്ബോക്സിന് പിന്നിൽ ഒളിപ്പിക്കുന്നു, ചിലപ്പോൾ പോർട്ട് ഫോർവേഡിംഗിന് പകരം സുരക്ഷാ ക്രമീകരണങ്ങൾക്ക് കീഴിൽ. അത്തരം നിയന്ത്രണം ഇല്ലെങ്കിൽ, ക്ലയന്റിൽ ഒന്നും അത് നികത്തില്ല.

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

PPTP മാറ്റിസ്ഥാപിക്കുന്നത് മറ്റൊരു ഓപ്ഷനാണ്, പലപ്പോഴും വിലകുറഞ്ഞത്. VPN സ്വയം അവസാനിപ്പിക്കുന്ന റൂട്ടർ വരുന്ന ക്ലയന്റുകൾക്ക് ഇരട്ട NAT ഒഴിവാക്കുന്നു, പോർട്ട് അടിസ്ഥാനമാക്കിയ NAT ഇതിനകം കൈകാര്യം ചെയ്യുന്ന പ്രോട്ടോക്കോളിന് പാസ്ത്രൂ ആവശ്യമില്ല: UDP യിൽ OpenVPN, TCP 443 ൽ SSTP, അല്ലെങ്കിൽ ESP യെ UDP 4500 നുള്ളിൽ പൊതിയുന്ന NAT-T യോടെ L2TP/IPsec. PPTP MS-CHAPv2 യെയും ആശ്രയിക്കുന്നു, അതിന്റെ രേഖപ്പെടുത്തിയ ദൗർബല്യങ്ങൾ പിശക് മാറിയതിനുശേഷവും പുതിയ വിന്യാസത്തിന് അതിനെ മോശം തിരഞ്ഞെടുപ്പാക്കുന്നു.

ഏത് നിയമമാണ് വ്യത്യാസം ഉണ്ടാക്കിയതെന്ന് എഴുതിവയ്ക്കുക, രണ്ടാമത്തെ ഉപയോക്താവ് പ്രവേശനം ആവശ്യപ്പെടുമ്പോൾ അതേ സൈറ്റ് അതേ പരിധി കാണും. പ്രോട്ടോക്കോൾ തലത്തിലുള്ള പരിഹാരം നെറ്റ്വർക്ക് കുറിപ്പുകളിൽ വേണം, അടുത്ത എഞ്ചിനീയർ അവിടെ നോക്കും.