pptpd-ലെ GRE എഴുത്ത് പരാജയങ്ങൾ പാസ്വേഡ് പ്രശ്നമല്ല

ലോഗിൽ GRE എഴുത്ത് പരാജയം, ഉപയോക്താവിന്റെ പാസ്വേഡ് പുനഃസജ്ജമാക്കുകയാണ് ആദ്യ പ്രവണത. ആ പ്രവണത എപ്പോഴും ഏതാണ്ട് തെറ്റാണ്. ഈ സന്ദേശങ്ങൾ ക്രെഡൻഷ്യൽ പരിശോധനയല്ല, ഡാറ്റാ പാത്ത് വിവരിക്കുന്നു: ക്ലയന്റ് വിജയകരമായി പ്രാമാണീകരിച്ച് പിന്നീട് നെറ്റ്വർക്കിൽ രജിസ്റ്റർ ചെയ്യുന്ന ഘട്ടത്തിൽ കുടുങ്ങിയിരിക്കാം. രണ്ട് വ്യത്യസ്ത സന്ദേശങ്ങൾ രണ്ട് വ്യത്യസ്ത പരാജയങ്ങളിലേക്ക് ചൂണ്ടുന്നു, രണ്ടിനെയും പുതിയ പാസ്വേഡ് പരിഹരിക്കുന്നില്ല.

രണ്ട് സന്ദേശങ്ങൾ, രണ്ട് വ്യത്യസ്ത പരാജയങ്ങൾ

വായന പരാജയം എന്നാൽ GRE പാക്കറ്റുകൾ ഒരിക്കലും ഡീമണിൽ എത്തുന്നില്ല, അല്ലെങ്കിൽ അകത്തേക്ക് വരുമ്പോൾ ഉപേക്ഷിക്കപ്പെടുന്നു. നിയന്ത്രണ കണക്ഷൻ പൂർണ്ണമായി ആരോഗ്യകരമായി തോന്നാം, പക്ഷേ ഡാറ്റാ പാത്തിലൂടെ ഒന്നും കടക്കുന്നില്ല. പ്രാമാണീകരണം മാത്രമാണ് വ്യക്തമായി പ്രവർത്തിച്ചത്.

എഴുത്ത് പരാജയം സാധാരണയായി സെഷൻ കെർണലിനോ ക്ലയന്റിനോ ഉപയോഗിക്കാനാകാത്ത എന്തോ ചർച്ച ചെയ്തു എന്നാണ്. നിയന്ത്രണ ചാനൽ പൂർത്തിയായി, ആ കൈമാറ്റത്തിൽ സമ്മതിച്ച ഓപ്ഷനുകൾ എൻഡ്പോയിന്റുകൾക്ക് യഥാർത്ഥത്തിൽ ചെയ്യാനാകുന്നതുമായി പൊരുത്തപ്പെടുന്നില്ല. ഇത് കോൺഫിഗറേഷൻ വിയോജിപ്പാണ്, പ്രാമാണീകരണ സംഭവമല്ല.

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് രണ്ടിൽ ഏതാണ് കാണുന്നതെന്ന് വായിക്കുക. അവ നിങ്ങളെ വ്യത്യസ്ത പാളികളിലേക്ക് അയയ്ക്കുന്നു, അവയെ ഒരു ലക്ഷണമായി കാണുന്നതാണ് ഒരേ സെർവർ ബന്ധമില്ലാത്ത കാരണങ്ങളാൽ രണ്ടുതവണ പാച്ച് ചെയ്യപ്പെടാൻ കാരണം. ലോഗ് വരി മാത്രമാണ് നിങ്ങൾക്ക് ലഭിക്കുന്ന ഒരേയൊരു സൗജന്യ ഡയഗ്നോസ്റ്റിക്സ്.

പ്രോട്ടോക്കോൾ 47 പോർട്ട് 47 അല്ല

PPTP കോൾ സ്ഥാപിക്കാൻ TCP 1723-ഉം പേലോഡ് കൊണ്ടുപോകാൻ GRE-യും ഉപയോഗിക്കുന്നു. GRE എന്നത് IP പ്രോട്ടോക്കോൾ 47 ആണ്, പോർട്ട് നമ്പറല്ല, അതിനാൽ പോർട്ട് 47 തുറക്കുന്ന ഫയർവാൾ നിയമം ഉപയോഗപ്രദമായ ഒന്നും അനുവദിക്കുന്നില്ല.

