Wi-Fi થી સેલ્યુલર પર જવા પછી કિલ સ્વિચ: શું તૂટે છે

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

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

હેન્ડઓવર ખરેખર શું ફરીથી લખે છે

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

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

છિદ્ર ન પાડતાં બહારની ટનલ ફરી બનાવવી

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

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

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

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

જ્યારે નવી કડી IPv6 લાવે અને નિયમો ન લાવે

સેલ્યુલર અને મહેમાન નેટવર્ક ઘણી વાર વૈશ્વિક IPv6 પ્રીફિક્સ આપે છે, જ્યારે ઓફિસના વાયરવાળા LAN એ કદી આપ્યું ન હોય. ફક્ત IPv4 નિયમો તરીકે લખાયેલી નીતિ — મોટાભાગની હાથે બનાવેલી iptables અને nftables વાનગીઓનું ડિફૉલ્ટ સ્વરૂપ — એમાંથી કંઈ આવરતી નથી. ટનલ જોડાયેલી રહે છે, IPv6 પહોંચ ધરાવતી એપ્લિકેશનો તેની બહાર નીકળી જાય છે, અને સૂચક તફાવત બતાવી શકતું નથી કારણ કે ટનલ ખરેખર ચાલુ છે. વિરુદ્ધ કેસ પણ એટલો જ સામાન્ય છે: ફક્ત IPv6 માટેનો નિયમસમૂહ એવા નેટવર્ક પર કંઈ કરતો નથી જે v6 આપતું નથી.

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

ip -4 route show default
ip -6 route show default
sudo nft list ruleset | grep -c 'ip6 '

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

રિઝોલ્વર સત્રની વચ્ચે હાથ બદલે છે

આધુનિક સિસ્ટમોમાં રિઝોલ્વર કડીઓ સાથે જોડાયેલા હોય છે, તેથી નવી કડી નવા રિઝોલ્વર સમૂહ સાથે અને કદાચ અલગ split-DNS દૃશ્ય સાથે આવે છે. systemd-resolved દરેક કડી માટે scope રાખે છે અને રૂટ પ્રમાણે તેમની વચ્ચે પસંદ કરે છે, જ્યારે macOS ડાયનેમિક સ્ટોરમાંથી scoped રિઝોલ્વર વાંચે છે અને ઇન્ટરફેસનો ક્રમ માને છે. પોતાનું રિઝોલ્વર બેસાડતો ક્લાયન્ટ કડીના રિઝોલ્વર સાથે સ્પર્ધા કરે છે, અને કોઈ ન જોતા પ્રાથમિકતાના નિયમો વિજેતા નક્કી કરે છે. પછી નામ ઉકેલવું તૂટી શકે છે જ્યારે પેકેટ ફિલ્ટરિંગ બરાબર એ જ કરે છે જેના માટે તે લખાયું હતું.

રૂપરેખાંકિત રિઝોલ્વરને બદલે સક્રિય રિઝોલ્વર વાંચો. systemd હોસ્ટ પર status પેટા-આદેશ બતાવે છે કે દરેક scope કઈ કડીમાંથી આવ્યો અને private-DNS નામ અમલમાં છે કે નહીં:

resolvectl status --no-pager
resolvectl query intranet.example.com

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

હેન્ડઓવરનો અભ્યાસ કરો અને રેકોર્ડ રાખો

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

અપવાદોને પોતાનો પાસ જોઈએ, કારણ કે જૂના નેટવર્ક પર વ્યાજબી ઠરેલો બાયપાસ નવા પર આપોઆપ વ્યાજબી ઠરતો નથી. ઘરના LAN પરનું પ્રિન્ટર, NAS અથવા captive portal સેલ્યુલર પર સમાન ધરાવતું નથી, અને જે અપવાદ ત્યાં પહોંચતો હતો તે સમાન વગરનો નિયમ બની જાય છે.

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