PPTP കണക്റ്റ് ചെയ്ത ശേഷം Linux NAT-ന് പിന്നിൽ തൂങ്ങുന്നു: GRE സഹായി

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

ഫോർവേഡ് ഒരിക്കലും പ്രശ്നമായിരുന്നില്ല

പോർട്ട്-ഫോർവേഡ് നിയമം TCP അല്ലെങ്കിൽ UDP ട്രാഫിക് വിവരിക്കുന്നു. സെഷന്റെ നടുവിൽ മറ്റൊരു IP പ്രോട്ടോക്കോളിലേക്ക് മാറുന്ന പേലോഡ് അതിന് വിവരിക്കാനാവില്ല, PPTP കൃത്യമായി അതാണ് ചെയ്യുന്നത്.

അതുകൊണ്ടാണ് കണക്ഷൻ തൂങ്ങുന്ന നിമിഷം വരെ ആരോഗ്യകരമായി കാണപ്പെടുന്നത്. പോർട്ട് നിയമത്തിന് നിയന്ത്രിക്കാനാകുന്ന ഭാഗം വിജയിച്ചു, നിയന്ത്രിക്കാനാകാത്ത ഭാഗമാണ് പരാജയപ്പെട്ട ഭാഗം.

നിയന്ത്രണത്തിന് TCP, ഡാറ്റയ്ക്ക് GRE

കോൾ TCP 1723-ൽ ചർച്ച ചെയ്യുന്നു. അത് ഉയർന്നുകഴിഞ്ഞാൽ പേലോഡ് GRE-യിലേക്ക്, IP പ്രോട്ടോക്കോൾ 47-ലേക്ക് പോകുന്നു, അത് പോർട്ട് നമ്പറുകളൊന്നും വഹിക്കുന്നില്ല. പോർട്ടുകളെ ആശ്രയിക്കുന്ന നിയമത്തിന് പൊരുത്തപ്പെടുത്താൻ ഒന്നുമില്ല.

GRE വഹിക്കുന്നത് അതിന്റെ ഹെഡറിലെ ഒരു കോൾ ഐഡന്റിഫയറാണ്, NAT പരിഭാഷകൻ ആ ഫീൽഡ് ഇരുവശത്തേക്കും സ്ഥിരതയോടെ വീണ്ടും എഴുതണം, അല്ലെങ്കിൽ സെഷന്റെ രണ്ട് പകുതികൾ പരസ്പരം യോജിക്കുന്നത് നിർത്തുന്നു. ഒരു ദിശ വീണ്ടും എഴുതി മറ്റേത് ഇല്ലെങ്കിൽ ഓതന്റിക്കേറ്റ് ചെയ്ത ശേഷം ഓരോ ഡാറ്റ പാക്കറ്റും വലിച്ചെറിയുന്ന സെഷൻ ഉണ്ടാകും. രോഗലക്ഷണത്തിന്റെ രൂപം കൃത്യമായി ഇതാണ്: വിജയം, പിന്നെ നിശബ്ദത.

PPTP ഇല്ലാത്ത വെറും GRE-യ്ക്ക് അത്തരം പുനരെഴുത്ത് ആവശ്യമില്ല, അതുകൊണ്ടാണ് അതേ പാതയിൽ PPTP ക്ലയന്റിന് പരാജയപ്പെടുന്ന റൗട്ടർ വഴി സാധാരണ GRE ടണൽ പ്രവർത്തിക്കാനാകുന്നത്.

നാല് മൊഡ്യൂളുകളും അവ ഓഫാക്കിയ ഒരു sysctl-ഉം

രണ്ട് മൊഡ്യൂളുകൾ ഫ്രെയിമിംഗ് കൈകാര്യം ചെയ്യുന്നു, nf_conntrack_proto_gre, nf_nat_proto_gre. മറ്റ് രണ്ടെണ്ണം കോൾ ഐഡന്റിഫയർ കൈകാര്യം ചെയ്യുന്നു, nf_conntrack_pptp, nf_nat_pptp. അവസാനത്തേത് ലോഡ് ചെയ്യുമ്പോൾ ബാക്കിയുള്ളവ ആശ്രിതത്വങ്ങളിലൂടെ വരുന്നു, അതിനാൽ മൊഡ്യൂൾ പട്ടിക നാലും കാണിക്കണം.

പഴയ നിർദ്ദേശങ്ങൾ 2.6 കാലഘട്ടത്തിലെ ip_ പ്രിഫിക്സ് ഉപയോഗിക്കുന്നു. ആ കമാൻഡുകൾ ഒന്നും ലോഡ് ചെയ്യാതെ പ്രവർത്തിക്കുന്നതായി തോന്നാം, അതിനാൽ എക്സിറ്റ് സ്റ്റാറ്റസല്ല, ലോഡ് ചെയ്ത പട്ടിക പരിശോധിക്കുക.

