PPTP വിഭജിത ടണലിംഗ് പ്രവർത്തിക്കുന്നില്ല: ആദ്യം GRE പാത ശരിയാക്കുക

PPTP കണക്ഷൻ ഉയരുന്നത് കാണുക, ബുദ്ധിമുട്ടുള്ള ഭാഗം കഴിഞ്ഞു എന്ന് വിശ്വസിക്കാൻ എളുപ്പമാണ്: ക്ലയന്റ് പ്രാമാണീകരണം നടത്തുന്നു, ppp0 അഡാപ്റ്റർ അല്ലെങ്കിൽ WAN Miniport പ്രത്യക്ഷപ്പെടുന്നു, സ്റ്റാറ്റസ് വിൻഡോ പച്ചയാകുന്നു. പിന്നീട് ആന്തരിക ഹോസ്റ്റിലേക്കുള്ള ആദ്യ അഭ്യർത്ഥന സമയപരിധി കവിയുന്നു, പ്രൊഫൈലിനെ കുറ്റപ്പെടുത്തുന്നു. പ്രായോഗികമായി രണ്ട് സ്വതന്ത്ര പാളികൾ വൃത്തിയാക്കണം: TCP 1723 ഉം GRE യും വഹിക്കുന്ന പുറം ഗതാഗതം, ഏത് ലക്ഷ്യങ്ങൾ PPP ഇന്റർഫേസ് ഉപയോഗിക്കുന്നു എന്ന് തീരുമാനിക്കുന്ന ആന്തരിക നയം. പച്ച സ്റ്റാറ്റസ് ആദ്യ പാളി ചർച്ച ചെയ്തു എന്ന് മാത്രം തെളിയിക്കുന്നു; രണ്ടാമത്തേതിനെക്കുറിച്ച് അത് ഒന്നും പറയുന്നില്ല.

പ്രൊഫൈലിൽ നിന്ന് കൺട്രോൾ സോക്കറ്റ് വരെ ക്ലയന്റിനെ പിന്തുടരുക

ക്ലയന്റ് ലോഗ് തുറന്ന് അത് സെർവറുമായി ബന്ധപ്പെടുന്ന സ്ഥലം കണ്ടെത്തുക. PPTP ആദ്യം പോർട്ട് 1723 ലേക്ക് TCP കണക്ഷൻ തുറന്ന് ആ ചാനലിലൂടെ ടണൽ പാരാമീറ്ററുകൾ ചർച്ച ചെയ്യുന്നു. ഈ ഘട്ടം പരാജയപ്പെട്ടാൽ പിന്നീട് ഒന്നും പ്രധാനമല്ല, പിശക് സാധാരണയായി സെർവർ വിലാസമോ സമയപരിധിയോ പേരിടുന്നു.

ഏതെങ്കിലും റൂട്ട് തൊടുന്നതിന് മുമ്പ് നെറ്റ്വർക്കിൽ കൺട്രോൾ കണക്ഷൻ സ്ഥിരീകരിക്കുക. ക്ലയന്റിലോ മിറർ പോർട്ടിലോ ഒരു കണക്ഷൻ ശ്രമത്തിനായി TCP 1723 ക്യാപ്ചർ ചെയ്യുക:

sudo tcpdump -ni any 'tcp port 1723' -c 20

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

GRE രണ്ടാമത്തെ പ്രോട്ടോക്കോളാണ്, പോർട്ടല്ല

PPTP, PPP പേലോഡ് വിപുലീകൃത GRE, IP പ്രോട്ടോക്കോൾ 47 നുള്ളിൽ വഹിക്കുന്നു, അതിന് റൂട്ടർ ട്രാക്ക് ചെയ്യാൻ കഴിയുന്ന പോർട്ട് നമ്പർ ഇല്ല. അതിനാൽ TCP 1723 അനുവദിക്കുന്ന നിയമവും ടണലിനെ ഡാറ്റാ പാതയില്ലാതെ വിടാം. സ്റ്റേറ്റ്ഫുൾ NAT ഉപകരണങ്ങൾ ഉത്തരങ്ങൾ തിരികെ മാപ്പ് ചെയ്യാൻ GRE യിലെ കോൾ ID മനസ്സിലാക്കണം, പലതും അത് ചെയ്യുന്നില്ല. PPTP സ്പെസിഫിക്കേഷൻ കൺട്രോൾ ചാനലും GRE പേലോഡും വേർതിരിച്ച ഭാഗങ്ങളായി സൂക്ഷിക്കുന്നു, നിങ്ങളുടെ പരീക്ഷണ പദ്ധതിയും അങ്ങനെയായിരിക്കണം.

