સ્પ્લિટ ટનલિંગ વિરુદ્ધ કંપની નીતિ: કયો નિયમ જીતે

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

ચેકબોક્સ વિશે દલીલ કરતા પહેલાં નક્કી કરો કે નીતિ કઈ મિલકતને રક્ષણ આપવા માટે છે.

નિયમ પાછળની મિલકત

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

ચોથું જૂથ એન્ડપોઇન્ટની સ્થિતિ લાગુ કરે છે: ડિસ્ક એન્ક્રિપ્શન સ્થિતિ, પેચ સ્તર, એજન્ટની સ્વાસ્થ્ય. ટનલને વિભાજિત કરવાથી તે બદલાતું નથી, જ્યારે એજન્ટના પોતાના ટ્રાફિકને ટાળતો બાયપાસ તેને બદલી શકે છે.

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

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

ચકાસણીઓ ક્રમમાં ચલાવો

નીચેનો ક્રમ અપવાદને ખરેખર નિષ્ફળ ગયેલી સૌથી નાની વસ્તુ સુધી મર્યાદિત કરે છે. જે ચકાસણી ટકતી નથી ત્યાં જ અટકો, કારણ કે પછીનો સુધારો અગાઉની ખામીની ભરપાઈ કરી શકતો નથી.

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

દરેક જવાબ એક હકીકત છે, અને અપવાદ વિનંતીને હકીકતોની જ જરૂર છે. VPN હેરાન કરે છે કે નહીં તેવી દલીલ તેમાંની એક નથી. વાતચીત શરૂ થાય તે પહેલાં જવાબો લખો.

સંકુચિત અપવાદ માંગો

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

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

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

અપવાદને ટકાઉ બનાવો

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

resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status

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

અપવાદ, તેનો હેતુ અને તે આવરી લેતા ઘટકોને ડિપ્લોયમેન્ટ નોંધો સાથે એ જ જગ્યાએ નોંધો. દસ્તાવેજ ન કરેલો અપવાદ આગલા ત્રિમાસિકની ઘટના બને છે, અને દસ્તાવેજ કરેલો અપવાદ એ વાતનો પુરાવો બને છે કે ડિઝાઇન વાસ્તવિક કાર્યભાર સંભાળે છે.