તે સાચવેલી Mac VPN પ્રોફાઇલ પાછળ કયો પ્રોટોકોલ છે?

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

લેબલ ઉપનામ છે, પેલોડ પ્રકાર જાહેર કરે છે

macOS VPN સેવા એ સિસ્ટમ કન્ફિગરેશન એન્ટ્રી છે જેમાં દેખાતું નામ, માલિક ક્લાયન્ટ અને ટાઇપ કરેલી સેટિંગ્સનો સમૂહ હોય છે. દેખાતું નામ મુક્ત ટેક્સ્ટ છે, એન્ટ્રી બનાવનાર કોઈપણ તેને સંપાદિત કરી શકે છે, અને વપરાશકર્તાઓ મેનુ બારમાં જે ભાગ જુએ છે તે આ જ છે. સેટિંગ્સ તથ્યો ધરાવે છે: કયો કનેક્શન પ્રકાર, કયો ગેટવે, કઈ પ્રમાણીકરણ યોજના. કંઈ પણ આ બેને સમન્વયમાં રાખતું નથી, તેથી «L2TP ઓફિસ» નામની પ્રોફાઇલ IKEv2 સેવા હોઈ શકે છે.

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

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

પેલોડમાં બીજા કંઈપણ પહેલાં VPNType વાંચો

Apple ની મેનેજ કરેલી VPN પેલોડ સ્કીમા તેનો કનેક્શન પ્રકાર VPNType કીમાં જાહેર કરે છે, જેનું PayloadType com.apple.vpn.managed હોય તેવા શબ્દકોશની અંદર. મૂલ્ય IKEv2, IPsec, L2TP અથવા VPN જેવું ટૂંકું ટોકન છે, અને પેલોડમાં બાકીનું બધું તે ટોકન અનુસાર અર્થઘટિત થાય છે.

<key>PayloadType</key>
<string>com.apple.vpn.managed</string>
<key>VPNType</key>
<string>IKEv2</string>
<key>IKEv2</key>
<dict>
  <key>RemoteAddress</key>
  <string>vpn.head-office.example</string>
  <key>RemoteIdentifier</key>
  <string>ikev2.head-office.example</string>
</dict>

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

જૂનું મૂલ્ય, જેમ કે PPTP, હજી જૂની ફાઇલમાં દેખાઈ શકે છે, જ્યારે વર્તમાન macOS નવી કન્ફિગરેશન માટે તેને વિકલ્પ તરીકે આપતું નથી. સંગ્રહિત પ્રોફાઇલમાં ટોકન મળવો એ પુરાવે છે કે શું લખાયું હતું, એ નહીં કે ઓપરેટિંગ સિસ્ટમ હજી શું સ્વીકારશે.

કસ્ટમ પ્રકારોને VPNSubType અને માલિક એપ્લિકેશનની જરૂર છે

જ્યારે VPNType VPN હોય, ત્યારે પેલોડે VPNSubType પણ ધરાવવું પડે, જે કનેક્શન અમલમાં મૂકતું પ્લગ-ઇન અથવા Network Extension પ્રદાતા ઓળખે છે. તે ઓળખકર્તા જ કનેક્શનને ચોક્કસ ક્લાયન્ટ તરફ મોકલે છે, તેથી ખોટો સબટાઇપ એવી પ્રોફાઇલ બનાવે છે જે સ્થપાય છે અને પછી શરૂ થવાનો ઇનકાર કરે છે.

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

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

Mac એ ખરેખર શું રૂપરેખાંકિત કર્યું છે તેની સૂચિ બનાવો

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

scutil --nc list
scutil --nc show "Office VPN"

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

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

સંગ્રહિત સેટિંગ્સને જીવંત સેશનથી અલગ રાખો

સંગ્રહિત પ્રોફાઇલ ઇરાદાનું નિવેદન છે. તે દર્શાવતું નથી કે ગેટવે હજી તે સેવા આપે છે, કે આ પ્રોફાઇલ સક્રિય છે, કે સેશને સફળતાપૂર્વક વાટાઘાટ કરી છે. તે ત્રણ અલગ પ્રશ્નો છે અને દરેકનો પોતાનો પુરાવો છે.

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

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