ipsec.conf કે swanctl.conf? strongSwan નું એક ફ્રન્ટએન્ડ પસંદ કરો

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

બે ફાઇલો, બે લોડર, એક ડેમન

જૂની starter ગોઠવણ ipsec.conf વાંચે છે અને તેના જૂના સંચાલન એકીકરણ દ્વારા જોડાણો charon ને સોંપે છે. તેનું કાર્યકારી પ્રવેશબિંદુ ipsec આદેશ છે.

swanctl ગોઠવણ VICI દ્વારા વ્યાખ્યાઓ લોડ કરે છે, swanctl.conf વાંચે છે અને swanctl આદેશ દ્વારા ચાલે છે. systemd નું મૂળ charon ડેમન આ અભિગમ સાથે જોડાય છે.

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

સ્થાપિત પેકેજો અને unit વાંચો

ફક્ત-વાંચન સ્થિતિમાં શરૂ કરો. Ubuntu 24.04 પર પેકેજના નામ અલગ છે: strongswan-starter, strongswan-swanctl અને charon-systemd. ગેરહાજર પેકેજ ઉપયોગી માહિતી છે, તેને સ્થાપિત કરવાની સૂચના નથી.

એક જ પાસમાં પેકેજો અને unit ની યાદી બનાવો:

dpkg-query -W strongswan-starter strongswan-swanctl charon-systemd
systemctl list-unit-files '*strongswan*'

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

જો સક્રિય unit strongswan-starter હોય, તો મહત્વની ફાઇલ ipsec.conf છે. જો તે swanctl સાથે charon-systemd હોય, તો ipsec.conf ફક્ત શોભા છે.

મેળ ખાતો નિયંત્રણ માર્ગ વાપરો

દરેક ફ્રન્ટએન્ડનું જોડાણો અને સંગઠનો વિશે પોતાનું દૃશ્ય છે. swanctl --list-conns લોડ કરેલ વ્યાખ્યાઓ બતાવે છે અને swanctl --list-sas સક્રિય સંગઠનો બતાવે છે. જૂનો માર્ગ ipsec statusall વાપરે છે.

બંનેને મિશ્ર કરવાથી ભ્રામક ભૂલો થાય છે. ગેરહાજર VICI સોકેટ કે નકારેલ નિયંત્રણ વિનંતી સંચાલન-માર્ગની સમસ્યા છે, એ પુરાવો નહીં કે સામેના પક્ષે પ્રમાણીકરણ નકાર્યું.

ચાલુ ડેમનનું દૃશ્ય વાંચો, પછી પરિણામનું અર્થઘટન કરો. જો તે દૃશ્યમાં જોડાણ ન હોય, તો સમસ્યા લોડિંગમાં છે, વાટાઘાટમાં નહીં.

ફોર્મેટ એ IKE આવૃત્તિ નથી

જૂની પ્રોફાઇલ keyexchange=ikev1 દ્વારા IKEv1 પસંદ કરે છે. swanctl જોડાણ આવૃત્તિ સેટિંગ વાપરે છે, જ્યાં 1 IKEv1 પસંદ કરે છે. આ એક જ વિચારના બે શબ્દભંડોળ છે, રૂપાંતરણ નહીં.

સામેના પક્ષના સરનામાં, સ્થાનિક અને દૂરની ઓળખ, ઓળખપત્રના સ્રોત, પ્રસ્તાવો અને child સિલેક્ટર—દરેકને જાણી જોઈને મેપ કરવા પડે. left/right બ્લોક swanctl સિન્ટેક્સમાં પેસ્ટ કરવાથી એમાંથી કંઈ થતું નથી.

ફક્ત પ્રોટોકોલ આવૃત્તિ બદલવી એ સૌથી સામાન્ય અડધી સ્થળાંતર છે. એવી ફાઇલ બને છે જે લોડ થાય છે અને પછી આવૃત્તિ સાથે સંબંધ ન હોય એવા કારણોસર પ્રમાણીકરણમાં નિષ્ફળ જાય છે. IKEv1 પોતે RFC 9395 દ્વારા બાહ્ય થયું છે, તેથી જે હાલનો સામેનો પક્ષ હજી પણ તેની માંગ કરે છે તેને દસ્તાવેજી સુસંગતતા-મર્યાદા અને સ્થળાંતર માર્ગ યોગ્ય છે, નવું ડિફોલ્ટ નહીં.

પ્રોફાઇલને અડકતાં પહેલાં લોડર તપાસો

પહેલાં લોડર તપાસ ચલાવો, પછી ઇચ્છિત જોડાણ લોડ કરો, પછી વાટાઘાટનું મૂલ્યાંકન કરો અને અંતે સુરક્ષિત ટ્રાફિકનો માર્ગ. દરેક તબક્કાની નિષ્ફળતાની સહી અલગ છે.

બે નિયંત્રણ માર્ગો લોડિંગના પ્રશ્નનો સીધો જવાબ આપે છે:

swanctl --list-conns
ipsec statusall

આમાંથી ફક્ત એક આદેશ તમારા હોસ્ટનો છે. બંને ચલાવીને આઉટપુટ સરખાવવો એ શોધવાનો રસ્તો છે કે કયો તમને ખોટું કહે છે, નિદાન પદ્ધતિ નહીં.

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