അവ ലോഡ് ചെയ്തിരിക്കുന്നത് മാത്രം ഇനി മതിയാകില്ല. Linux 4.7 മുതൽ net.netfilter.nf_conntrack_helper sysctl ഡിഫോൾട്ടായി 0 ആണ്, ഇത് പുതിയ ഫ്ലോകൾക്ക് സ്വയമേവയുള്ള സഹായി അനുവദനം പ്രവർത്തനരഹിതമാക്കുന്നു. ഒരു റൗട്ടറിൽ എല്ലാ മൊഡ്യൂളുകളും ഉണ്ടായിരിക്കാം, എന്നിട്ടും ഒന്നും പരിഭാഷപ്പെടുത്തില്ല. മൊഡ്യൂൾ പട്ടിക വീണ്ടും നോക്കുന്നതിന് മുമ്പ് ഫലപ്രദമായ മൂല്യം പരിശോധിക്കുക.

ഒന്നുകിൽ സ്വയമേവയുള്ള അനുവദനം വീണ്ടും ആഗോളമായി ഓണാക്കുക, അല്ലെങ്കിൽ ആവശ്യമുള്ള ഫ്ലോകളിൽ സഹായി ഘടിപ്പിച്ച് ബാക്കിയെല്ലാം അതേപടി വിടുക:

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

രണ്ടാമത്തെ ഓപ്ഷനാണ് മുൻഗണന. മുഴുവൻ റൗട്ടറിലും സ്വയമേവയുള്ള അനുവദനം വീണ്ടും സജീവമാക്കുന്നതിന് പകരം അത് സ്വഭാവം PPTP ട്രാഫിക്കിൽ ഒതുക്കുന്നു.

പോർട്ടുകളില്ലാത്ത ഒരു പ്രോട്ടോക്കോൾ തുറക്കുക

1723 അനുവദിക്കുന്ന ഫയർവാൾ നിയമം പ്രോട്ടോക്കോൾ 47-നെ കുറിച്ച് ഒന്നും പറയുന്നില്ല. firewalld-ൽ ക്ലയന്റിന് അഭിമുഖമായ സോണിൽ പ്രോട്ടോക്കോൾ അനുവദിക്കുക. സാധാരണ iptables-ൽ ഇൻപുട്ട് ചെയിനിൽ gre പ്രോട്ടോക്കോൾ സ്വീകരിക്കുക.

പിന്നീട് ഇരുവശത്തും ക്യാപ്ചർ ചെയ്യുക. ക്ലയന്റ് വിടുന്ന പാക്കറ്റുകൾക്ക് മറുപടികൾ എത്തുന്നില്ലെങ്കിൽ തിരിച്ചുള്ള പാത ഫിൽട്ടർ ചെയ്യപ്പെട്ടു, അത് നിരസിക്കപ്പെട്ട ക്രെഡൻഷ്യലിൽ നിന്ന് വ്യത്യസ്തമായ തകരാറാണ്.

കണക്റ്റ് ചെയ്തതിന് ശേഷം വലിപ്പ പരിധി

GRE ഒരു ഹെഡർ ചേർക്കുന്നു, അതിനുള്ളിലെ PPP കൂടുതൽ ചേർക്കുന്നു, അതിനാൽ പ്രവർത്തിക്കുന്ന ലിങ്ക് 1500-ന് വളരെ താഴെയുള്ള MTU റിപ്പോർട്ട് ചെയ്യുന്നു. ചെറിയ പ്രതികരണങ്ങൾ ലോഡ് ചെയ്യുന്നു, വലുത് തൂങ്ങുന്നു, ഇത് ആദ്യത്തെ പ്രശ്നം പരിഹരിക്കുന്ന നിമിഷത്തിൽ പ്രത്യക്ഷപ്പെടുന്ന രണ്ടാമത്തെ, അസംബന്ധമായ പ്രശ്നം പോലെ തോന്നുന്നു.

ക്ലയന്റിന്റെ PPP അഡാപ്റ്ററിൽ MTU വായിക്കുക, റൗട്ടറിന്റെ സ്വന്തം കണക്കുകൂട്ടലുമായി അത് ഒത്തുചേർക്കുക എന്തെങ്കിലും പ്രവർത്തിക്കുന്നതുവരെ സംഖ്യകൾ കുറയ്ക്കുന്നതിന് പകരം. പൂർണ്ണ വലിപ്പത്തിലുള്ള പാക്കറ്റുകൾ പുറപ്പെട്ട് ഒന്നും തിരിച്ചുവരാത്തത് പരിഭാഷയിലേക്കല്ല, ആ പരിധിയിലേക്കാണ് സൂചന നൽകുന്നത്.

പാത നന്നാക്കുന്നത് ഉപയോക്താവിനെ ജോലിയിൽ തിരികെ കൊണ്ടുവരുന്നു, അത് PPTP-യെ നല്ല തിരഞ്ഞെടുപ്പാക്കുന്നില്ല. MS-CHAPv2-ഉം RC4-ഉം വളരെ മുമ്പേ കാലഹരണപ്പെട്ടവയാണ്, അതിനാൽ മൊഡ്യൂൾ ലോഡ് ചെയ്യുന്നത് താൽക്കാലിക പരിഹാരമായി കണക്കാക്കി പരിപാലിക്കപ്പെടുന്ന ഒരു പ്രോട്ടോക്കോളിലേക്ക് മാറാൻ പദ്ധതിയിടുക.