PPTP പിശക് 800 ഉം 812 ഉം ഒരു മിനിറ്റിന് ശേഷമുള്ള കണക്ഷൻ വിച്ഛേദവും

ഒരു PPTP ക്ലയന്റിൽ നിന്നുള്ള മൂന്ന് പിശക് സന്ദേശങ്ങൾ സാധാരണയായി മൂന്ന് വ്യത്യസ്ത തകരാറുകളെ വിവരിക്കുന്നു. പിശക് 800 എന്നാൽ ടണൽ ഒരിക്കലും രൂപപ്പെട്ടില്ല, പിശക് 812 എന്നാൽ സർവർ ഓതന്റിക്കേഷൻ രീതി നിരസിച്ചു, ഒരു മിനിറ്റിന് ശേഷമുള്ള വിച്ഛേദം ആരോഗ്യമുള്ള ഒരു പങ്കാളി പോയി എന്ന് തീരുമാനിക്കുന്ന keepalive ടൈമറാണ്. ഓരോ ഘട്ടവും അതതിന്റെ കാരണത്താൽ പരാജയപ്പെടുന്നു, അതിനാൽ ഓരോന്നിനും അതതിന്റെ പരിശോധന വേണം.

പിശക് 800 എന്നാൽ ടണൽ ഒരിക്കലും രൂപപ്പെട്ടില്ല

Windows ടണൽ ഒട്ടും നിർമ്മിക്കാൻ കഴിയാത്തപ്പോൾ പിശക് 800 ഉയർത്തുന്നു, എത്തിച്ചേരാൻ കഴിയാത്ത സർവർ അല്ലെങ്കിൽ അനുയോജ്യമല്ലാത്ത സുരക്ഷാ പാരാമീറ്ററുകൾ സംബന്ധിച്ച വാചകം രോഗനിർണയമല്ല, സംഗ്രഹമാണ്. ഏതെങ്കിലും ക്രെഡൻഷ്യൽ പരിശോധിക്കുന്നതിന് മുമ്പ് PPTP-യ്ക്ക് നെറ്റ്വർക്കിൽ നിന്ന് രണ്ട് വേറിട്ട കാര്യങ്ങൾ വേണം. TCP 1723 നിയന്ത്രണ ചാനൽ വഹിക്കുന്നു, IP പ്രോട്ടോക്കോൾ 47, അതായത് GRE, എൻകാപ്സുലേറ്റ് ചെയ്ത പേലോഡ് വഹിക്കുന്നു.

ആ പുറം വഴി നിങ്ങളുടെ സ്വന്തം LAN-ന് പുറത്തുനിന്ന് പരീക്ഷിക്കുക, കാരണം ഓഫീസിനുള്ളിൽ പ്രവർത്തിക്കുന്ന കണക്ഷൻ അരികിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല:

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

1723 പ്രതികരിക്കുകയും ക്ലയന്റ് കണക്ട് ചെയ്യാൻ ശ്രമിക്കുമ്പോൾ ക്യാപ്ചർ ശൂന്യമായി തുടരുകയും ചെയ്താൽ, വഴി പ്രോട്ടോക്കോൾ 47 ഉപേക്ഷിക്കുകയാണ്. 1723 ഫോർവേഡ് ചെയ്തെങ്കിലും PPTP പാസ്ത്രൂ ഓഫ് ചെയ്ത റൗട്ടർ കൃത്യമായി ആ മാതൃക സൃഷ്ടിക്കുന്നു: TCP ഹാൻഡ്ഷേക്ക് പൂർത്തിയാകുന്നു, പിന്നീട് GRE പാക്കറ്റുകൾ അപ്രത്യക്ഷമാകുന്നു, അതിനാൽ ലോഗിൻ ശ്രമം നടന്നിട്ടില്ലെങ്കിലും തകരാർ ക്രെഡൻഷ്യൽ പ്രശ്നമായി തോന്നുന്നു.

