DHCP રિન્યુ પછી VPN ડ્રોપ થાય છે? સરનામાંની સરખામણી કરો

લીઝ રિન્યુ અને VPN નિષ્ફળતા લોગમાં એટલા વારંવાર સાથે દેખાય છે કે લોકો માની લે છે કે એક બીજાનું કારણ છે. સમયનો મેળ ખરો છે; કારણભાવ સામાન્ય રીતે નથી. રિન્યુ એ લીઝ આપનાર સર્વરને મોકલેલી યુનિકાસ્ટ વિનંતી છે, જે એ જ બાઈન્ડિંગ વાપરવાનું ચાલુ રાખવા માંગે છે, અને સર્વર ક્લાયન્ટ એક પણ સરનામું બદલ્યા વિના તેને લંબાવી શકે છે. ઘટનાની આસપાસ ક્લાયન્ટની પોતાની કિંમતો તપાસવાથી શાંતિથી રિન્યુ થયેલી લીઝ અને ચાલતા ટનલ નીચે ખરેખર બદલાયેલા નેટવર્ક વચ્ચે ભેદ પડે છે.

જે ક્લાયન્ટ ડ્રોપ થયો તેનાથી શરૂ કરો

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

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

ઘટનાની આસપાસની ચાર કિંમતોની સરખામણી કરો

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

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

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

રિન્યુ શું બદલી શકે છે અને શું નહીં

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

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

જ્યારે ક્લાયન્ટ અનુકૂળ ન થઈ શકે

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

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

દોષ આપતાં પહેલાં ઘટના ફરી થવા દો

સમયપત્રકની રાહ જોવાને બદલે સ્થિતિ પુનઃઉત્પન્ન કરો: લીઝ છોડો અને ફરી રિન્યુ કરો, અથવા સમાન નિયંત્રિત ઘટના ફરજિયાત કરો, અને જુઓ કે ટનલ ટકે છે કે નહીં. મેનેજ્ડ નેટવર્કમાં, સરનામાનો કોઈ પણ ફેરફાર નેટવર્ક માલિક સાથે સંકલન કરો, કારણ કે મનસ્વી સ્થિર ફાળવણી એ સરનામું પહેલેથી ધરાવતા ઉપકરણ સાથે અથડાઈ શકે છે.

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