Wi-Fi બદલાય ત્યારે કે Ethernet જોડાય ત્યારે તમારું VPN કેમ તૂટે છે
'નવું SSID, એક્સેસ પોઈન્ટ વચ્ચે રોમિંગ અને જોડાયેલો કેબલ ટનલને ત્રણ અલગ જગ્યાએ તોડે છે. સ્રોત સરનામું, પછી રૂટ, પછી પ્રોટોકોલ તપાસો.'
બે વસ્તુઓ એક જ ખામી તરીકે નોંધાય છે: લેપટોપ બીજા Wi-Fi નેટવર્ક પર ગયું, અથવા Wi-Fi ચાલુ રહેતાં કેબલ જોડાયું. ક્લાયન્ટ હજી કહે છે જોડાયેલું છે, આઇકન સ્વસ્થ લાગે છે, અને ટનલ કંઈપણ વહન કરતી નથી. અંદરથી ફક્ત ત્રણ સ્થિતિના ટુકડા ખસી શકે - લિંક, સ્થાનિક સરનામું, ડિફોલ્ટ રૂટ - અને કયો ખસ્યો તે નક્કી કરે છે કે ટનલ જાતે પુનઃપ્રાપ્ત થશે કે ફરી જોડાવાની જરૂર પડશે. હું તેમને એ જ ક્રમમાં તપાસું છું, કારણ કે એકાઉન્ટ સેટિંગ્સ બદલવાથી આમાંથી એક પણ ક્યારેય ઠીક થયું નથી.
લિંક, સરનામું અને રૂટ સ્વતંત્ર રીતે ખસે છે
એક જ નેટવર્કના એક્સેસ પોઈન્ટ વચ્ચે રોમિંગ સામાન્ય રીતે L2 ઘટના છે. રેડિયો ફરી જોડાય છે, ઇન્ટરફેસ પોતાનું સરનામું અને ગેટવે રાખે છે, અને ટનલ જેના પર આધાર રાખે છે તેમાં કંઈ બદલાતું નથી, તેથી મોટી ઓફિસમાં ચાલવું ક્યારેક ધ્યાનમાં ન આવે. બીજા SSIDમાં જોડાવું એવું નથી: જૂનું ઇન્ટરફેસ નીચે જઈ શકે, DHCP નવું સરનામું, નવું ગેટવે અને નવા રિઝોલ્વર આપે, અને ટનલ જે બાહ્ય પ્રવાહ વાપરતી હતી તે અસ્તિત્વમાં રહેતો નથી.
Ethernet ત્રીજું સ્વરૂપ ઉમેરે છે. Wi-Fi ક્યારેય તૂટતું નથી, તેથી કોઈ લિંક ઘટના સક્રિય થતી નથી, તોપણ વાયરવાળું ઇન્ટરફેસ પોતાના સરનામા સાથે દેખાય છે અને ઘણી વાર મેટ્રિક પર ડિફોલ્ટ રૂટ જીતી જાય છે. ટનલ એવા માર્ગ પર ચાલુ રહે છે જે હવે પ્રિય નથી, અથવા ક્લાયન્ટ પોતાનું સોકેટ જે વાયરલેસ નેટવર્ક પર શરૂ થયું હતું તેમાં જ પિન રાખે છે. બ્રાઉઝરથી બંને એકસરખા દેખાય છે: કેબલ ક્લિક થાય તે ક્ષણે પૃષ્ઠો અટકી જાય છે.
તેથી પહેલો પ્રશ્ન એ નથી કે Wi-Fi બદલાયું કે નહીં. પ્રશ્ન એ છે કે તમે જે સરનામા સાથે બંધાયેલા છો, અથવા અંતિમ બિંદુ સુધીનો રૂટ, ટનલ ચાલુ હતી ત્યારે બદલાયો કે નહીં.
બાહ્ય સોકેટ એવા સરનામા પર પિન થયેલું છે જે હમણાં જ અદૃશ્ય થયું
દરેક ટનલ બાહ્ય પ્રવાહ છે: સ્થાનિક સરનામું અને પોર્ટ સર્વરના સરનામા અને પોર્ટ સાથે વાત કરે છે. Linux પર તે જૂના સ્રોત સાથે બંધાયેલું UDP સોકેટ છે; જ્યારે સરનામું ધરાવતું ઇન્ટરફેસ દૂર થાય છે, ત્યારે મોકલાવવા કાં તો EADDRNOTAVAIL સાથે નિષ્ફળ જાય છે અથવા નવા ઇન્ટરફેસ દ્વારા એવા સ્રોત સાથે નીકળે છે જે સર્વરે ક્યારેય જોયો નથી.
દૂરની બાજુ પોતાનું પિન રાખે છે. MOBIKE વગરનું IKEv2 SA સરનામા જોડી દ્વારા ઓળખાય છે, અને એક OpenVPN સત્ર જે પીઅર સરનામું શીખ્યું તેની સાથે બંધાયેલું છે, અને NAT મેપિંગ તેને બનાવનાર ખાનગી સરનામું, પોર્ટ અને જાહેર સરનામાનું છે. બીજા NAT પાછળ જાઓ અને દરેક જવાબ એવા મેપિંગ પર જાય છે જે હવે અસ્તિત્વમાં નથી. તમારા મશીન પર કંઈ ખોટું ગોઠવાયેલું નથી; પાંચ-ટ્યુપલ તમે છોડી આવેલા નેટવર્ક તરફ ઇશારો કરે છે.
સિદ્ધાંત બાંધતા પહેલાં સ્થિતિ વાંચો:
ss -unpદરેક ટનલ સોકેટ ખરેખર ધરાવતું સ્થાનિક સરનામું અને પોર્ટ દર્શાવે છે.ip route get 203.0.113.10કર્નલ હમણાં અંતિમ બિંદુ માટે વાપરશે તે સ્રોત સરનામું અને ઉપકરણ છાપે છે.wg show wg0 endpoints,swanctl --list-sasઅથવા ક્લાયન્ટ લોગ દૂરની બાજુ જે પીઅર સરનામા સાથે વાત કરે છે એમ માને છે તે દર્શાવે છે.
જો સોકેટનું સરનામું અને રૂટ શોધ મેળ ન ખાય, તો તમે ભંગાણ શોધી કાઢ્યું છે, અને કોઈ ક્રેડેન્શિયલ ફેરફાર તેને સ્પર્શશે નહીં.
નવા સ્રોત સરનામા સાથે દરેક પ્રોટોકોલ શું કરે છે
ક્લાયન્ટ અલગ અલગ માત્રામાં ફેરફાર શોષે છે, અને ટેબલ એ છે જેની સાથે હું ક્લાયન્ટ રૂપરેખા સરખાવું છું, ફરી જોડાવાના વર્તન પરથી અનુમાન કરવાને બદલે.
| Tunnel | Recovery behaviour | Failure signature |
|---|---|---|
| WireGuard | Updates the peer endpoint when an authenticated packet arrives from a new address; no handshake needed if traffic continues. | Handshake current, no return traffic; wg show still lists the old endpoint. |
| IKEv2/IPsec | MOBIKE (RFC 4555) moves the SA to the new address; without it the responder discards packets from an unknown source. | DPD or keepalive timeouts, then a full rekey or a dead SA. |
| OpenVPN over UDP | --float accepts a packet from a new source mid-session; otherwise the session stays tied to the original peer address. | Idle until ping-restart fires, then a visible reconnect. |
| OpenVPN over TCP | The tunnel is a byte stream, so a changed source address breaks it outright. | Immediate reset and a new connection attempt. |
WireGuardનો રોમિંગ નિયમ ફક્ત એક જ દિશામાં કામ કરે છે: ક્લાયન્ટે પહેલાં નવા સરનામેથી મોકલવું પડે. જૂના ઇન્ટરફેસ સાથે હજી બંધાયેલું સોકેટ એ ક્યારેય કરતું નથી, તેથી ટનલ જીવંત લાગે છે જ્યારે તેનો હેન્ડશેક ટાઇમર જૂનો થતો રહે છે. પ્રોટોકોલ વર્ણન અંતિમ બિંદુ અપડેટની શરત ચોકસાઈપૂર્વક કહે છે, અને રૂપરેખા બદલતા પહેલાં તે વાંચવા જેવું છે.
MOBIKE વાટાઘાટ થાય છે, ધારવામાં આવતું નથી. જો સર્વર તેને ઓફર ન કરે, તો ક્લાયન્ટે ફરી સ્થાપિત કરવું પડે, અને તે એ હકીકત છે જે તમે SA યાદી અથવા લોગમાંથી પુષ્ટિ કરો છો, ફરતા ચક્રમાંથી અનુમાન કરતા નથી.
માર્ગ નક્કી રૂટની પ્રાધાન્યતા કરે છે, Wi-Fi આઇકન નહીં
બંને ઇન્ટરફેસ ઉપર હોય ત્યારે કર્નલ મેટ્રિક અને પ્રીફિક્સ લંબાઈ પ્રમાણે પસંદ કરે છે. ip route show default ઉમેદવારોની યાદી આપે છે અને ip route get 203.0.113.10 સ્રોત સરનામા સહિત ખરેખર નિર્ણય ઉકેલે છે. મેટ્રિક 100 પર વાયરવાળું ડિફોલ્ટ અને 600 પર વાયરલેસ એટલે કેબલ બેસે તે ક્ષણે અંતિમ બિંદુ ખસી જાય છે, જ્યારે પહેલાં સોકેટ ખોલેલી દરેક એપ્લિકેશન પોતાનો જૂનો સ્રોત રાખે છે.
Windows પણ સ્વયંસંચાલિત ઇન્ટરફેસ મેટ્રિક સાથે એ જ કરે છે, લિંક ઝડપથી પક્ષપાત સાથે. Get-NetRoute -DestinationPrefix 0.0.0.0/0 ઉમેદવારોને ગોઠવે છે અને Find-NetRoute -RemoteIPAddress 203.0.113.10 સ્ટેક પસંદ કરે તે ઇન્ટરફેસ અને સ્રોત પરત આપે છે. જે ક્લાયન્ટ પોતાનું બાહ્ય સોકેટ એક ઇન્ટરફેસ સાથે બાંધે છે તે મેટ્રિક ઊંધું થયા પછી પણ તેનો ઉપયોગ ચાલુ રાખે છે; તે બંધનનો નિર્ણય છે, રૂટિંગ ખામી નહીં.
Android વિભાજનને દૃશ્ય બનાવે છે: ConnectivityManager ઉપલબ્ધ નેટવર્ક અને અલગ ડિફોલ્ટ જણાવે છે, અને જે VPN એપ સોકેટને Network ઑબ્જેક્ટ સાથે બાંધે છે તે ફરી ન બાંધે ત્યાં સુધી એ બંધન રાખે છે. macOS પર, scutil --nwi પ્રાથમિક ઇન્ટરફેસ અને સિસ્ટમ જે ક્રમ વાપરશે તે છાપે છે.
DNS, MTU અને IPv6 જોડાણ સાથે ખસે છે
નવું જોડાણ નવા રિઝોલ્વર લાવે છે. systemd-resolved સાથે DNS દરેક લિંક માટે છે, resolvectl status કઈ લિંક નામનો જવાબ આપે છે તે દર્શાવે છે, અને જે ગેસ્ટ નેટવર્ક પોતાનું રિઝોલ્વર આપે છે તે લિંક ફરી પ્રિય ન થાય ત્યાં સુધી ટનલે ધકેલેલું DNS વણવપરાયું રાખી શકે છે. કેપ્ટિવ પોર્ટલ વધુ ખરાબ કરે છે: પહેલા HTTPS વિનંતીનો જવાબ અંતિમ બિંદુને બદલે પોર્ટલ આપે છે, અને ક્લાયન્ટ મૃત સર્વર નોંધે છે.
માર્ગનું MTU પણ બદલાય છે. Ethernet અને Wi-Fi સામાન્ય રીતે 1500 બાઇટ વહન કરે છે, PPPoE 1492, અને મોબાઇલ લિંક ઘણી વાર ઓછું. નાનું MTU વારસામાં મળેલી ટનલ મોટા પેકેટ પર અટકે છે જ્યારે નાની વિનંતીઓ સફળ થાય છે, જે અડધું તૂટેલું જોડાણ તરીકે વંચાય છે. ping -M do -s 1472 203.0.113.10 DF સેટ કરીને 1500 બાઇટનું પેકેટ મોકલે છે; મૌન એટલે માર્ગ તમે ધાર્યું તેના કરતાં નાનો છે.
IPv6 બીજો અર્ધો ભાગ છે. નવું પ્રીફિક્સ આપતું નેટવર્ક ડ્યુઅલ-સ્ટેક ક્લાયન્ટ વાપરે તે સ્રોત બદલે છે, અને ફક્ત v4 ટનલ નીતિ આવે ત્યાં સુધી v6 ટ્રાફિકને બહાર રાખે છે. ip -6 route show default અને ip -6 addr show નવી લિંકને બિલકુલ v6 માર્ગ છે કે નહીં તેનો જવાબ આપે છે.
વર્ણન કરવાને બદલે સંક્રમણનું પુનરુત્પાદન કરો
એક નિરુપદ્રવી વિનંતી પસંદ કરો અને ફેરફારની બંને બાજુએ એ જ ત્રણ આદેશ ચલાવો: ip -br addr, ip route show default, ip route get 203.0.113.10. પછી જુઓ કે ટનલ હજી પેકેટ છોડે છે કે નહીં - tcpdump -ni any udp port 51820 WireGuard માટે, બાકીના બધા માટે અનુરૂપ પોર્ટ. જૂના સ્રોતથી નીકળતા પેકેટ એટલે બંધનની સમસ્યા. નવા સ્રોતથી જવાબ વગર નીકળતા પેકેટ એટલે દૂરની બાજુ અથવા વચ્ચેનું NAT.
પહેલી ખામી સાથે કઈ ઘટના સંપાત થઈ તે નોંધો: લિંક નીચે, સરનામું બદલાવો, અથવા ડિફોલ્ટ રૂટ બદલાવો. આ અલગ માલિકો તરફ ઇશારો કરે છે - ફરી બાંધવાની જરૂર હોય તેવો ક્લાયન્ટ, ફરી મેળવવાનું સરનામું, અથવા એવો રૂટ જે રૂપરેખા ફાઇલનો છે, કાયમી બાયપાસ નિયમનો નહીં.
ઠીક થયું કહેતા પહેલાં ખાતરી કરો કે સીધા ટ્રાફિકનો બ્લોક ગેપ દરમિયાન હજી ટકે છે અને નામ નવા જોડાણ દ્વારા રિઝોલ્વ થાય છે. જો સ્વિચ પછી ક્લાયન્ટ જૂનું અંતિમ બિંદુ રાખે, તો પહેલાં રોમિંગ અથવા float સેટિંગ ઠીક કરો. જો તે યોગ્ય રીતે રોમ કરે અને તોપણ જવાબ ન મળે, તો સર્વરની પીઅર ઓળખ અને માર્ગ પરના NAT તરફ જુઓ, અને બંને નેટવર્ક સંદર્ભ અહેવાલમાં રાખો જેથી આગળની વ્યક્તિ તેમની સરખામણી કરી શકે.