L2TP ഡീബഗ് ലോഗ് കാലിയാണോ? പിശക് ഒരുപക്ഷേ ജേണലിലാണ്

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

നാല് പ്രോസസ്സുകൾ, രണ്ട് ലോഗ് ലക്ഷ്യങ്ങൾ

കണക്ഷൻ IPsec-ൽ തുടങ്ങുന്നു, ഇൻസ്റ്റലേഷൻ അനുസരിച്ച് അത് libreswan അല്ലെങ്കിൽ strongSwan ആണ്. തുടർന്ന് L2TP ഡെമൺ, പരമ്പരാഗതമായി xl2tpd, ചില ബിൽഡുകളിൽ kl2tpd, ടണൽ നടത്തുന്നു. അവസാനം pppd അതിനുള്ളിൽ പ്രാമാണീകരണവും വിലാസം നൽകലും കൈകാര്യം ചെയ്യുന്നു.

സഹായ സേവനം ആ ഭാഗങ്ങൾ ഏകോപിപ്പിക്കുകയും സ്വന്തം പുരോഗതി പ്രിന്റ് ചെയ്യുകയും ചെയ്യുന്നു. IPsec ഡെമണും pppd-യും സാധാരണയായി സിസ്റ്റം ജേണലിലൂടെ റിപ്പോർട്ട് ചെയ്യുന്നു, അതുകൊണ്ടാണ് ടെർമിനൽ പരാജയപ്പെടുന്ന കണക്ഷൻ കാണിക്കുന്നത്, കാരണം നിങ്ങൾ തുറക്കാത്ത ഒരു ഫയലിലാണ്.

ഈ വിഭജനം PSK പിശകും പാസ്വേഡ് പിശകും ഡെസ്ക്ടോപ്പിൽ നിന്ന് ഒരേപോലെ തോന്നുന്നതിന്റെ കാരണവും വിശദീകരിക്കുന്നു: രണ്ടും പൊതുവായ വിച്ഛേദം സൃഷ്ടിക്കുന്നു, പരാജയപ്പെട്ട ഘട്ടം ഓരോ പ്രോസസ്സിന്റെയും ഔട്ട്പുട്ടിൽ മാത്രമാണ് കാണുന്നത്. ഇവിടെ ജേണൽ പ്രധാനമാകാനുള്ള മുഴുവൻ കാരണം അതാണ്. ഡെസ്ക്ടോപ്പിൽ ഒരു പൊതു സന്ദേശം, അതിന് പിന്നിൽ നാല് സാധ്യതയുള്ള രചയിതാക്കൾ.

ഒരു ശ്രമം ശേഖരിക്കുക, പിന്നീട് ക്രമം വായിക്കുക

അറിയാവുന്ന പ്രൊഫൈലും അറിയാവുന്ന സമയവും ഉപയോഗിച്ച് ഒരിക്കൽ പുനർനിർമ്മിക്കുക, പിന്നീട് മുഴുവൻ ബൂട്ടിനും പകരം ഇടുങ്ങിയ വിൻഡോ വായിക്കുക. ക്രമീകരണങ്ങൾ മാറ്റുമ്പോൾ ശ്രമങ്ങൾ ആവർത്തിക്കുന്നത് ലോഗിനെ വ്യാഖ്യാനിക്കാനാകാത്ത മിശ്രിതമാക്കി മാറ്റുന്നു.

ഈ കമാൻഡുകൾ നിലവിലെ ബൂട്ടിലെ പങ്കെടുക്കുന്ന പ്രോസസ്സുകൾ തിരഞ്ഞെടുക്കുന്നു, നിങ്ങളുടെ വിതരണത്തിൽ പ്ലഗിൻ പാത്ത് സ്ഥിരീകരിക്കുന്നത് മൂല്യവത്താണ്:

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=pluto _COMM=charon _COMM=xl2tpd _COMM=pppd
rpm -ql NetworkManager-l2tp 2>/dev/null | grep nm-l2tp-service

ഒരു വിളിയിൽ ആവർത്തിച്ച ഫീൽഡുകൾ ആ പ്രോസസ്സുകളുടെ യൂണിയൻ തിരഞ്ഞെടുക്കുന്നു, ഇത് ക്രമം സമയക്രമത്തിൽ നിലനിർത്തുന്നു. Debian അടിസ്ഥാനമാക്കിയ സിസ്റ്റത്തിൽ തത്തുല്യമായ ക്വറി dpkg -L ആണ്; കാര്യം, കൈകൊണ്ട് പ്രവർത്തിപ്പിക്കാൻ ശ്രമിക്കുന്നതിന് മുമ്പ് സഹായി യഥാർത്ഥത്തിൽ എവിടെ താമസിക്കുന്നു എന്ന് കണ്ടെത്തുക എന്നതാണ്.

അടുത്ത നീക്കം മൂന്ന് വ്യവസ്ഥകൾ തീരുമാനിക്കുന്നു

ആദ്യം പരാജയപ്പെട്ട ഘട്ടം വായിച്ച്, അതനുസരിച്ച് തിരഞ്ഞെടുക്കുക. IPsec നിർദ്ദേശത്തിന്റെയോ സഹകാരിയുടെ പ്രാമാണീകരണത്തിന്റെയോ പരാജയം റിപ്പോർട്ട് ചെയ്താൽ, ടണൽ ഒരിക്കലും രൂപപ്പെട്ടിട്ടില്ല, PPP പാസ്വേഡ് മാറ്റുന്നത് സഹായിക്കില്ല.

