Apple VPN On Demand ના ડોમેન નિયમો ટનલ કેવી રીતે શરૂ કરે છે
ડોમેન નિયમ ફક્ત નક્કી કરે છે કે ટનલ ક્યારે ખૂલશે. connect-if-needed DNS પ્રોબ કેવી રીતે કામ કરે છે, રૂટ હજી પણ ટ્રાફિક કેમ પસંદ કરે છે અને પ્રોફાઇલ કેવી રીતે ચકાસવું.
જ્યારે તમે એક આંતરિક નામની વિનંતી કરો છો ત્યારે ટનલ ખૂલે છે અને જ્યારે આગલી એપને એટલી જ જરૂર હોય ત્યારે તે બંધ રહે છે. તે એપમાં બગ નથી; તે ડોમેન નિયમનો આકાર છે. Apple નું on-demand રૂપરેખાંકન જોડાણ બનાવવાની શરતો વર્ણવે છે, અને તે શરતોનું ડોમેન સ્વરૂપ એક પેકેટ પણ ખસે તે પહેલાં સિસ્ટમ રિઝોલ્વરને પ્રશ્ન પૂછે છે. બે પ્રશ્નો સતત ભળી જાય છે: ટનલ ક્યારે ઉપર આવવી જોઈએ અને ટનલ અસ્તિત્વમાં આવ્યા પછી શું વહન કરે છે. પ્રથમ ટ્રિગર છે, બીજું રૂટ અને રિઝોલ્વર નીતિ છે, અને એક પ્રોફાઇલ સામાન્ય રીતે બંનેને એક જ પેલોડમાં સેટ કરે છે, તેથી સાચો ડોમેન નિયમ પણ તમને ખોટા નેટવર્ક પર છોડી શકે છે.
ટ્રિગર અને ટ્રાફિક પસંદગી જુદા સ્તરે રહે છે
on-demand નિયમ VPN પેલોડના on-demand શબ્દકોશમાં રહે છે: નિયમોની ક્રમબદ્ધ યાદી, દરેકમાં એક ક્રિયા અને મેળ શરતોનો સમૂહ. જ્યારે કનેક્ટિવિટી બદલાય છે અથવા કંઈક નેટવર્ક સુધી પહોંચવાનો પ્રયાસ કરે છે ત્યારે સિસ્ટમ તેમનું મૂલ્યાંકન કરે છે, અને ક્રિયા નક્કી કરે છે કે ટનલ ઉપર લેવાય, મૂલ્યાંકન થાય, ડિસ્કનેક્ટ થાય કે અવગણાય. આ બધું પ્લેટફોર્મના નેટવર્કિંગ સ્તરમાં થાય છે, તમારી એપને સોકેટ મળે તે પહેલાં.
ત્યારપછી જે થાય છે તે કીનું અલગ જૂથ છે: ટનલની IPv4 અને IPv6 સેટિંગ્સ, તેના સમાવિષ્ટ અને બાકાત રૂટ, તેના DNS સર્વર સરનામાં, અને iOS તથા iPadOS પર પ્રતિ-એપ મેપિંગ જે નક્કી કરે છે કે કઈ એપ ટનલનો ઉપયોગ કરી શકે. એક પ્રોફાઇલ પહોળા ટ્રિગરને સાંકડા રૂટ સાથે જોડી શકે છે, અથવા સાંકડા ટ્રિગરને ડિફોલ્ટ રૂટ સાથે. ફક્ત એક અડધું વાંચો અને બીજું અડધું ખામી જેવું લાગશે.
મારી પાસે એક લેબ પ્રોફાઇલ છે જે આંતરિક ડોમેન હેઠળ કંઈપણ માંગવામાં આવે ત્યારે જોડાય છે, પણ ટનલમાં ફક્ત એક /16 રૂટ કરે છે. તે તેના પેલોડમાં જે કહે છે તે બરાબર કરે છે, અને તે એવા પ્રકારની પ્રોફાઇલ પણ છે જે ટિકિટ પેદા કરે છે: લોકો ધારે છે કે જોડાયેલી ટનલ એટલે તેમનો ટ્રાફિક તેની અંદર છે.
ડોમેન નિયમ રિઝોલ્વરને ખરેખર શું પૂછે છે
નિયમનું ડોમેન સ્વરૂપ, જેને ઘણી વાર connect-if-needed કહેવાય છે, પેકેટ પેલોડ તપાસતું નથી કે URL જોતું નથી. જ્યારે નામ રિઝોલ્વ થાય છે, સિસ્ટમ તેને નિયમના ડોમેન સાથે સરખાવે છે અને મેળ પડે તો પૂછે છે કે તે નામ ટનલ પ્રદાન કરતા DNS સર્વર દ્વારા રિઝોલ્વ થઈ શકે છે કે નહીં. જો ટનલનું રિઝોલ્વર જવાબ આપે, તો નામ આંતરિક ગણાય છે અને જોડાણ શરૂ થાય છે. જો સ્થાનિક રિઝોલ્વર જવાબ આપે, તો નામ બાહ્ય ગણાય છે અને કોઈ ટનલ દેખાતી નથી. Apple નું ડિપ્લોયમેન્ટ ઝલક આને નેટવર્ક શોધ અને પછી જોડાણ મૂલ્યાંકન તરીકે વર્ણવે છે.
બે પરિણામ આવે છે. પ્રોફાઇલમાં ટનલની અંદર DNS સર્વરનો ઉલ્લેખ હોવો જોઈએ; ટનલ રિઝોલ્વર વગરના ડોમેન નિયમ પાસે સરખાવવા જેવું કંઈ નથી, તેથી મૂલ્યાંકન તમે અપેક્ષા રાખો તે મેળ આપી શકતું નથી. અને શોધ સિસ્ટમ રિઝોલ્વર સુધી પહોંચવી જોઈએ. જે એપ કે બ્રાઉઝર પોતાનું એન્ક્રિપ્ટેડ DNS ચલાવે છે, જે એક્સ્ટેન્શન સ્થાનિક રીતે જવાબ આપે છે, અથવા શાબ્દિક સરનામા સાથેનું જોડાણ — તે કદી તે નામ રિઝોલ્યુશન પેદા કરતું નથી જેની નિયમ રાહ જોતો હતો. મેં પસાર કરેલા સૌથી લાંબા બપોરોમાંનો એક ત્યારે પૂરો થયો જ્યારે મને જાણવા મળ્યું કે ટનલ સામેનું ક્લાઇન્ટ DNS over HTTPS વાપરી રહ્યું હતું.
કેશિંગ ટ્રિગરને પણ દૂર કરે છે. કેશમાં પહેલેથી રહેલા નામનો જવાબ તે પ્રોબ વગર આપી શકાય છે જે ટનલ શરૂ કરતો, તેથી ગઈકાલે કામ કરતો નિયમ રીબૂટ પછી, અથવા ટનલ થોડા સમય ઉપર રહ્યા પછી નિષ્ફળ જાય છે. macOS પર sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder સ્થિતિ રીસેટ કરે છે; iOS પર એરપ્લેન મોડ ચાલુ-બંધ કરવાથી કે ઉપકરણ રીસ્ટાર્ટ કરવાથી તમને સરખી સ્વચ્છ શરૂઆત મળે છે.
મેળનો વ્યાપ: નામ, એપ અને નેટવર્ક
ડોમેન મેચિંગ ઘણા પ્રકારોમાંનો એક છે. નિયમ ઇન્ટરફેસ પ્રકાર (Wi-Fi, સેલ્યુલર, Ethernet) અને ચોક્કસ SSID સાથે પણ મેળ ખાઈ શકે છે, અને પ્રતિ-એપ કે Safari-ડોમેન એન્ટ્રી ટનલને એક વર્કફ્લો સાથે બાંધે છે. તે બંધન તે વિચિત્ર અનુભવ સમજાવે છે જેમાં ફક્ત એક એપ બાકીની બધી કરતાં અલગ વર્તે છે: બીજી એપ ટનલના વ્યાપની બહાર છે, તેથી ટનલ આઇકન જોડાયેલું કહે ત્યારે પણ તેઓ સ્થાનિક માર્ગ વાપરતા રહે છે.
લોકો ધારે છે તેના કરતાં ક્રમ વધુ મહત્વનો છે. નિયમો ક્રમમાં મૂલ્યાંકિત થાય છે અને પ્રથમ મેળ ખાતો નિયમ ક્રિયા આપે છે, તેથી સાંકડા ડોમેન નિયમ ઉપર મૂકેલો પહોળો કોઈપણ-Wi-Fi-પર-જોડાઓ નિયમ શાંતિથી જીતી જશે અને ડોમેન નિયમને પરીક્ષણ-અયોગ્ય બનાવશે. ડોમેન યાદી ફરી લખતા પહેલાં ખાતરી કરો કે કોઈ અગાઉનો નિયમ પહેલેથી મેળ ખાધો નથી.
એટલે જ always-on ફક્ત વધુ કડક on-demand નિયમ નથી. always-on અમલીકરણ અલગ ડિપ્લોયમેન્ટ મોડ છે જેની પોતાની દેખરેખ અને સંચાલન આવશ્યકતાઓ છે; તે નામ પર પ્રતિક્રિયા આપવાને બદલે ટનલ ખુલ્લી રાખે છે. જો તમને કદી ન પડતી ટનલ જોઈએ, તો ડોમેન નિયમ ખોટું સાધન છે.
તૂટેલા નિયમ જેવી નિષ્ફળતાઓ
ડોમેન નિયમ કામ નથી કરતો એવા મોટા ભાગના અહેવાલ પાંચ જગ્યાઓમાંની એકમાં પડે છે, અને તેમાંથી ફક્ત છેલ્લી જ નિયમની લખાણ છે.
| What you see | Layer | First check |
|---|---|---|
| Tunnel comes up, internal site still fails | route or resolver after connect | netstat -rn, scutil --dns |
| Tunnel never comes up for that name | trigger path | fresh lookup, cache flush, private DNS |
| Tunnel comes up for every app | scope, or an earlier rule | rule order, per-app mapping |
| Tunnel drops and will not return on the same Wi-Fi | interface or SSID match, admission | captive portal, SSID string, auth prompt |
| Tunnel returns after you disconnect it | profile ownership | profiles show |
કેપ્ટિવ પોર્ટલ પોતાની લાઇનને લાયક છે, કારણ કે હોટેલ અને એરપોર્ટનું Wi-Fi તે જ શોધને અટકાવે છે જેના પર નિયમ આધાર રાખે છે. જ્યાં સુધી પોર્ટલ ઉપકરણને પ્રવેશ ન આપે, ટનલનું DNS સર્વર પહોંચની બહાર રહે છે, પ્રોબ નિષ્ફળ જાય છે, અને નિષ્ફળતા ખોટી જોડણીવાળા ડોમેન જેવી લાગે છે. પ્રમાણીકરણ બીજો શાંત કિસ્સો છે: નિયમ ચાલુ થઈ શકે, ટનલ જોડાવા લાગે, અને જોડાણ સમાપ્ત થયેલા પ્રમાણપત્ર પર કે બીજા ડિસ્પ્લે પર દેખાતા પ્રોમ્પ્ટ પર મરી જાય.
IPv6 એક પ્રકાર બનાવે છે જેને ખોટી રીતે નિદાન કરવું સરળ છે. બંને સરનામા કુટુંબ ધરાવતા નામનો જવાબ પહેલા AAAA રેકોર્ડથી આપી શકાય છે, જ્યારે ટનલની રૂટ યાદી ફક્ત IPv4 ધરાવે છે. એક બ્રાઉઝર સફળ થાય, બીજું નિષ્ફળ, અને ડોમેન યાદી સંપૂર્ણ નિર્દોષ છે.
વાસ્તવિક વિનંતી સાથે, આ ક્રમમાં પરીક્ષણ કરો
અનુમાન કરતા પહેલાં નીતિ વાંચો. macOS પર sudo profiles show -type configuration VPN પેલોડ સહિત સ્થાપિત પ્રોફાઇલ છાપે છે, scutil --nc list સેવાની સ્થિતિ દર્શાવે છે, અને scutil --nc show <service> સિસ્ટમ વાપરતો on-demand શબ્દકોશ છાપે છે. મેનેજ્ડ iPhone કે iPad પર એ જ પેલોડ મેનેજમેન્ટ કન્સોલ કે MDM રિપોર્ટથી આવે છે. નેટવર્કિંગ લોગ macOS પર log stream --predicate 'subsystem == "com.apple.networkextension"' સાથે, અને ફોન જોડાયેલો હોય ત્યારે ઉપકરણ કન્સોલ દ્વારા ઉપલબ્ધ છે.
પછી એવા હોસ્ટનામ સાથે પરીક્ષણ કરો જે સત્રમાં પહેલા પૂછવામાં આવ્યું ન હોય. ટનલના DNS ઝોનમાં એવું નામ પસંદ કરો જે તમે જાણો છો કે આંતરિક રીતે રિઝોલ્વ થાય છે, તેને એક વાર માંગો, અને ટનલ દેખાય છે કે નહીં તે જુઓ. એ જ શોધ બે વાર ચલાવો: બીજો પ્રયાસ કેશ માર્ગનો ઉપયોગ કરે છે, અને બંને વચ્ચેનો તફાવત તમને કહે છે કે ટ્રિગર રિઝોલ્યુશન છે કે રૂટિંગ.
ટનલ ઉપર આવ્યા પછી બે સ્તર અલગથી ચકાસો. netstat -rn -f inet અને netstat -rn -f inet6 દર્શાવે છે કે દરેક પ્રીફિક્સ ક્યાં નિર્દેશ કરે છે, scutil --dns રિઝોલ્વરનો ક્રમ અને કઈ ઇન્ટરફેસ કયા રિઝોલ્વરની માલિક છે તે દર્શાવે છે, અને nettop -m route દર્શાવે છે કે કઈ ઇન્ટરફેસ બાઇટ્સ લઈ ગઈ. જો ટનલ ઉપર છે અને રિઝોલ્વર સાચું છે પણ સ્રોત હજી નિષ્ફળ જાય, તો નિયમ સંપાદિત કરવાનું બંધ કરો; સર્વર-સાઇડ અધિકૃતિ અને પરત રૂટ તપાસો.
જ્યારે નિયમ બીજા કોઈનો હોય
જો જોડાણ કાપ્યા પછી ટનલ ફરી દેખાય, તો નિયમ સામાન્ય રીતે એપનો નહીં પણ પ્રોફાઇલનો હોય છે: MDM દ્વારા ધકેલાયેલું રૂપરેખાંકન, બાકી રહેલી વ્યક્તિગત પ્રોફાઇલ, અથવા બીજા ક્લાઇન્ટે સ્થાપિત કરેલી પ્રોફાઇલ. sudo profiles show -type configuration અને on-demand કીની શોધ તેને સાંકડું કરશે, અને દૂર કરવાનો માર્ગ પ્રોફાઇલ છે, મેનુ બારનો ટોગલ નહીં. સેવા એન્ટ્રી કે એપ કાઢી નાખવાથી નિયમ પાછળ રહી જાય છે, અને આગલી સ્થાપના ફરી તેનો વારસો મેળવે છે.
એક પરીક્ષણ માલિકી નક્કી કરે છે: ડિસ્કનેક્ટ કરો, રાહ જુઓ, ફરી આંતરિક નામ માંગો. જો ટનલ પાછી આવે, તો ટ્રિગર ડિઝાઇન મુજબ કામ કરે છે અને ખુલ્લો પ્રશ્ન એ છે કે તેને કોણ સંભાળે છે અને તે વ્યાપ તમે ઇચ્છો છો કે નહીં.
આને બગ તરીકે નોંધતા પહેલાં એ જ પાંચ તપાસ કરો: પેલોડમાં ટનલ રિઝોલ્વર સરનામાં હાજર છે, નામ કેશ થયું નથી, અગાઉનો કોઈ નિયમ પહેલેથી મેળ ખાધો નથી, રૂટ યાદી AAAA માર્ગ આવરે છે, અને એપ ટનલના વ્યાપમાં છે. પાંચેય સાચા હોય ત્યારે નિયમ પોતાનું કામ કરે છે અને ખામી માર્ગમાં આગળ છે.