Android ઘરના IPsec VPN સાથે કેમ જોડાય છે અને Windows કેમ નહીં

ફોન કોઈ ફરિયાદ વગર રાઉટરના VPN માં જોડાઈ જાય છે, જ્યારે એ જ Wi-Fi પરનું લેપટોપ જોડાઈ શકતું નથી. એ જ લોગિન માહિતી, એ જ સર્વર, એ જ મિનિટ. ફરક પ્રોટોકોલ સપોર્ટનો છે, પાસવર્ડનો નથી: રાઉટર એવી પ્રોફાઇલ બતાવે છે જે એક ઓપરેટિંગ સિસ્ટમ લાગુ કરે છે અને બીજીએ ક્યારેય ધરી નથી.

પહેલા પ્રોફાઇલ ઓળખો, પછી દરેક ક્લાયન્ટ ખરેખર શું બોલે છે તેની સાથે તુલના કરો.

એક મેનૂ, ત્રણ પ્રોટોકોલ

એક જ IPsec શીર્ષક હેઠળ ગ્રાહક ફર્મવેર ત્રણ તદ્દન જુદા ટનલ છુપાવી શકે છે. પહેલું IKEv1 XAUTH સાથે છે: એક વહેંચાયેલ જૂથ રહસ્ય અને તેની ઉપર વપરાશકર્તાનામ અને પાસવર્ડ. બીજું L2TP/IPsec છે, જ્યાં PPP વહેંચાયેલ કી દ્વારા સુરક્ષિત IPsec પરિવહનની અંદર ચાલે છે. ત્રીજું IKEv2 છે, પ્રમાણપત્રો કે EAP થી પ્રમાણિત.

ફીલ્ડ વાંચો, લેબલ નહીં. જૂથ રહસ્ય અને વપરાશકર્તા યાદી એટલે IKEv1 XAUTH. પહેલેથી વહેંચાયેલ કી અને PPP ખાતું એટલે L2TP/IPsec. જૂથ રહસ્ય વગરનું સર્વર પ્રમાણપત્ર એટલે IKEv2.

ફોન અને લેપટોપ વચ્ચેની સપોર્ટ ખાલી જગ્યા

Android માં IKEv1 XAUTH PSK ક્લાયન્ટ બિલ્ટ-ઇન છે, અને તેથી જ જે રાઉટર બીજું કંઈ આપતું નથી તેની સામે ફોન સફળ થાય છે. Windows માં નથી: તેનું મૂળ ક્લાયન્ટ L2TP/IPsec અને IKEv2 સંભાળે છે, અને ચાલુ કરવા માટે કોઈ IKEv1 XAUTH વિકલ્પ નથી. રહસ્ય ફરી દાખલ કરવાથી મદદ નથી, કારણ કે ખૂટતો ભાગ પ્રોટોકોલ છે, લોગિન માહિતી નહીં.

Apple ની બાજુ ચાલતું લક્ષ્ય છે. નવા macOS અને iOS સંસ્કરણો IKEv2 તરફ વળે છે, જૂની Cisco શૈલીની પ્રોફાઇલ કેટલાક બિલ્ડમાં ટકે છે, અને અપગ્રેડ ગયા મહિને ચાલતું હતું તે દૂર કરી શકે છે અથવા કડક કરી શકે છે. જે Mac ગઈકાલે જોડાતું હતું અને આજે નથી, રાઉટર બદલ્યા વગર, સામાન્ય રીતે આ જ છે.

બે સેટિંગ જે બાકી રીતે સાચી પ્રોફાઇલ તોડે છે

Synology નું L2TP/IPsec પૃષ્ઠ Enable SHA2-256 compatible mode (96 bit) નામનું ચેકબોક્સ આપે છે. iOS 14 અને macOS Big Sur થી Apple ના ક્લાયન્ટ તે કપાયેલ મોડ નકારે છે, તેથી તેમના માટે ચેકબોક્સ બંધ હોવું જોઈએ. ચાલુ રહે તો ટનલ પ્રમાણિત થઈને પછી પડી જાય છે, જે ખરાબ લોગિન માહિતી જેવું લાગે છે અને એવું નથી. ઉત્પાદક સ્વિચનું દસ્તાવેજીકરણ કરે છે, અને ઓપરેટિંગ સિસ્ટમ અપગ્રેડ સામાન્ય રીતે એ ક્ષણ છે જ્યારે આ મહત્વનું બને છે.

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

જ્યારે રાઉટર જેમ છે તેમ રહે

ફક્ત XAUTH PSK બોલતું રાઉટર ત્રણ રસ્તા છોડે છે: ઉત્પાદકનું ક્લાયન્ટ, ત્રીજા પક્ષનું ક્લાયન્ટ જે હજી પ્રોફાઇલ લાગુ કરે છે, અથવા ટનલનો અંતિમ બિંદુ IKEv2 બોલતી વસ્તુ તરફ ખસેડવો. ઉદાહરણ તરીકે AVM પોતાના રાઉટર માટે Windows ક્લાયન્ટ સોફ્ટવેર અને નિકાસ કરેલ કન્ફિગરેશન ફાઇલ પ્રકાશિત કરે છે. એ રસ્તો સમર્થિત છે, અને તેનો અર્થ દરેક લેપટોપ પર ઉત્પાદકનું સાધન સ્થાપિત કરવું.

જ્યારે લેપટોપ તમારા નથી ફરી બનાવવા માટે, ત્યારે સપોર્ટ સૌંદર્ય કરતાં વધુ મહત્વનો છે.

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

બહારથી અંદર નિદાન કરો

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

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