શું એક VPN સેવા Windows, Mac અને Linux ડેસ્કટોપને આવરી શકે?
એક એક્સેસ પ્લાન Windows, Mac અને Linux ડેસ્કટોપને સેવા આપી શકે, પરંતુ ગેટવે ઓળખ, ક્રેડેન્શિયલ, રૂટ અને રિઝોલ્વર નીતિ નિશ્ચિત થયા પછી જ.
એક ટીમમાં ત્રણ લેપટોપ, ત્રણ અલગ VPN મેનુ, અને એક ટિકિટ કે જે કહે છે કે કનેક્શન Mac સિવાય બધે કામ કરે છે. એ ક્લાયન્ટ્સ પાછળનો પ્લાન મેનુ અલગ હોવા છતાં એકસમાન હોઈ શકે. જે મેળ ખાવું જોઈએ તે મોટાભાગના રોલઆઉટ ધારે છે તેના કરતાં સાંકડું છે: એક ગેટવે ઓળખ, એક ક્રેડેન્શિયલ પ્રકાર, એક રૂટ સમૂહ અને એક રિઝોલ્વર નીતિ. કોઈ પ્રોફાઇલ નિકાસ કરે તે પહેલાં એ ચાર લખી લો, અને પ્લેટફોર્મનું કામ તપાસની જગ્યાએ ચેકલિસ્ટ બની જશે.
ક્લાયન્ટ ફાઇલથી નહીં, એક્સેસ કરારથી શરૂ કરો
એક્સેસ કરાર એ પાંચ લીટીઓ છે જે સમીક્ષક વેન્ડર કન્સોલ ખોલ્યા વિના ચકાસી શકે. તે નામ આપે છે જે ખાનગી પ્રીફિક્સ સુધી પહોંચી શકાય તે જરૂરી છે, જે આંતરિક નામો ઉકેલાવા જોઈએ, જે રિઝોલ્વર તેમને જવાબ આપે છે, જે ટ્રાફિક સ્થાનિક માર્ગ પર રહી શકે છે, અને જે ગેટવે સર્ટિફિકેટ ક્લાયન્ટે જોવાની અપેક્ષા રાખવી જોઈએ. રોલઆઉટમાં બાકીનું બધું એ લીટીઓનું ફાઇલ ફોર્મેટમાં ભાષાંતર છે.
ઓફિસનું ઉદાહરણ આકારને મૂર્ત બનાવે છે: 10.60.0.0/16 માં એપ્લિકેશન સર્વર, corp.example હેઠળ ખાનગી નામો, 10.61.0.53 પર આંતરિક રિઝોલ્વર, અને સામાન્ય બ્રાઉઝિંગ જે માર્ગ પર ઉપકરણ પહેલેથી જ વપરાય છે ત્યાં જ છોડી દેવાય છે. છેલ્લી વસ્તુ ક્લાયન્ટ ડિફોલ્ટ નહીં પણ નીતિ નિર્ણય છે, અને કોઈ વિરુદ્ધ ન કહે તો ઘણા ક્લાયન્ટ બધું ટનલ દ્વારા મોકલશે. કરારને તારીખ અને માલિક સાથે નોંધો, કારણ કે એ નોંધ જ પછી તમને કહેશે કે ટનલ બદલાઈ કે નીતિ.
એક પ્રોટોકોલ અને એક પ્રમાણીકરણ જોડી પસંદ કરો જેનો તમે બચાવ કરી શકો
સર્ટિફિકેટ આધારિત ગેટવે પ્રમાણીકરણ અને વપરાશકર્તા માટે EAP સાથે IKEv2 સામાન્ય પસંદગી છે જ્યારે ત્રણેય પ્લેટફોર્મને વધારાના સોફ્ટવેર વિના કામ કરવું પડે, કારણ કે Windows, macOS અને NetworkManager દરેક IKEv2 ક્લાયન્ટ આપે છે. મુશ્કેલી એ છે કે IKEv2 નું સમર્થન એ લેબલ વર્ણવે છે, લક્ષણોનો સમૂહ નહીં. EAP પદ્ધતિઓ, હાર્ડવેર આધારિત કી, સર્ટિફિકેટ-થી-એકાઉન્ટ મેપિંગ અને સ્વયં પુનઃકનેક્શન પ્રત્યેક પ્લેટફોર્મ માટે અલગથી અમલમાં મૂકાય છે. ત્રણમાંથી બે પર કામ કરતું સંયોજન એટલું સામાન્ય છે કે પરીક્ષણ ન થાય ત્યાં સુધી એવું ધારી લેવું જોઈએ.
ડિપ્લોયમેન્ટ ગાઇડ લખાય તે પહેલાં દરેક લક્ષ્ય પ્લેટફોર્મ પર જોડીનું પરીક્ષણ કરો, પછી નહીં. જે ગેટવે EAP-MSCHAPv2 અને EAP-TLS બંને આપે છે તે તમને પાછા ખસવાની જગ્યા આપે છે, જો પાછા ખસવું ઘટનામાં જ શોધાયા વિના સમર્થિત તરીકે દસ્તાવેજીકૃત હોય. બે સમર્થિત માર્ગ સસ્તું વીમો છે; અદસ્તાવેજીકૃત ત્રીજો માર્ગ ભવિષ્યની ટિકિટ છે.
જ્યારે કોઈ એક જોડી ત્રણેય ક્લાયન્ટને આવરી લેતી નથી, ત્યારે પ્રામાણિક વિકલ્પો છે ક્લાયન્ટ ઉમેરવો, ગેટવે પ્રોફાઇલ ઉમેરવો, અથવા સમર્થિત પ્લેટફોર્મની યાદી સાંકડી કરવી. જે પ્લેટફોર્મ સૌથી મોટેથી ફરિયાદ કરે છે ત્યાં સર્ટિફિકેટ માન્યતા બંધ કરવી એમાંનો એક નથી. એ ફેરફાર સુસંગતતાના અંતરને અટકાવવાના જોખમમાં ફેરવે છે, અને રોલઆઉટનું કોઈ પણ પછીનું પગલું તેને સુધારતું નથી.
કરારમાંથી દરેક પ્લેટફોર્મ માટે એક આર્ટિફેક્ટ બનાવો
Windows VPNv2 પ્રોફાઇલ લે છે, જે MDM દ્વારા પહોંચાડાય છે અથવા Add-VpnConnection અને તેના XML પેલોડ સાથે સ્થાનિક રીતે બનાવાય છે. જે ભાગો દુખે છે તે સ્કોપ અને વિશ્વાસ છે. ઉપકરણ-સ્કોપવાળી પ્રોફાઇલ અને વપરાશકર્તા-સ્કોપવાળી પ્રોફાઇલ અલગ સ્ટોરમાં ઇન્સ્ટોલ થાય છે, તેથી ક્લાયન્ટને જરૂરી સર્ટિફિકેટ તમે પસંદ કરેલા સ્કોપ સાથે મેળ ખાતા સ્ટોરમાં હોવું જોઈએ. ખોટી જોડી એવી પ્રોફાઇલ બનાવે છે જે સ્વચ્છ રીતે આયાત થાય અને પછી પ્રથમ કનેક્શન પર નિષ્ફળ જાય.
macOS મેનેજ્ડ VPN પેલોડ સાથેની કન્ફિગરેશન પ્રોફાઇલ લે છે, જે સહી કરીને MDM દ્વારા મોકલાય છે અથવા પાઇલટ માટે હાથે ઇન્સ્ટોલ થાય છે. ઓળખ અને CA શૃંખલા અલગ પેલોડ તરીકે મુસાફરી કરે છે, તેથી પ્રોફાઇલ ફરિયાદ વિના ઇન્સ્ટોલ થઈ શકે અને છતાં કનેક્ટ થતી વખતે નિષ્ફળ જાય. પેલોડની યાદી તપાસો, ફક્ત ઇન્સ્ટોલનું પરિણામ નહીં.
Linux NetworkManager પાછળના બેકએન્ડ પર આધાર રાખે છે, અને strongSwan તથા NetworkManager પ્લગઇન અલગ પેકેજ છે. કનેક્શન ગુણધર્મો સામાન્ય VPN કી નહીં પણ પ્લગઇન-વિશિષ્ટ છે, તેથી બીજા પ્લગઇનમાંથી કોપી કરેલી કી ઘણી વાર ભૂલ વિના સેવ થાય અને પછી સક્રિયકરણમાં નિષ્ફળ જાય. પ્લગઇન ખરેખર ક્યાં ચાલશે ત્યાં હાજર છે તેની ખાતરી કરવા સ્વચ્છ ઇમેજ પર કનેક્શન બનાવો.
ત્રણેય આર્ટિફેક્ટ ફોર્મેટમાં અલગ છે, પણ દરેક એ જ પાંચ કરાર-લીટીઓ એન્કોડ કરે છે. આર્ટિફેક્ટ પૂર્ણ છે કે નહીં તેની પરીક્ષા આ છે: દરેક લીટી ક્યાંક રજૂ થઈ છે, અને રસ્તામાં વધારાનું કંઈ શોધાયું નથી.
| Platform | Artifact | Check before handoff |
|---|---|---|
| Windows | VPNv2 profile or Add-VpnConnection | Scope matches certificate store |
| macOS | Managed VPN payload plus certificate payload | Both payloads present in one profile |
| Linux | NetworkManager connection with strongSwan backend | Plugin package installed on the image |
સ્વચ્છ એકાઉન્ટ પર રૂટ, રિઝોલ્વર અને પુનઃકનેક્શન ચકાસો
કનેક્ટેડ હોવું એ સ્વીકૃતિ પરીક્ષા નથી. Windows પર Get-VpnConnection પ્રોફાઇલ બતાવે છે અને route print બતાવે છે કે ખાનગી પ્રીફિક્સ ટનલ ઇન્ટરફેસ પર ઉતર્યું છે કે નહીં. macOS પર scutil --nc list સક્રિય સેવાની પુષ્ટિ કરે છે જ્યારે scutil --dns સિસ્ટમ ખરેખર ઉપયોગ કરશે તે રિઝોલ્વર ક્રમ બતાવે છે.
Linux પર nmcli connection show --active સાબિત કરે છે કે કનેક્શન ઉપર છે અને resolvectl status દરેક લિંક માટે DNS બતાવે છે. કનેક્શન ફાઇલમાં હાજર પણ લિંક-મુજબના આઉટપુટમાં ગેરહાજર રિઝોલ્વર એટલે સ્પ્લિટ DNS લાગુ નથી થઈ રહ્યું. આ નામ ઉકેલાવા અને ટનલ દ્વારા નામ ઉકેલાવા વચ્ચેનો તફાવત છે, અને તે બદલે છે કે આગળનું પગલું કઈ સપોર્ટ ટીમ પાસે છે. લિંક-મુજબનું આઉટપુટ કનેક્શન આવ્યા પહેલાં અને પછી સરખાવો, ફક્ત પછી નહીં.
આખી તપાસ નવા એકાઉન્ટ સાથે ચલાવો, જેમાં કોઈ કેશ કરેલા ક્રેડેન્શિયલ ન હોય અને એડમિનિસ્ટ્રેટર દ્વારા ઇન્સ્ટોલ કરેલું સર્ટિફિકેટ ન હોય. પછી સસ્પેન્ડ અને રિઝ્યુમ પછી તેને પુનરાવર્તિત કરો, અને ક્રેડેન્શિયલ ફરી દાખલ કરવા ફરજ પાડ્યા પછી વધુ એક વાર. એ બે સંક્રમણો પ્રથમ કનેક્શન ક્યારેય ન બતાવે તેવી મોટાભાગની પુનઃકનેક્શન નિષ્ફળતાઓ સામે લાવે છે.
પેકેજને સંસ્કરણ આપો અને રોલબેક માર્ગ રાખો
દરેક પ્લેટફોર્મ પેકેજને તે જે કરાર-સુધારો અમલમાં મૂકે છે તેની સાથે ટૅગ કરો, અને જે ક્લાયન્ટ અને ગેટવે સંસ્કરણો સામે તમે તેને સ્વીકાર્યું તે નોંધો. ક્લાયન્ટ અપડેટ પછી વર્તન બદલાય ત્યારે ટૅગ અનુમાન કરવાની ફાઇલને બદલે ફરી પરીક્ષણ કરવાના કરાર તરફ ઇશારો કરે છે.
દરેક પ્લેટફોર્મનું અગાઉનું પેકેજ પુનઃપ્રાપ્ત કરી શકાય તેમ રાખો, અને તેની બાજુમાં દૂર કરવાનો આદેશ લખો. VPN પ્રોફાઇલ અનઇન્સ્ટોલ કરવું એ Windows, macOS કે Linux પર ઇન્સ્ટોલ કરવાની પ્રતિબિંબ છબી નથી, અને તફાવતો સૌથી ખરાબ સમયે દેખાય છે. વધારાના ઉપકરણ પર એક વાર દૂર કરવાની તાલીમ લો જેથી આર્કાઇવ આશાને બદલે યોજના બને.