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

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

કયું ટાઇમર અટકવાનો માલિક છે

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

જે હેડ-એન્ડ સાથે તમે વાત કરી રહ્યા હતા તેની બાજુમાં નંબર લખો. અંતરાલ સ્થિર થયા પછી બાકીનું કામ ત્રણ કારણો વચ્ચે પસંદગી કરવાનું છે, અને દરેક પુનઃકનેક્શન પર એક સેટિંગ બદલવું એ જ તેમને અલગ રાખે છે.

પહેલો કિસ્સો: ક્લાયન્ટ નિષ્ક્રિય સત્ર છોડી દે છે

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

DPD idle timeout (our side) 0
NAT Traversal Mode cisco-udp

ક્લાયન્ટ DPD બંધ કરવાથી ખોટો સંકેત દૂર થાય છે અને તમારી એકમાત્ર સ્થાનિક શોધ પણ દૂર થાય છે, તેથી તેને એકલું લાગુ કરો અને જુઓ કે અંતરાલ આખરે બદલાય છે કે નહીં.

બીજો કિસ્સો: રીકી નકારવામાં આવે છે

જો અંતરાલ DPD ફેરફાર પછી ટકી રહે, તો ફેઝ 1 ની રીકી ઉમેદવાર બને છે. જૂની vpnc બિલ્ડ વર્તમાન કરતાં ઓછી કાળજીથી રીકી સંભાળતી હતી, અને સામાન્ય મતભેદ Diffie-Hellman ગ્રુપ છે. હેડ-એન્ડ પહેલેથી સ્વીકારે તેવા ગ્રુપને ફરજિયાત કરવાથી એક લીટી અને એક પુનઃકનેક્શનનો ખર્ચ થાય છે, જે તેને નીતિ પરિવર્તનને બદલે સસ્તું પ્રયોગ બનાવે છે.

IKE DH Group dh5

માન્ય ગ્રુપ નામો dh1, dh2 અને dh5 છે. કન્સન્ટ્રેટર જે ગ્રુપ નકારે છે તે તાત્કાલિક નિષ્ફળતા આપે છે, અને તે પણ માહિતી છે: તે કહે છે કે હેડ-એન્ડ પસંદગીયુક્ત છે અને મૂળ ગ્રુપ કદાચ સાચું હતું.

ત્રીજો કિસ્સો: અનુવાદ એન્કેપ્સ્યુલેશન ફરી લખે છે

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

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

જે પ્રોફાઇલ કમાન્ડ લાઇનથી સારી રીતે કનેક્ટ થાય છે પણ ડેસ્કટોપથી નહીં, તે ફ્રન્ટએન્ડની સમસ્યા છે, ટાઇમરની સમસ્યા નહીં.

ત્રીજા ફેરફાર પહેલા નિષ્ફળ જતું આદાનપ્રદાન ચકાસો

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

vpnc --debug 3 office

જ્યારે ટનલ ટકી રહે પણ ટ્રાફિક અટકે ત્યારે બીજા નેટવર્ક ડિમન પણ તપાસો. રાઉટિંગ ટેબલ લખતા બે મેનેજર ડેસ્કટોપથી એ જ લક્ષણ અને સંપૂર્ણ અલગ લોગ બનાવે છે.

સંબંધિત લેખો