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

પ્રમાણીકરણ કરતું, સરનામું મેળવતું અને ઇચ્છિત ગંતવ્ય તરફ રાઉટ કરતું સેશન એ જ પરિણામ છે જે તમે ડિબગ કરી રહ્યા હતા. નિષ્ફળ પ્રયાસ દરમિયાન શાંત ટર્મિનલ તમને ફક્ત એટલું કહે છે જ્યાં આઉટપુટ લખાયું નથી.