പാത്തിലുള്ള റൗട്ടറിന് PPTP passthrough സവിശേഷതയോ വ്യക്തമായ GRE അനുമതിയോ ആവശ്യമാണ്. അതില്ലാതെ TCP ഹാൻഡ്ഷേക്ക് പൂർത്തിയാകുന്നു, ടണൽ ഒരിക്കലും പാക്കറ്റ് കൊണ്ടുപോകുന്നുമില്ല, ഇത് മുകളിലെ വായന പരാജയം കൃത്യമായി സൃഷ്ടിക്കുന്നു. ഫയർവാളിലെ പോർട്ട് 47 നിയമങ്ങൾ ഈ പ്രോട്ടോക്കോളിൽ ഏറ്റവും കൂടുതൽ പാഴാക്കുന്ന ഉച്ചയ്ക്കുശേഷമാണ്.

ഏത് വശമാണ് ട്രാഫിക് ഉപേക്ഷിക്കുന്നതെന്ന് ഊഹിക്കുന്നതിനുപകരം സെർവറിൽ രണ്ട് ദിശകളും ഒരുമിച്ച് നിരീക്ഷിക്കുക: tcpdump -ni any port 1723 or proto gre.

1723 കോൾ സ്ഥാപനം കാണിക്കുകയും GRE നിശബ്ദമായിരിക്കുകയും ചെയ്താൽ, തടയൽ ഹോസ്റ്റിന് മുകളിലാണ്. GRE എത്തിയിട്ടും ഡീമൺ ഇപ്പോഴും പരാജയപ്പെടുന്നെങ്കിൽ, പ്രശ്നം പ്രാദേശികമാണ്, ഓപ്ഷനുകളാണ് അടുത്ത് നോക്കേണ്ട സ്ഥലം.

ഹോസ്റ്റ് യഥാർത്ഥത്തിൽ കൈമാറ്റം ചെയ്യുന്നിടത്ത് GRE അനുവദിക്കുക

GRE-യ്ക്ക് forward നിയമം ചേർക്കുന്നത് ടണൽ ട്രാഫിക് കൈമാറ്റം ചെയ്യുന്ന ഹോസ്റ്റിൽ ന്യായമായ പരിശോധനയാണ്, അത് നയമല്ല. ഒരു പ്രോട്ടോക്കോളിന്റെ എല്ലാം സ്വീകരിക്കുന്ന പരിശോധനാ നിയമം ഡയഗ്നോസ്റ്റിക്സാണ്, ഡിസൈനല്ല. എന്തെങ്കിലും പഠിക്കാൻ മതിയായ സമയം വയ്ക്കുക, പിന്നീട് പരിമിതമായ നിയമം കൊണ്ട് മാറ്റുക.

സെർവറിന് തന്നെ അയച്ച പാക്കറ്റുകൾക്ക് input നിയമം ചേർക്കുക, കാരണം forward ശൃംഖല അവ കാണുന്നില്ല. പിന്നീട് കണക്ഷൻ ശ്രമത്തിന് മുമ്പും ശേഷവും നിയമത്തിന്റെ കൗണ്ടറുകൾ നോക്കുക, പാക്കറ്റുകൾ എത്തുന്നുണ്ടോ എന്ന് അത് പറയും.

ഓരോ റീബൂട്ടിനും ശേഷം വീണ്ടും പ്രവർത്തിപ്പിക്കുന്നതിനുപകരം വിതരണത്തിന്റെ ഫയർവാൾ സേവനത്തിലൂടെ നിയമം സ്ഥിരമാക്കുക. nftables ഹോസ്റ്റിൽ input, forward എന്നീ രണ്ട് ശൃംഖലകളിലും ip protocol gre പൊരുത്തപ്പെടുത്തുക.

ppp_generic മോഡ്യൂളും ലോഡ് ചെയ്തിട്ടുണ്ടെന്ന് ഉറപ്പാക്കുക, കണക്ഷൻ ട്രാക്കിംഗ് തിരിച്ചുവരവ് ദിശ ഉപേക്ഷിക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക. രണ്ടും ഫയർവാൾ പ്രശ്നമായി തോന്നുന്ന, എന്നാൽ അല്ലാത്ത പരാജയങ്ങൾ സൃഷ്ടിക്കുന്നു. ഇല്ലാത്ത കെർണൽ മോഡ്യൂൾ പരിശോധിക്കുന്നതുവരെ കൃത്യമായി തടഞ്ഞ പ്രോട്ടോക്കോൾ പോലെ തോന്നുന്നു.

