Android IKEv2 વિશ્વાસ ભૂલ: મૂળ નહીં, મધ્યવર્તી CA મોકલો
ફોન ગેટવેને નકારે છે કારણ કે મળેલી ચેઇન વહેલી અટકે છે. નક્કી કરો: મધ્યવર્તી મોકલો, ઓળખ સુધારો અથવા કી પ્રકાર બદલો.
ફોન જોડાવાની ના પાડે છે અને No trusted RSA public key found for vpn.example.net છાપે છે, જ્યારે એ જ ગેટવે પ્રમાણપત્ર એ જ નેટવર્ક પર લેપટોપથી કામ કરે છે. પ્રમાણપત્ર ફરીથી જારી કરવું લોભામણું પગલું છે. તે પહેલાં ત્રણમાંથી કઈ ભૂલ છે તે નક્કી કરો, કારણ કે તેમાંથી ફક્ત એક જ પ્રમાણપત્રની સામગ્રી વિશે છે.
એક સંદેશ પાછળ ત્રણ ભૂલો
Android ગેટવે પ્રમાણપત્રથી VPN પ્રોફાઇલમાં પસંદ કરેલા CA સુધી ચેઇન બનાવે છે અને પછી સર્વરનું નામ પ્રોફાઇલ સાથે સરખાવે છે. સૂચના પરિણામ જણાવે છે, તબક્કો નહીં. વિશ્વાસ ભૂલ એટલે વિનિમયમાં આપેલા પ્રમાણપત્રોથી ચેઇન પૂર્ણ ન થઈ શકી; ઓળખ ભૂલ એટલે ચેઇન માન્ય છે પણ નામ મળતું નથી; અલ્ગોરિધમ ભૂલ એટલે ઉપકરણ કે પ્રોફાઇલ કી પ્રકાર કે સહી સ્વીકારતું નથી.
| What you see | What it points to | First move |
|---|---|---|
| Chain stops after the leaf in the daemon log | intermediate not loaded or not sent | load the intermediate as CA material |
| Chain validates, name differs from the profile | identity mismatch | fix the profile name or the certificate SAN |
| Chain validates, handshake still fails | key or signature not accepted | compare key type against the device |
ક્રમમાં સુધારા અજમાવવાને બદલે પુરાવા સાથે નક્કી કરો. ડિમન પર લોગ સ્તર 2 પર એક પ્રયાસ તમે કઈ હરોળમાં છો તે કહે છે, અને કદી ખોટું ન હોય તેવું પ્રમાણપત્ર ફરીથી જારી કરવા કરતાં ઓછો ખર્ચ છે.
પહેલાં નક્કી કરો: આખી ચેઇન આવી?
strongSwan તે જોડાણ માટે ગોઠવેલું પ્રમાણપત્ર મોકલે છે, અને મધ્યવર્તી પ્રમાણપત્રો અલગ ઓળખપત્રો છે. ડિમન તેમને પેલોડમાં મૂકે તે પહેલાં CA પ્રમાણપત્ર તરીકે લોડ કરવા પડે, તેથી જ્યાં સર્વર પ્રમાણપત્ર મધ્યવર્તીથી સહી કરેલું છે, મૂળ વિશ્વાસનું લંગર છે અને મધ્યવર્તી ફક્ત CA ના બિલ્ડ ફોલ્ડરમાં રહે છે તેવી ગોઠવણી બરાબર આ જ ભૂલ આપે છે: તાર પર ફક્ત પાનું અને ફોન પર ચેઇન વહેલી પૂરી થાય છે.
swanctl ડિપ્લોયમેન્ટ પર swanctl --list-certs થી, અથવા જૂના સ્ટાર્ટર સાથે ipsec listcerts થી ડિમન પાસે શું છે તે તપાસો. મધ્યવર્તી મૂળની ઉપર CA પ્રમાણપત્ર તરીકે દેખાવું જોઈએ. ન હોય તો કોઈ ક્લાયન્ટ વિકલ્પ મદદ નહીં કરે; હોય તો આગળના પ્રશ્ન પર જાઓ.
પછી તપાસો કે તે મોકલાશે કે નહીં. swanctl.conf સંદર્ભ send_cert નું વર્ણન કરે છે, જેનું મૂળભૂત ifasked ફક્ત ત્યારે પ્રમાણપત્રો મોકલે છે જ્યારે સાથીએ માંગ્યું હોય; always હંમેશા મોકલે છે. જૂનું સમકક્ષ ipsec.conf માં leftsendcert=always છે. આ સેટિંગ મોકલવાનું નિયંત્રણ કરે છે, ઉપલબ્ધતાનું નહીં, તેથી ડિમને કદી લોડ ન કરેલા મધ્યવર્તીની ભરપાઈ કરી શકતું નથી.
ચેઇન ટૂંકી હોય તો ડિમન જ્યાં શોધે ત્યાં મધ્યવર્તી લોડ કરો
મધ્યવર્તીને પાનાની બાજુમાં નહીં, CA ફોલ્ડરમાં મૂકો: ipsec.conf વાળી ગોઠવણી માટે /etc/ipsec.d/cacerts, swanctl માટે /etc/swanctl/x509ca, અથવા તમારું પેકેજ જે પથ બદલે છે. રૂપરેખા ફરી લોડ કરો અને પ્રમાણપત્રો ફરી સૂચિબદ્ધ કરો. કેટલાક સંસ્કરણો પાના ફાઇલમાં ચેઇન ધરાવતું બંડલ પણ મોકલે છે, પણ CA ફોલ્ડર સંસ્કરણો અને પેકેજો વચ્ચેની સુવાહ્ય ગોઠવણી છે.
ક્લાયન્ટ બાજુથી પણ ચકાસો. ફોન ફક્ત વિનિમય લાવ્યું તે જ જુએ છે, તેથી સ્તર 2 ના ડિમન લોગમાં મોકલેલા પ્રમાણપત્રોમાં મધ્યવર્તી દેખાવું જોઈએ. લોગ દેખાડે અને ફોન હજી નિષ્ફળ જાય તો તમે કોષ્ટકની બીજી હરોળમાં છો, અને CA ફાઇલો બદલવાથી પરિણામ નહીં બદલાય.
ચેઇન પૂર્ણ હોય તો પ્રમાણપત્રો સંપાદિત કરવાનું બંધ કરો
ઓળખ ભૂલ એ VPN પ્રોફાઇલના નામ અને પ્રમાણપત્રના નામ વચ્ચેનો મેળ ન હોવો છે. Android તમે ગોઠવેલી સર્વર ઓળખને તેની પ્રમાણિત કરેલી પ્રમાણપત્ર સાથે સરખાવે છે, તેથી પ્રોફાઇલ સરનામું બતાવે અને પ્રમાણપત્ર યજમાનનામ કહે, અથવા પ્રોફાઇલ એવું યજમાનનામ કહે જે પ્રમાણપત્ર આવરી લેતું નથી, તો સફળ ચેઇન ચકાસણી પછી પણ નિષ્ફળ જાય છે. ખોટી બાજુ સુધારો અને પ્રોફાઇલ તથા પ્રમાણપત્ર સુસંગત રાખો.
અલ્ગોરિધમ ભૂલ માન્ય ચેઇન અને મળતા નામ સાથે દેખાય છે. Android આવૃત્તિઓ કઈ કી પ્રકારો અને સહી યોજનાઓ સ્વીકારે તેમાં ભિન્ન છે, અને પ્રોફાઇલનો પ્રકાર પોતે વિકલ્પો મર્યાદિત કરે છે. ગેટવે જૂનું કે અસામાન્ય સંયોજન વાપરે તો પ્રમાણપત્ર બગડેલું માનવા પહેલાં ઉપકરણ શું ટેકો આપે તેની સાથે સરખાવો. લોગ દેખાડશે કે હેન્ડશેક વિશ્વાસ કિસ્સા કરતાં આગળ વધે છે, જે સંકેત છે કે ચેઇન હવે સમસ્યા નથી.
ફોન પર મધ્યવર્તીને વપરાશકર્તા મૂળ તરીકે સ્થાપિત ન કરો
ગુમ થયેલા મધ્યવર્તીને ફોન પર વપરાશકર્તા પ્રમાણપત્ર તરીકે સ્થાપિત કરવાથી ચેતવણી અદૃશ્ય થાય છે અને વપરાશકર્તા-સ્થાપિત મૂળ સ્વીકારતી દરેક એપ માટે ફોનનું વિશ્વાસ મોડેલ બદલાય છે. તે આગળના ક્લાયન્ટને અસર કરનારી વિતરણ ક્ષતિ પણ છુપાવે છે અને ગેટવેને દરેક ભાવિ ઉપકરણને અપૂર્ણ ચેઇન મોકલતું રાખે છે. ટકાઉ સુધારો સર્વર પર છે, એક વાર, બધા ક્લાયન્ટ માટે.
ફેરફાર રેકોર્ડમાં ત્રણ નિર્ણયો અલગ રાખો: કયા પ્રમાણપત્રો મોકલાયા, કઈ ઓળખ સરખાવાઈ અને કયો અલ્ગોરિધમ વાટાઘાટ થયો. હંમેશા પૂરી ચેઇન મોકલતું ગેટવે, પ્રમાણપત્રને યોગ્ય નામ આપતી પ્રોફાઇલ અને ફ્લીટ ટેકો આપતો કી પ્રકાર — ત્રણ નાની હકીકતો, અને આખી આ ભૂલ એ જ છે.