Ubuntu 22.04 માં L2TP સમયસમાપ્તિ: xl2tpd ટનલ બગ
IPsec કનેક્ટ થાય છે, PPP ક્યારેય શરૂ થતું નથી, અને xl2tpd એવી ટનલનું પુનરાવર્તન કરે છે જે તે મેળવી શકતું નથી. PSK કે સર્વરને સ્પર્શ કરતાં પહેલાં સ્થાપિત બિલ્ડ તપાસો.
ડેસ્કટોપ ચાલુ સંપર્ક દર્શાવે છે, IPsec સફળતાની જાણ કરે છે, અને PPP ઇન્ટરફેસ ક્યારેય દેખાતું નથી. સિસ્ટમ લોગમાં એ જ ટનલ નંબર પુનરાવર્તિત થાય છે જ્યાં સુધી UDP 1701 પર પ્રયાસનો સમય પૂરો ન થાય. પૂર્વ-શેર કરેલી કી અથવા સર્વર રૂપરેખાંકન સંપાદિત કરતાં પહેલાં આ આકાર ઓળખો: Ubuntu 22.04 પર તે સામાન્ય રીતે xl2tpd માં પેકેજિંગ રીગ્રેશન છે, અને સર્વર આખો સમય સાચું હતું.
પુનરાવર્તિત લોગ જોડી તમને શું કહે છે
નિષ્ફળ સત્ર નિયમિત અંતરાલે બે લાઇન છાપે છે: ડિમન આવતા નિયંત્રણ સંદેશ માટે ટનલ શોધી શકતું નથી, પછી તેને મળેલા કૉલ અને ટનલ ઓળખકર્તાઓ ડમ્પ કરે છે. પછી ફરી પ્રયાસ કાઉન્ટર તેની મર્યાદા સુધી પહોંચે છે અને સંપર્ક પોર્ટ 1701 સમયસમાપ્તિ સાથે બંધ થાય છે. સરનામાં અને ઓળખકર્તાઓ ગૌણ છે; આકાર જ મહત્વનો છે. IKE પૂર્ણ થયું, L2TP નિયંત્રણ ટ્રાફિક આવ્યો, અને ડિમન તેને પહેલેથી બનાવેલી ટનલ સાથે જોડી શક્યું નહીં.
તેથી ખામી L2TP નિયંત્રણ અને PPP વચ્ચે છે. ગુપ્ત કી, PPP વિકલ્પો કે દૂરના સબનેટ વિશે હજી કંઈ પણ પરીક્ષણ કરાયું નથી.
ખાતરી કરો કે IPsec ખરેખર સફળ થયું
બે તપાસો આને ઓળખપત્ર સમસ્યાથી અલગ પાડે છે, અને બંને કોઈપણ પેકેજ ફેરફાર પહેલાં આવે છે.
ipsec status
journalctl -u strongswan --since "5 min ago" | grep -i "shared key"સ્થિતિ આઉટપુટ સંપર્ક અને તેની સ્થિતિ સૂચવે છે, અને સ્થાપિત ટનલ એટલે પ્રથમ અને બીજો તબક્કો પૂર્ણ થયા. ગુમ થયેલી શેર કરેલી કી વિશેની લોગ લાઇન ફક્ત ગુપ્ત કી તરફ ઇશારો કરે છે, તેથી થોભો અને પહેલા તે સુધારો. જ્યારે IPsec સ્થાપિત હોય અને L2TP સમયસમાપ્તિ હજી દેખાય, ત્યારે ડિમન જ બાકીનો શંકાસ્પદ છે. આખા દિવસના ફરી પ્રયાસોને બદલે એક પ્રયાસની ચોક્કસ લાઇનો રાખો.
xl2tpd નું બિલ્ડ તપાસો, રિલીઝનું નામ નહીં
Ubuntu ના jammy બિલ્ડમાં xl2tpd 1.3.16 એ લિંક-ટાઇમ ઓપ્ટિમાઇઝેશન સક્ષમ કર્યું, જેણે સર્વરના SCCRP જવાબમાં ટનલ ઓળખકર્તાનું પાર્સિંગ તોડી નાખ્યું. પછી ડિમન પોતે બનાવેલી ટનલ માટે નિયંત્રણ પેકેટો કાઢી નાખે છે. વર્ઝન સ્ટ્રિંગ વિતરણના નામ કરતાં વધુ મહત્વની છે.
dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showholdસુધારેલું પેકેજ 1.3.16-1ubuntu0.1 છે, તેથી તે પ્રત્યય વગરનું બિલ્ડ સુધારણા પહેલાનું છે. પોલિસી આઉટપુટ દર્શાવે છે કે અપગ્રેડ કયો ઉમેદવાર સ્થાપિત કરશે, અને હોલ્ડ યાદી સમજાવે છે કે સુધારો કેમ આવ્યો નથી. જ્યાં પેકેજ ઉપલબ્ધ હોય ત્યાં તેને અપગ્રેડ કરો અને હાથે ફાઇલો સંપાદિત કરવાને બદલે સામાન્ય પ્રોફાઇલ દ્વારા ફરી કનેક્ટ થાઓ. જૂનું બિલ્ડ હજી સ્થાપિત હોય ત્યાં સુધી મોડ્યુલ ફરી ન બનાવો અને ગુપ્ત કી બદલો નહીં.
ફેરફાર પછી PPP ચકાસો
સફળ અપગ્રેડ એ જ સ્તર પર સાબિત થાય છે જે તૂટેલું હતું. ફક્ત આઇકોન બદલાયું કે નહીં નહીં, પણ PPP ઉપર આવ્યું છે કે નહીં તે ચકાસો.
ip -4 addr show ppp0
ip route | grep pppઇન્ટરફેસ યાદીમાં સ્થાનિક અને પીઅર સરનામું દેખાવું જોઈએ, અને રૂટ કોષ્ટકમાં ટનલના પ્રીફિક્સ હોવા જોઈએ. સિસ્ટમ લોગમાં ટનલ સ્વીકારાયેલી અને pppd બંને સરનામાંની જાણ કરતું દેખાવું જોઈએ, વારંવાર ટનલ-ન-મળી લાઇનો વગર. જો PPP ઉપર હોય અને ટ્રાફિક હજી નિષ્ફળ જાય, તો પછી રૂટિંગ કે MTU જુઓ, કારણ કે L2TP તબક્કાએ તેનું કામ પૂરું કર્યું છે. કામ કરતી પેકેજ આવૃત્તિ મશીન નોંધમાં લખો, જેથી ભવિષ્યની પુનઃસ્થાપના તૂટેલું બિલ્ડ પાછું ન લાવે.
જ્યાં સુધારેલું પેકેજ ઉપલબ્ધ નથી, ત્યાં દસ્તાવેજીકૃત વિકલ્પો 1.3.16 અથવા 1.3.17 નું સ્થાનિક સ્રોત બિલ્ડ, kl2tpd તરફ સ્વિચ કે પિન કરેલ ડાઉનગ્રેડ છે. દરેકમાં જાળવણી ખર્ચ છે જે લખવા યોગ્ય છે.