അതേ ക്യാപ്ചറിൽ പ്രോട്ടോക്കോൾ 47 നിരീക്ഷിക്കുക, എന്നിട്ട് പുറത്തുപോകുന്നതിനെ തിരികെ വരുന്നതുമായി താരതമ്യം ചെയ്യുക:

sudo tcpdump -ni any 'proto gre' -c 20

TCP 1723 ആരോഗ്യകരമായിരിക്കുമ്പോൾ ഉത്തരമില്ലാതെ പുറത്തുപോകുന്ന പാക്കറ്റുകൾ തടയപ്പെട്ട GRE യുടെ ക്ലാസിക് ലക്ഷണമാണ്. ഉപഭോക്തൃ റൂട്ടറിലെ PPTP പാസ്ത്രൂ ആ നിർദ്ദിഷ്ട ഫേംവെയറിന്റെ സവിശേഷതയാണ്, അതിനാൽ പ്രവർത്തിക്കുന്ന ഹോട്ടൽ നെറ്റ്വർക്ക് അടുത്തതിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. റൂട്ടർ പാസ്ത്രൂ നൽകുന്നില്ലെങ്കിൽ, നിങ്ങൾക്ക് അത് മാറ്റാൻ കഴിയുന്നില്ലെങ്കിൽ, പ്രശ്നം റൂട്ട് ടേബിളല്ല, പ്രോട്ടോക്കോൾ തിരഞ്ഞെടുപ്പാണ്.

ടണൽ ഒരു പാക്കറ്റ് നീക്കുന്നു എന്ന് തെളിയിക്കുക

GRE ഒഴുകാൻ തുടങ്ങുമ്പോൾ, PPP ചർച്ച ക്ലയന്റ് ഇന്റർഫേസിന് ഒരു വിലാസം നൽകുന്നു. അനുമാനിക്കാതെ അനുവദനം വായിക്കുക:

ip -4 addr show ppp0

പോയിന്റ്-ടു-പോയിന്റ് ലിങ്കിന്റെ ലക്ഷ്യമായി കാണിക്കുന്ന പിയർ വിലാസത്തിലേക്ക് പിംഗ് ചെയ്യുക. ഈ ഘട്ടത്തിലെ ഉത്തരം എൻകാപ്സുലേറ്റ് ചെയ്ത പാത ആദ്യം മുതൽ അവസാനം വരെ പ്രവർത്തിക്കുന്നു എന്നും സെർവർ ടണലിനുള്ളിൽ ഉത്തരം നൽകുന്നു എന്നും തെളിയിക്കുന്നു. പിയർ ഉത്തരം നൽകിയാൽ ആന്തരിക ഹോസ്റ്റുകൾ നൽകുന്നില്ലെങ്കിൽ, പുറം ഗതാഗതം കുഴപ്പമില്ല, പരാജയം അകത്തേക്ക് മാറി.

ഏതെങ്കിലും വിഭജിത റൂട്ട് ചേർക്കുന്നതിന് മുമ്പ് ഇത് ചെയ്യുക. ഗതാഗതം തകർന്നിരിക്കുമ്പോൾ ചെയ്യുന്ന റൂട്ട് മാറ്റം രണ്ടാമത്തെ വേരിയബിൾ സൃഷ്ടിച്ച് ആദ്യത്തേത് മറയ്ക്കുന്നു.

വിഭജിത നയം എഴുതുക, DNS ഉൾപ്പെടെ