ടണൽ രൂപപ്പെടുകയും pppd ലോഗിൻ നിരസിക്കുകയും ചെയ്തെങ്കിൽ, പങ്കിട്ട രഹസ്യം മുമ്പേ തന്നെ ശരിയായിരുന്നു, ക്രെഡൻഷ്യൽ പ്രശ്നം ഒരു പാളി മുകളിലാണ്. pppd വിലാസത്തെക്കുറിച്ച് ചർച്ച ചെയ്ത് പരാജയം പിന്നീട് പ്രത്യക്ഷപ്പെട്ടാൽ, രണ്ടും പ്രവർത്തിക്കുന്നു, ബാക്കിയുള്ള പ്രശ്നം റൂട്ടിംഗ്, DNS അല്ലെങ്കിൽ സെർവറിന്റെ സ്വന്തം നയമാണ്.

ആ മൂന്ന് ശാഖകൾ മിക്കവാറും എല്ലാ പൊതു വിച്ഛേദവും ഉൾക്കൊള്ളുന്നു, ഏത് പ്രോസസ്സ് അവസാന പിശക് രേഖപ്പെടുത്തി എന്നതാണ് അവയെ തീരുമാനിക്കുന്നത്, ഏത് പിശക് സന്ദേശം ഏറ്റവും ഭീഷണമായി തോന്നുന്നു എന്നതല്ല.

ഡീബഗ് ക്രമീകരണം തൊടുന്നതിന് മുമ്പ് ഏത് IPsec ബാക്കെൻഡ് ഇൻസ്റ്റാൾ ചെയ്തിട്ടുണ്ടെന്ന് സ്ഥിരീകരിക്കുന്നതും മൂല്യവത്താണ്. strongSwan-നായി എഴുതിയ ലോഗിംഗ് ഓപ്ഷൻ libreswan പ്രവർത്തിക്കുമ്പോൾ ഒന്നും ചെയ്യുന്നില്ല, ആരും വായിക്കാത്ത ഫയൽ നിങ്ങൾ തിരുത്തുമ്പോൾ കണക്ഷൻ അതേ സ്ഥലത്ത് പരാജയപ്പെട്ടുകൊണ്ടിരിക്കും.

ഡീബഗ് മോഡ് ഫയലുകൾ വിട്ടേക്കുന്നു

യഥാർത്ഥ ഡീബഗ് വർക്ക്ഫ്ലോ ഡീബഗ് ഫ്ലാഗിനൊപ്പം സേവനം കൈകൊണ്ട് പ്രവർത്തിപ്പിക്കുന്നു, ആ മോഡ് കണക്ഷൻ അവസാനിക്കുമ്പോൾ സൃഷ്ടിച്ച റൺടൈം കോൺഫിഗറേഷൻ ഫയലുകൾ അവിടെത്തന്നെ വിട്ടേക്കാം.

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

കൈകൊണ്ട് പ്രവർത്തിപ്പിച്ച ഇൻസ്റ്റൻസും സാധാരണയുമായി ഏകോപിപ്പിക്കണം. സേവനം ഇതിനകം പ്ലഗിൻ സ്വന്തമാക്കിയിരിക്കെ ഡീബഗ് പകർപ്പ് ആരംഭിക്കുന്നത് രണ്ട് ഉടമകളെയും രണ്ടിനെയും കലർത്തുന്ന ലോഗിനെയും സൃഷ്ടിക്കുന്നു, അത് ഡീബഗ് ഔട്ട്പുട്ട് ഒട്ടും ഇല്ലാതിരിക്കുന്നതിനേക്കാൾ മോശമാണ്.

തുടർന്ന് സാധാരണ സഹായി പുനഃസ്ഥാപിക്കുക

അന്വേഷണം അവസാനിക്കുമ്പോൾ കൈകൊണ്ട് പ്രവർത്തിപ്പിച്ച ഇൻസ്റ്റൻസ് നിർത്തുക, സൂക്ഷിച്ച റൺടൈം ഫയലുകൾ നീക്കം ചെയ്യുക, സാധാരണ പാതയിലൂടെ വീണ്ടും ബന്ധിപ്പിക്കുക, അടുത്ത വ്യക്തിക്ക് യാഥാർത്ഥ്യവുമായി പൊരുത്തപ്പെടുന്ന കോൺഫിഗറേഷൻ കാണാനാകട്ടെ.

തുടർന്ന് ഫലം പരാജയപ്പെട്ട പാളിയിൽ പരിശോധിക്കുക, ഡെസ്ക്ടോപ്പ് ഐക്കണിൽ അല്ല:

journalctl -b -u NetworkManager --since -10min | tail -30
ip -4 addr show ppp0
ip -4 route get 10.20.4.10

പ്രാമാണീകരിക്കുന്ന, വിലാസം സ്വീകരിക്കുന്ന, ഉദ്ദേശിച്ച ലക്ഷ്യസ്ഥാനത്തേക്ക് റൂട്ട് ചെയ്യുന്ന സെഷനാണ് നിങ്ങൾ ഡീബഗ് ചെയ്തിരുന്ന ഫലം. പരാജയപ്പെട്ട ശ്രമത്തിനിടയിൽ നിശബ്ദമായ ടെർമിനൽ നിങ്ങളോട് പറയുന്നത് ഇത്രമാത്രം ഔട്ട്പുട്ട് എവിടെ എഴുതിയില്ല.