રાઉટર રીબૂટ પછી અટકી ગયેલું VPN: બદલાયેલી ત્રણ બાબતો

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

ત્રણ શરતો ઉકેલ નક્કી કરે છે. તેમને ક્રમમાં તપાસો, કારણ કે પ્રથમ શરત પહેલેથી જ અટકવાનું કારણ સમજાવતી હોય તો પછીની શરતો વ્યર્થ શ્રમ છે.

શરત એક: સ્થાનિક સરનામું બદલાયું છે

રીબૂટ મશીનને બીજું સરનામું આપી શકે છે. ત્યારે સ્થિર સ્થાનિક એન્ડપોઇન્ટ સાથે ગોઠવેલું VPN એવી જોડાણનો ઉપયોગ ચાલુ રાખે છે જે હવે નથી. જે ક્લાયન્ટે પોતાનું સોકેટ જૂના સરનામા સાથે બાંધ્યું હતું તેના માટે પણ એ જ લાગુ પડે છે. ટનલ ઇન્ટરફેસ ચાલુ રહી શકે છે જ્યારે તે જે પેકેટ બનાવે છે તે નકામી જગ્યાએ જાય છે.

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

ip -4 addr show
ip route show default
ip route get 203.0.113.10

શરત બે: અનુવાદિત મેપિંગ ગયું છે

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

અહીં જ keepalive વગરની ટનલ જોરથી નિષ્ફળ થવાને બદલે શાંતિથી અટકી જાય છે. WireGuard ના દસ્તાવેજીકૃત મર્યાદાઓ એ જ પ્રકારની નિષ્ફળતા વર્ણવે છે. ખોટી એન્ડપોઇન્ટ સ્થિતિ નિદાનને બદલે ફેંકાયેલા પેકેટ પેદા કરે છે.

25 સેકન્ડનું સતત keepalive સામાન્ય ઉપાય છે, કારણ કે તે નિષ્ક્રિય ટાઇમઆઉટ પૂરો થાય તે પહેલાં મેપિંગ તાજું કરે છે. તે પહેલેથી ગયેલું મેપિંગ સુધારતું નથી. keepalive ને ઉકેલ ગણવાને બદલે ફરી જોડાવાની લોજિક સાથે જોડો.

શરત ત્રણ: જાહેર સરનામું બદલાયું છે

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

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

યોગ્ય ક્રમમાં પુનઃપ્રાપ્ત કરો

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

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

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