L2TP જોડાય છે પણ PPP વાટાઘાટ નિષ્ફળ જાય છે: કયો તબક્કો?

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

ટનલ ફક્ત પ્રથમ સ્તર છે

L2TP IPsec-સુરક્ષિત ટનલની અંદર PPP ફ્રેમ્સ વહન કરે છે, એટલે કે પેકેટ રૂટ થાય તે પહેલાં બે સ્વતંત્ર વાટાઘાટ સફળ થવી જોઈએ. બાહ્ય વાટાઘાટ સાબિત કરે છે કે બંને છેડા કી અને ઓળખ પર સહમત છે. આંતરિક વાટાઘાટ લિંક પરિમાણો, વપરાશકર્તા પ્રમાણીકરણ થાય છે કે નહીં અને ક્લાયન્ટને કયું સરનામું મળે છે તે નક્કી કરે છે.

PPP ની અંદરની નિષ્ફળતા દરેક એવા ક્લાયન્ટમાં તૂટેલી ટનલ જેવી લાગે છે જે ફક્ત એક સ્થિતિ દીવો બતાવે છે. તેને ટનલની સમસ્યા તરીકે ગણવાથી કી ફરી બનાવવી, સેવાઓ ફરી શરૂ કરવી અને અંતે એવી શેર કરેલી ગુપ્ત કી બદલવી પડે છે જે ક્યારેય ખોટી નહોતી. ઉપયોગી ભેદ સસ્તો છે: જો પીઅર સાથેની આપલે પૂરી થઈ ગઈ હોય અને ક્લાયન્ટ વપરાશકર્તાનામની વિનંતી કે પ્રમાણીકરણ તબક્કે આગળ વધ્યો હોય, તો ટનલ ઠીક છે. એ બિંદુ પછીનું બધું PPP નું છે.

સફળ થયેલો છેલ્લો તબક્કો વાંચો

લોગમાં આગળ ચાલો અને જે પ્રથમ તબક્કો પૂરો થયો નથી ત્યાં થોભો. પહેલા LCP આવે છે, પછી પ્રમાણીકરણ, પછી IPv4 પરિમાણો માટે IPCP.

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

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

ટિકિટમાં તબક્કાના નામ સાથે લોગનો અંશ રાખો. તબક્કાની સીમા વગર ચોંટાડેલી પૂંછડી આગળના વાચકને અનુમાન કરવા આમંત્રે છે, અને અહીં અનુમાન કરવાનો ખર્ચ એક કલાક છે.

ક્લાયન્ટ અને સર્વર વચ્ચેની સહમતિ

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

દરેક જૂના વિકલ્પને બદલે એક સમર્થિત પદ્ધતિ સક્રિય કરો, કારણ કે પાંચ પદ્ધતિ ઓફર કરતો ક્લાયન્ટ કઈ નિષ્ફળ ગઈ તે છુપાવે છે. એડમિનિસ્ટ્રેટરને સર્વર-બાજુની નીતિ અને ચોક્કસ અસ્વીકાર માટે પૂછો, જેમાં કોઈએ પાસવર્ડ પ્રકાશિત કરવાની જરૂર નથી. એક ક્લાયન્ટને બચાવવા સક્રિય કરેલી જૂની પદ્ધતિ ફાઇલની નકલ કરતી દરેક પ્રોફાઇલમાં ફેલાવાનું વલણ ધરાવે છે.

સરનામું ચકાસો, લોગિન નહીં

પૂર્ણ થયેલું લોગિન વપરાયોગ્ય સત્ર નથી. IPCP આંતરિક સરનામું વાટાઘાટ કરે છે, અને ખાલી થયેલો પૂલ કે ક્લાયન્ટને નકારતી નીતિ હજી પણ જોડાયેલી ટનલને રૂટ કરવા માટે કંઈ વગર છોડી શકે છે.

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

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

તબક્કો, પદ્ધતિ અને સરનામું એક નોંધમાં લખો અને તારીખ નાખો. જો એ જ ખાતું એક મહિના પછી ફરી નિષ્ફળ જાય, તો એ નોંધ પાંચ મિનિટની ચકાસણી અને નવી તપાસ વચ્ચેનો ફરક છે. જુદા જુદા તબક્કેની નિષ્ફળતાઓ જુદી જુદી ઘટનાઓ છે, ભલે ક્લાયન્ટ એક જ સંવાદ બતાવે.