OpenVPN કે IKEv2: પ્રોટોકોલ પસંદ કરતા પહેલા ચાર તપાસ

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

ક્લાયન્ટ ન હોય તો ચર્ચા પૂરી થાય

Windows અને macOS IKEv2 ક્લાયન્ટ સાથે આવે છે, તેથી ત્યાં IKEv2 પ્રોફાઇલ તૈનાત કરવાનો કોઈ વધારાનો ખર્ચ નથી અને ઓપરેટિંગ સિસ્ટમ પહેલેથી જ આપતા પ્રોવિઝનિંગ વિકલ્પો વારસામાં મળે છે. OpenVPN એ જ મશીનો પર તૃતીય-પક્ષનો ક્લાયન્ટ સ્થાપિત, અપડેટ અને સપોર્ટ કરવો પડે એમ કહે છે, અને એ ક્લાયન્ટે પ્રોફાઇલ વાપરતો દરેક વિકલ્પ સ્વીકારવો પડે. બીજું કંઈ પણ સરખાવતા પહેલા જે પ્લેટફોર્મ ઢાંકવા પડે તે ગણો, કારણ કે કામ કરતા ક્લાયન્ટ વિનાનું પ્લેટફોર્મ સરખામણીનું સ્થાન જ નથી.

Windows પર એક આદેશ પહેલેથી હયાત પ્રોફાઇલની સૂચિ આપે છે અને દરેકનો પ્રકાર બતાવે છે. તે જે નામ છાપે છે તે જ નામ પછીની તપાસ વાપરે છે.

Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType

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

ગતિશીલતા સંયુક્ત સેટિંગ છે, પ્રોટોકોલનું વચન નહીં

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

તમને ખરેખર મહત્વનું હોય તે સંક્રમણ ચાલુ કંઈક સાથે કરો જે તમે જોઈ શકો. Windows પર ping -t <internal-host> ચાલુ રાખો, અથવા સાદું ping બીજે, પછી Wi-Fi થી મોબાઇલ પર જાઓ અને ખાલી જગ્યાઓ જુઓ. MOBIKE નિષ્ફળતા ક્લાયન્ટ લોગમાં શાંત સરનામા અપડેટને બદલે સંપૂર્ણ પુનઃપ્રમાણીકરણ તરીકે દેખાય છે. તમે માપો છો કે ટનલ બદલાવ ટકી રહે છે કે નહીં, પ્રોટોકોલ સપોર્ટની જાહેરાત કરે છે કે નહીં તે નહીં.

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

ઓળખપત્રો સ્ટેકના નહીં, સેવાના છે

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

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

openssl x509 -in client.crt -noout -subject -issuer -dates

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

ટનલ ખરેખર શું રૂટ કરે છે તે તપાસો

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

Windows પર બે આદેશ રૂટ અને નામ-શોધને આવરી લે છે. Linux માં સમકક્ષ છે ip route show default અને resolvectl query <internal-host>.

Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>

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

તપાસ પછી જાળવણી તોળો

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

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