യഥാർത്ഥത്തിൽ ഉള്ള ക്ലയന്റുമായി ഓപ്ഷനുകൾ ഒത്തുപോകട്ടെ

മറ്റേ റിപ്പോർട്ടിന്റെ തിരുത്തൽ /etc/ppp/pptpd-options-ൽ ഉണ്ട്, അവിടെ റെസിപ്പി PAP, CHAP, MSCHAP എന്നിവ നിരസിക്കുന്നു, ബന്ധപ്പെട്ട require വരികൾ കമന്റ് ചെയ്യുന്നു, അവസ്ഥയുള്ള MPPE നിലനിർത്തുന്നു. ആ റെസിപ്പി ഒരു ക്ലയന്റ് മിശ്രിതത്തിനായി എഴുതിയതാണ്, കണ്ണടച്ച് പകർത്തുന്നത് സാധാരണ കേസ് തകർക്കുന്നു. നിരസിക്കൽ വരികൾ ശുപാർശയായല്ല, രചയിതാവിന് ഏതൊക്കെ ക്ലയന്റുകൾ ഉണ്ടായിരുന്നു എന്ന പ്രസ്താവനയായി വായിക്കുക.

Windows ക്ലയന്റിന് സാധാരണയായി MS-CHAPv2-ഉം MPPE-128-ഉം ആവശ്യമാണ്. ആ ആവശ്യകതകൾ നിലനിർത്തി ക്ലയന്റിന് യഥാർത്ഥത്തിൽ ചർച്ച ചെയ്യാനാകാത്ത ഓപ്ഷനുകൾ മാത്രം നീക്കം ചെയ്യുക.

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

കണക്ഷൻ വിജയിക്കാൻ എൻക്രിപ്ഷൻ ഓഫ് ചെയ്യുന്നത് തരംതാഴ്ത്തലാണ്, അറ്റകുറ്റപ്പണിയല്ല. അത്തരം ഒരു വകഭേദം ലാബ് ലിങ്കിൽ പരീക്ഷിക്കുക, പിന്നീട് സേവനം യഥാർത്ഥ ക്ലയന്റുകളെ നേരിടുന്നതിന് മുമ്പ് എൻക്രിപ്ഷൻ പുനഃസ്ഥാപിക്കുക. സുരക്ഷിതമല്ലാതെ പ്രവർത്തിക്കുന്ന കണക്ഷൻ സത്യസന്ധമായി പരാജയപ്പെടുന്നതിനേക്കാൾ മോശമാണ്.

ക്ലയന്റിന്റെ പിശക് നമ്പർ വായിക്കുക

ക്ലയന്റിന്റെ സംഖ്യാ കോഡ് സെർവർ ലോഗിനേക്കാൾ വേഗത്തിൽ ഘട്ടം ചുരുക്കുന്നു. മറ്റെന്തെങ്കിലും വായിക്കുന്നതിന് മുമ്പ് അത് വായിക്കുക. 691 എന്നാൽ ക്രെഡൻഷ്യലുകൾ നിരസിക്കപ്പെട്ടു, 721 എന്നാൽ സെർവർ ഒരിക്കലും ഉത്തരം നൽകിയില്ല, 619 എന്നാൽ കണക്ഷൻ വിച്ഛേദിക്കപ്പെട്ടു. നമ്പറിനൊപ്പം രണ്ട് മിനിറ്റ് കോൺഫിഗറേഷനിൽ ഒരു മണിക്കൂർ ലാഭിക്കുന്നു.

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

ലോഗിൻ വിജയിക്കുകയും ട്രാഫിക് നീങ്ങാതിരിക്കുകയും ചെയ്താൽ, GRE ഇപ്പോഴും സംശയാസ്പദമാണ്. ക്രെഡൻഷ്യൽ സ്റ്റോറിന് പകരം ക്യാപ്ചറിലേക്ക് മടങ്ങേണ്ട നിമിഷമാണത്.