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

send_cert ખરેખર શું નિયંત્રિત કરે છે

પ્રમાણપત્ર દ્વારા પ્રમાણીકરણ માટે જરૂરી છે કે peer નું અંતિમ-એકમ પ્રમાણપત્ર IKE આદાનપ્રદાન અથવા પૂર્વ તૈયારી દ્વારા બીજી બાજુ પહોંચે. swanctl માં કનેક્શન સેટિંગ send_cert નક્કી કરે છે કે આ અંતિમ બિંદુ તેનું પ્રમાણપત્ર પેલોડ સમાવે છે કે નહીં: ક્યારેય નહીં, હંમેશા અથવા ifasked. ડિફોલ્ટ ifasked તેને peer તરફથી આવેલી પ્રમાણપત્ર વિનંતીના જવાબમાં મોકલે છે. પ્રમાણપત્ર માંગવું અલગ સેટિંગ છે, કારણ કે બીજી બાજુ પાસેથી તેનું પ્રમાણપત્ર માંગવું પોતાનું રજૂ કરવા જેટલું નથી.

જૂની ipsec.conf જમાવટ leftsendcert અને rightsendcert વાપરતી, અને આ નામો સ્થાનિક અને દૂરસ્થ ભૂમિકાઓ સાથે મેળ ખાય છે, સીધા swanctl સાથે નહીં.

કનેક્શન બદલતા પહેલાં એક પ્રયાસ વાંચો

એક નિયંત્રિત પ્રયાસ પરથી નિદાન કરો, પ્રમાણપત્રો સંકળાયેલા છે એવી સામાન્ય ધારણા પરથી નહીં. નીતિ અને સક્રિય સંલગ્નતા બંને તપાસી શકાય છે.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan --since "10 min ago" | grep -iE "cert|CERT"

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

પ્રાપ્તકર્તાનો વિશ્વાસ અલગ નિર્ણય છે

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

openssl x509 -in peer-chain.pem -noout -subject -issuer -dates

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

પુરાવા સાથે જ મોકલનાર બદલો

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

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

સંબંધિત લેખો