ഫോർവേഡിംഗ് സർവറിന്റെ നിലവിലെ LAN വിലാസത്തിലേക്ക് തിരിക്കുക, റൗട്ടർ വാഗ്ദാനം ചെയ്യുന്നിടത്ത് PPTP പാസ്ത്രൂ പ്രവർത്തനക്ഷമമാക്കുക, അതേ പുറം സ്ഥലത്തുനിന്ന് വീണ്ടും ശ്രമിക്കുക. GRE മുകളിൽ ഫിൽട്ടർ ചെയ്യപ്പെടുകയും നിങ്ങൾക്ക് അത് മാറ്റാൻ കഴിയാതിരിക്കുകയും ചെയ്താൽ, TCP 443-ന് മേലുള്ള SSTP-യ്ക്കോ UDP 500, 4500 എന്നിവയ്ക്ക് മേലുള്ള L2TP/IPsec-നോ Windows വശത്ത് നിങ്ങൾക്ക് ചെയ്യാവുന്ന ഏത് മാറ്റത്തെക്കാളും സാധ്യത കൂടുതലാണ്.

പിശക് 812 എന്നാൽ സർവർ നിങ്ങളുടെ ഓതന്റിക്കേഷൻ രീതി നിരസിക്കുന്നതാണ്

ടണൽ ഉയർന്നതിന് ശേഷം പിശക് 812 തിരികെ വരുന്നു, അതുകൊണ്ടാണ് അത് പാസ്വേഡ് പ്രശ്നമായി തോന്നുന്നത്. സർവർ കണക്ഷനായി ചർച്ച ചെയ്ത ഓതന്റിക്കേഷൻ രീതി നിരസിക്കുന്നു, പാസ്വേഡ് തന്നെ നിർബന്ധമായും അല്ല. ക്ലയന്റിൽ VPN എൻട്രി തുറക്കുക, സുരക്ഷാ ടാബിലേക്ക് പോകുക, തരം Point-to-Point Tunneling Protocol ആയി സജ്ജമാക്കുക, വ്യക്തമായ പ്രോട്ടോക്കോൾ ലിസ്റ്റ് തിരഞ്ഞെടുക്കുക, Microsoft CHAP പതിപ്പ് 2 ടിക്ക് ചെയ്യുക.

ഡയലോഗിൽ ക്ലിക്ക് ചെയ്യാതെ നിലവിലെ ക്രമീകരണം വായിക്കാം:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

MS-CHAP v2 ആവശ്യപ്പെടുന്ന സർവർ PAP-ലോ ദുർബലമായ എന്തോ ചർച്ച ചെയ്യുന്ന ഓട്ടോമാറ്റിക് തരത്തിലോ വിട്ട ക്ലയന്റിനെ നിരസിക്കുന്നു, ഏതെങ്കിലും ഉപയോക്തൃ പാസ്വേഡ് വിലയിരുത്തുന്നതിന് മുമ്പ് പിശക് എത്തുന്നു. അക്കൗണ്ട് ഫോർമാറ്റ് അതേ നിരസിച്ചലിന്റെ മറ്റേ പകുതിയാണ്. ഒരു സന്ദർഭത്തിൽ സർവർ പ്രാദേശിക അല്ലെങ്കിൽ ഡൊമെയ്ൻ അക്കൗണ്ട് ആഗ്രഹിച്ചപ്പോൾ Windows MicrosoftAccount\[email protected] രൂപത്തിലുള്ള Microsoft അക്കൗണ്ട് ഐഡന്റിറ്റി അയച്ചു. SERVERNAME\username ടൈപ്പ് ചെയ്തപ്പോൾ ഏത് അക്കൗണ്ട് സ്റ്റോർ സമീപിക്കണമെന്ന് Windows-നോട് പറഞ്ഞു, പിശക് മാറി. സംഭരിച്ച ക്രെഡൻഷ്യലിനെ മുൻ ഫോർമാറ്റ് ആവർത്തിക്കാൻ അനുവദിക്കുന്നതിന് പകരം പേര് കൈകൊണ്ട് നൽകുക.

ഒരു മിനിറ്റിന് ശേഷമുള്ള വിച്ഛേദങ്ങൾ keepalive തീരുമാനമാണ്

