ડિસ્કનેક્ટ દબાવવું કામ કરે છે, અને દસ સેકન્ડ પછી ટનલ કોઈપણ રીતે પાછી આવે છે. એ લૂપ ભાગ્યે જ VPN ક્લાયન્ટની ખોટી વર્તન છે; તે એક રિકવરી સ્ક્રિપ્ટ છે જે હંમેશા ફક્ત એક જ પ્રશ્ન પૂછતી હતી, «શું તે નીચે છે?», અને કનેક્ટ કરીને તેનો જવાબ આપતી હતી. જ્યારે તમે વપરાશકર્તાએ જવાબ આપેલો પ્રશ્ન સિસ્ટમ જે પ્રશ્નની જાણ કરે છે તેનાથી અલગ કરો છો, ત્યારે સુધારો લાંબી ઊંઘને બદલે થોડી સ્થિતિ બની જાય છે.

બે પ્રશ્નો, એક નહીં

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

IntentWhat you observeWhat to do
WantedDropped unexpectedlyAllow one supported recovery attempt
Paused by the userDisconnectedDo nothing until intent changes
WantedAlready connectingWait instead of starting a rival attempt
WantedAuthentication needs a personPrompt, then stop replaying credentials

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

નિરીક્ષિત સ્થિતિ પસંદગી નથી

Apple નું Network Extension સ્થિતિ મોડેલ connecting, connected, disconnecting, disconnected અને recovery સ્થિતિઓની જાણ કરે છે. પાંચેય કનેક્શનનું વર્ણન કરે છે. તેમાંથી કોઈ કહેતું નથી «વપરાશકર્તાએ આ પ્રોફાઇલને થોભાવેલી રાખવાનું કહ્યું», કારણ કે તે કોઈ કનેક્શન સ્થિતિ જ નથી. જે ક્લાયન્ટ્સ તે ફ્રેમવર્ક પર બનેલા નથી તે પોતાના સમર્થિત નિયંત્રણો અને સ્થિતિ કૉલ્સ આપે છે, અને તેઓ પોતાની શબ્દાવલીમાં એ જ રેખા દોરે છે.

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

scutil --nc list
scutil --nc status "Office VPN"

આ પ્રોફાઇલ શરૂ કરવાની બીજા કોને પરવાનગી છે

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

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

ફરી પ્રયાસોને કંટાળાજનક બનાવો

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

ઝડપી ફરી પ્રયાસ સ્ક્રીન પર ખરેખર શું ઉત્પન્ન કરે છે તે જુઓ. વપરાશકર્તા કાઢી નાખે તેવા પુનરાવર્તિત સંવાદો એક સ્પષ્ટ નિષ્ફળતા સંદેશા કરતાં ખરાબ છે, અને તે લોકોને પ્રોમ્પ્ટ વાંચ્યા વિના ક્લિક કરવાનું શીખવે છે.

વિરામ અને ટ્રાફિક નીતિ અલગ વચનો છે

વપરાશકર્તાએ થોભાવેલી ટનલ ઘણી વાર ટ્રાફિકને જાણી જોઈને અવરોધિત રાખે છે, જે kill switch શૈલીની નીતિનો આખો હેતુ છે. તેનો અર્થ એ છે કે વિરામે બરાબર એક જ વસ્તુનું વચન આપવું જોઈએ: રિકવરી અટકે છે. તે ચૂપચાપ બદલવું જોઈએ નહીં કે નેટવર્ક શું મંજૂરી આપે છે.

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

સંબંધિત લેખો