വിഭജിത റൂട്ടിംഗ് തീരുമാനങ്ങളുടെ പട്ടികയാണ്, ചെക്ക്ബോക്സല്ല. ടണൽ കടക്കേണ്ട ഓരോ സ്വകാര്യ പ്രിഫിക്സിനും PPP ഇന്റർഫേസിലൂടെ ഒരു റൂട്ട് വേണം, പ്രാദേശികമായി തുടരേണ്ട ഓരോ പ്രിഫിക്സും അതിൽ ഉണ്ടാകരുത്. ഒരു ആപ്ലിക്കേഷൻ സബ്നെറ്റിന് അതിന്റെ സ്വകാര്യ റിസോൾവറിലേക്ക് പൊരുത്തപ്പെടുന്ന റൂട്ട് ഇല്ലാതെ റൂട്ട് ഉണ്ടാക്കുന്നത് തകർന്ന ആപ്പ് പോലെ തോന്നുന്ന തടസ്സം സൃഷ്ടിക്കാനുള്ള സാധാരണ മാർഗമാണ്.

ഓരോ വിഭാഗത്തിലെയും ഒരു വിലാസത്തിന് കേർണൽ എടുക്കുന്ന തീരുമാനം പരിശോധിക്കുക:

ip route get 10.20.5.10
ip route get 203.0.113.25

ആദ്യത്തേത് ppp0 എന്നും രണ്ടാമത്തേത് സാധാരണ ഗേറ്റ്വേ എന്നും പറയണം. രണ്ടും ഒരേ ഇന്റർഫേസ് പറഞ്ഞാൽ, നയം അൽപ്പവും വിഭജിതമല്ല. DNS സെർവറിന്റെ സ്വന്തം വിലാസം ടണൽ ലിസ്റ്റിൽ ചേർക്കുക, അല്ലാത്തപക്ഷം ആന്തരിക ഹോസ്റ്റുകൾക്കുള്ള പേര് നിർണ്ണയം പ്രാദേശിക റിസോൾവറിലൂടെ പുറത്തുപോകുന്നു, ഉപയോഗപ്രദമായ ഒന്നും തിരികെ നൽകുന്നില്ല.

അഞ്ച് ഘട്ടങ്ങളിലായി ആവർത്തിക്കാവുന്ന പരിശോധന

പാളികൾ ക്രമത്തിൽ പ്രവർത്തിപ്പിച്ച് ആദ്യം പരാജയപ്പെട്ടതിൽ നിർത്തുക: കൺട്രോൾ ചാനൽ, GRE ദൃശ്യത, PPP പിയർ ഉത്തരം, ഒരു ആന്തരിക വിലാസത്തിനുള്ള വിഭജിത റൂട്ട്, ടണലിലൂടെയുള്ള ആപ്ലിക്കേഷൻ അഭ്യർത്ഥന. ഓരോ ഘട്ടത്തിനും സ്വന്തം കമാൻഡ് ഉണ്ട്, അതിനാൽ പരാജയം ആരോപിക്കാവുന്നതാണ്, നിഗൂഢമല്ല.

Linux ക്ലയന്റിനുള്ള ചുരുക്ക പതിപ്പ് ഇങ്ങനെയാണ്:

sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10

Windows ൽ അതേ ക്രമം route print ഉം ക്ലയന്റിൽ കാണിക്കുന്ന അഡാപ്റ്റർ സ്റ്റാറ്റസും ഉപയോഗിച്ച് ബാധകമാണ്. PPTP ഒരു പഴയ പ്രോട്ടോക്കോളാണ്, സെർവർ SSTP അല്ലെങ്കിൽ IKEv2 വാഗ്ദാനം ചെയ്യുന്നുവെങ്കിൽ, ഓരോ ഹോപ്പിലും പ്രോട്ടോക്കോൾ 47 കടന്നുപോകുന്നതിനെ ആശ്രയിക്കുന്ന ഒരു പാത ട്യൂൺ ചെയ്യുന്നതിനേക്കാൾ മാറിപ്പോകുന്നത് സാധാരണയായി സമയത്തിന്റെ മികച്ച ഉപയോഗമാണ്. പഴയ പ്രൊഫൈൽ പുതിയ റിലീസിലേക്ക് പകർത്തുന്നതിന് പകരം പകരക്കാരന്റെ സർട്ടിഫിക്കറ്റും പ്രാമാണീകരണ കരാറും പരിശോധിക്കുക.