ടണൽ കണക്ട് ചെയ്ത്, കുറച്ച് ട്രാഫിക് കടത്തിവിട്ട്, പിന്നീട് വിച്ഛേദിക്കുമ്പോൾ, ക്ലയന്റിനെ സ്പർശിക്കുന്നതിന് മുമ്പ് സർവറിന്റെ LCP പ്രതിധ്വനി സ്വഭാവം നോക്കുക. ഡീമൺ പങ്കാളിയോട് ഇപ്പോഴും അവിടെയുണ്ടോ എന്ന് ഇടയ്ക്കിടെ സ്ഥിരീകരിക്കാൻ ആവശ്യപ്പെടുന്നു. നിശ്ചിത ബജറ്റിനുള്ളിൽ വളരെ കുറച്ച് മറുപടികൾ എത്തിയാൽ, ഉപയോക്താവിന് ഇപ്പോഴും പ്രവർത്തിക്കുന്ന ലിങ്ക് ഉണ്ടെങ്കിലും സെഷൻ പൊളിക്കുന്നു.

Linux pptpd സർവറിൽ ആ മൂല്യങ്ങൾ /etc/ppp/options.pptpd-ൽ കഴിയുന്നു, സാധാരണ അറ്റകുറ്റപ്പണി ഇടവേള കുറയ്ക്കുന്നതല്ല, ബജറ്റ് വിശാലമാക്കുന്നതാണ്:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

അഞ്ച് സെക്കൻഡ് ഇടവേളയിൽ മുപ്പത് വീഴ്ചകൾ ചെറിയ തടസ്സം ക്ഷമിക്കുന്നു, പങ്കാളി പോയി എന്ന് പ്രഖ്യാപിക്കുന്നതിന് പകരം. എണ്ണം ഒന്നോ രണ്ടോ ആക്കി കുറച്ചാൽ, വിവർത്തനം ചെയ്ത വഴിയിലെ സാധാരണ ജിറ്റർ ഏകദേശം ഓരോ മിനിറ്റിലും വിച്ഛേദമായി മാറുന്നു. നിങ്ങളുടെ സർവർ pptpd അല്ലാതെ Windows RRAS ആണെങ്കിൽ, പകരം PPP സെഷൻ ടൈംഔട്ടും നിഷ്ക്രിയാവസ്ഥയിൽ വിച്ഛേദിക്കാനുള്ള നയവും നോക്കുക. അവ മറ്റൊരിടത്ത് കഴിയുന്നു, ഇല്ലാത്ത pppd ഫയൽ എഡിറ്റ് ചെയ്താൽ ഒന്നും മാറില്ല.

ഓവർലാപ്പിംഗ് സബ്നെറ്റുകൾ ഡാറ്റ പാത തകർക്കുന്നു

രണ്ട് സൈറ്റുകളും ഒരേ സ്വകാര്യ ശ്രേണി ഉപയോഗിക്കുമ്പോൾ, ഉദാഹരണത്തിന് ഓഫീസിലും വീട്ടിലും 192.168.1.0/24, PPTP ടണലിന് വൃത്തിയായി ഓതന്റിക്കേറ്റ് ചെയ്യാം, എന്നിട്ടും എങ്ങും എത്താതിരിക്കാം. നൽകിയ വിലാസം ഏത് ഹോസ്റ്റിനെ സൂചിപ്പിക്കുന്നു എന്ന് ക്ലയന്റിന് പറയാനാകില്ല, ചില സ്റ്റാക്കുകൾ ഒന്ന് തിരഞ്ഞെടുക്കുന്നതിന് പകരം റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്യാൻ തന്നെ വിസമ്മതിക്കുന്നു.

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

പരാജയപ്പെട്ട ഘട്ടത്തിൽ നിന്ന് തുടങ്ങുക: 800-ന് GRE, 812-ന് രീതിയും അക്കൗണ്ട് സ്ട്രിംഗും, ഷെഡ്യൂൾ പ്രകാരം മരിക്കുന്ന ടണലിന് പ്രതിധ്വനി ക്രമീകരണങ്ങൾ.