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

ચાર તપાસો ક્રમમાં કરો અને જે પહેલી નિષ્ફળ જાય ત્યાં જ અટકો.

ખરેખર કયું સરનામું બદલાયું

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

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

પ્રોટોકોલને સ્થળાંતર સંભાળવા દો

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

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

wg show wg0 endpoints
wg show wg0 latest-handshakes
conntrack -L -p udp --dport 51820 | head -n 10

જૂનું બહારનું બંધન સાફ કરો

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

તપાસ દરમિયાન જરૂરી અવરોધ ચાલુ રાખો. ટનલ સાજી થાય છે કે નહીં તે ચકાસવા નીતિને પૂરેપૂરી ખોલવાથી તમને કારણ વિશે કંઈ શીખવા મળતું નથી અને તૈનાતીને તમે જેવી જોઈ તેવી કરતાં ખરાબ બનાવી મૂકે છે.

નવી વિનંતી સાથે ફરી પરીક્ષણ કરો

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

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

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

સંબંધિત લેખો