VPN ચલાવતી વખતે ફરી જોડાય છે: રેડિયો બદલાવ કે IP બદલાવ?
ટાવરો વચ્ચેનું હેન્ડઓવર IP માર્ગને અકબંધ રાખી શકે છે. જે ક્લાયન્ટ ટનલ ખસેડે છે તેમની સરખામણી તેની સાથે કરો જે તેને ફરી બનાવે છે, અને નેટવર્કની ઘટના વાંચો, મુસાફરી નહીં.
તમે નગરની ધાર પસાર કરો ત્યારે કૉલ તૂટી જાય છે, અને VPN આઇકન તે જ ક્ષણે અદૃશ્ય થાય છે. તેને “ટાવર બદલાવે ટનલ મારી નાખી” તરીકે નોંધવું લલચાવનારું છે. બે જુદી બાબતો બની, અને તેમાંથી ફક્ત એક ટાવરો સાથે સંબંધિત છે. રેડિયો હેન્ડઓવર તમારું IP સરનામું, ડિફોલ્ટ માર્ગ અને સત્ર સંપૂર્ણ અકબંધ રાખી શકે છે, જ્યારે ખરું સરનામું બદલાવ દરેક એવી ટનલ તોડી નાખશે જે તેની સાથે ખસી શકતી નથી. તે બીજા કિસ્સાને ક્લાયન્ટ કેવી રીતે સંભાળે છે તેની સરખામણી કરવી એ જ ઉપયોગી કસરત છે, કારણ કે તે તમને કહે છે કે તમે રચાયેલું વર્તન જોઈ રહ્યા છો કે ખામી.
ટાવર બદલાવ એ જરૂરી રીતે સરનામાનો બદલાવ નથી
મોબાઇલ નેટવર્ક હેન્ડઓવર દરમિયાન પેકેટ સત્ર જીવંત રાખે છે જ્યાં સુધી ઓપરેટરનું મોબિલિટી એન્કર સમાન રહે. રેડિયો કડી બદલાય છે, ટનલ તેને નોંધતી નથી, અને કોઈ પણ લોગમાં ફરી જોડાવું દેખાવું ન જોઈએ. શહેરની અંદર હલનચલન માટે આ સામાન્ય કિસ્સો છે.
સરનામું બદલે છે એન્કર વચ્ચેનું સ્થળાંતર, Wi-Fi થી સેલ્યુલર પર જવું, અથવા લાંબા વિરામ પછી ઓપરેટરની બાજુએ ટનલની પુનઃસ્થાપના. તે ઘટનાઓ તમારા પેકેટ લઈ જતા સ્રોત સરનામાને બદલે છે, અને VPN સાથી ખસેલા સાથીને જુએ છે.
વ્યવહારુ પરિણામ એ છે કે હલનચલન પુરાવો નથી. ચાલીસ કિલોમીટર ગયેલું ઉપકરણ આખો રસ્તો એક જ સરનામું રાખી શકે છે, અને સ્થિર ઊભેલું ઉપકરણ બે વાર સરનામું બદલી શકે છે કારણ કે નેટવર્કે એવો નિર્ણય કર્યો. ઘટના નોંધવી એ તેમને અલગ પાડવાનો એકમાત્ર રસ્તો છે.
બે રચનાઓ: ટનલ ખસેડો અથવા ફરી બનાવો
ક્લાયન્ટ એમાં અલગ પડે છે કે બહારનું સ્રોત બદલાયું તેની તેમને કેટલી પરવા છે. કેટલાક ટનલને જે સરનામા પર બની હતી તેની સાથે બાંધે છે અને સંપૂર્ણ પુનઃસ્થાપન માંગે છે. અન્ય દરેક પેકેટને સ્વતંત્ર રીતે ચકાસે છે અને ફક્ત જવાબો ક્યાં મોકલવા તે અપડેટ કરે છે.
| Mechanism | Behaviour after the source changes | What the user notices |
|---|---|---|
| WireGuard | Endpoint updated on the next authenticated packet | Usually nothing; the tunnel continues |
| IKEv2 with MOBIKE | Security association moves to the new address | Short pause, no re-authentication |
| OpenVPN over UDP with float | Peer address may change without a restart | Might survive, depending on timing |
| Client bound to one address | Session dies and is rebuilt | A visible reconnect and a new authentication |
ઉપરની હરોળ ઘણા ગૂંચવણભર્યા અહેવાલો સમજાવે છે. WireGuard પાસે તોડવા જેવું કોઈ સત્ર નથી: દરેક પેકેટ સાથીનો અનુક્રમણિકા લઈ જાય છે અને ચકાસાય છે, તેથી નવા સરનામેથી આવતું માન્ય પેકેટ વ્યાખ્યા મુજબ તે સાથીનું જ છે, અને નોંધાયેલ અંતિમ બિંદુ તેને અનુસરે છે. મુસાફરી દરમિયાન સતત “જોડાયેલું” દર્શાવતો ક્લાયન્ટ સાચું બોલે છે.
નીચેની હરોળ પણ ખામી નથી. સત્ર ફરી બાંધવું વર્તમાન સરનામા સામે ચકાસણી ફરી ચલાવે છે, અને જૂનું સરનામું હવે બીજા કોઈનું હોઈ શકે ત્યારે તમે બરાબર એ જ ઈચ્છો છો.
હલનચલનને બદલે ઘટના જુઓ
Android માં કનેક્ટિવિટી ઉપપ્રણાલી નેટવર્ક ફેરફારોને ઘટના તરીકે જણાવે છે, અને એ જ તમારે ક્લાયન્ટના વર્તન સાથે સાંકળવા જોઈએ. ડંપ લાંબો છે, પણ સંબંધિત ભાગો ડિફોલ્ટ નેટવર્ક અને તેનું સરનામું છે:
adb shell dumpsys connectivity | grep -E 'NetworkAgentInfo|Default network'
adb shell ip -br addr show
adb logcat -b main -s Vpn:* | head -n 40સર્વરની બાજુએ રોમિંગ કિસ્સા માટે સીધું માપન છે. WireGuard દરેક સાથી માટે છેલ્લું ચકાસાયેલું અંતિમ બિંદુ સંગ્રહે છે, તેથી સરનામાનો બદલાવ ફરી જોડાવા તરીકે નહીં પણ બદલાયેલા મૂલ્ય તરીકે દેખાય છે:
sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakesમુસાફરી પહેલાં અને પછી અંતિમ બિંદુની સરખામણી કરો. સરનામું અને પોર્ટ બદલાયા ન હોય તો ટનલે કંઈ કરવાની જરૂર ન હતી અને ફરી જોડાવું બીજે ક્યાંકથી, સામાન્ય રીતે એપ્લિકેશનમાંથી આવ્યું. અંતિમ બિંદુ બદલાયું હોય પણ હેન્ડશેકનો સમયચિહ્ન સામાન્ય કી નવીકરણ અંતરાલની નજીક રહ્યું હોય તો ટનલ ફરી ચાલુ થયા વિના ખસી ગઈ.
ફરી ચાલુ થવું જુદું દેખાય છે: હેન્ડશેકનો સમયચિહ્ન ફરી જોડાવાની ક્ષણે રીસેટ થાય છે, અને ક્લાયન્ટ શાંત ચાલુ રાખવાને બદલે પ્રારંભ ક્રમ નોંધે છે.
ક્યારે ફરી જોડાવું એ જ સાચું વર્તન છે
દરેક ફરી જોડાવાને ખામી ગણવાથી એવી રૂપરેખાઓ બને છે જે મૃત સત્રોને જીવંત રાખે છે. જે સાથીનું સરનામું બદલાયું કારણ કે નેટવર્કે તેને ફરી ફાળવ્યું, તેણે જૂના મેપિંગ માટે ટ્રાફિક મેળવવાનું ચાલુ ન રાખવું જોઈએ, અને શાંતિથી ચાલુ રાખતો ક્લાયન્ટ આઇકન લીલું રહેતાં કાળા કાણામાં મોકલી શકે છે.
વપરાશકર્તાના દૃષ્ટિકોણથી બંને નિષ્ફળતાઓની સરખામણી કરો. ફરી જોડાવામાં થોડી સેકન્ડ અને નવી ચકાસણીનો ખર્ચ થાય છે. જૂની ટનલમાં એવી એપ્લિકેશનનો ખર્ચ થાય છે જે ભૂલ વગર અટકી જાય છે, જે સમજાવવી ઘણી અઘરી છે અને “ઇન્ટરનેટ બગડી ગયું” તરીકે જણાવાવાની શક્યતા ઘણી વધારે છે.
એની નીચે નીતિનો પ્રશ્ન પણ છુપાયેલો છે. એક માર્ગ ગુમાવવા અને બીજો સ્થાપિત કરવા વચ્ચેના અંતરાલમાં કેટલાક ક્લાયન્ટ સીધો ટ્રાફિક મોકલવા પર પાછા ફરે છે. તેને રોકવું સ્વયંસંચાલિત પુનઃપ્રાપ્તિથી અલગ નિયંત્રણ છે, અને ક્લાયન્ટ એકમાં સારો અને બીજામાં ખરાબ હોઈ શકે. કોઈપણ ગોઠવતા પહેલાં નક્કી કરો કે તમને કયો જોઈએ.
દેખાયેલો ક્રમ લખો
ઉપયોગી અહેવાલ ઘટનાના સ્રોતનું નામ આપે છે: નવા સરનામા સાથે ડિફોલ્ટ નેટવર્કનો બદલાવ, Wi-Fi થી સેલ્યુલર પર જવું, અથવા કોઈ સરનામા બદલાવ વગરનું હેન્ડઓવર. પછી તે કહે છે ક્લાયન્ટે શું કર્યું, યાદશક્તિમાંથી નહીં પણ સર્વરની બાજુના સમયચિહ્ન સાથે.
ટનલ ખસી હોય તો તે કહો અને નવો અંતિમ બિંદુ પરિવાર નોંધો. ફરી સ્થાપિત થયું હોય તો નોંધો કે ચકાસણી પ્રથમ પ્રયાસે સફળ થઈ અને અંતરાલ કેટલો રહ્યો. તે ત્રણ તથ્યો સ્વસ્થ મોબાઇલ રચનાને નેટવર્ક વચ્ચે ભટકતા ક્લાયન્ટથી અલગ પાડે છે.
અને “ટાવર બદલાવ” શબ્દસમૂહ ટાળો જ્યાં સુધી ઉપકરણનો લોગ ખરેખર તે સ્થાપિત ન કરે. Android ના કનેક્ટિવિટી દસ્તાવેજ તે કૉલબેકનું વર્ણન કરે છે જે ઉપલબ્ધતાને ડિફોલ્ટ નેટવર્ક બદલાવથી અલગ પાડે છે, અને તમારા અહેવાલને બરાબર એ જ ભેદ જોઈએ. બાકી બધું ગાડી ચલાવવાની વાર્તા છે.