strongSwan EAP: IKE ઓળખ વિરુદ્ધ અપેક્ષિત AAA નામ

strongSwan EAP ક્લાયન્ટ બે સર્વર નામ ચકાસી શકે છે. remote.id IKE ગેટવેને આવરે છે અને local.aaa_id EAP સર્વરને આવરે છે; તે એક જ ક્ષેત્ર નથી.

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

એક જોડાણ, બે સર્વર ઓળખ

પ્રથમ ઓળખ IKE વિનિમયની છે. ક્લાયન્ટ સરનામું ડાયલ કરે છે અને અપેક્ષા રાખે છે કે સામેનો પક્ષ ચોક્કસ ઓળખ સાબિત કરશે, સામાન્ય રીતે ગેટવે પ્રમાણપત્રનું નામ.

બીજી EAPની છે. PEAP અથવા TTLS સાથે ક્લાયન્ટ IKE SAની અંદર પ્રમાણીકરણ સર્વર સુધી TLS ટનલ બનાવે છે, અને તે આંતરિક સર્વર પોતાનું પ્રમાણપત્ર રજૂ કરે છે. જ્યારે બેકએન્ડ અલગ હોસ્ટ હોય, ત્યારે તેનું નામ ગેટવેના નામથી અલગ હોય છે. જે ક્લાયન્ટ ફક્ત પ્રથમ નામ તપાસે છે તે બીજું જે દાવો કરે તે સ્વીકારે છે. અને બંને જગ્યાએ એક જ નામ સાથે ગોઠવાયેલ ક્લાયન્ટ, જેવા બંને ખરેખર અલગ પડે ત્યાં જ નિષ્ફળ જાય છે.

બંને નામ ઓપરેટરના રૂપરેખાંકનમાંથી આવે છે, જે પ્રમાણપત્ર ભૂલ દૂર કરે છે તેનાથી નહીં. ઓપરેટરને જમાવટની વિગતો પૂછવી બે હોસ્ટનામ અનુમાન કરવા કરતાં ઝડપી છે.

કયું ક્ષેત્ર કયા સ્તરનું છે

swanctl માં સરનામું અને IKE ઓળખ અલગ સેટિંગ્સ છે, અને EAP ઓળખ ત્રીજી છે.

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

connections {
    office {
        remote_addrs = vpn.example.com
        local {
            auth = eap-peap
            aaa_id = auth.example.com
        }
        remote {
            auth = pubkey
            id = vpn.example.com
        }
    }
}

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

aaa_id local નીચે કેમ રહે છે

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

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

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

એવા ફ્રન્ટએન્ડ જે વિભાજન વ્યક્ત કરી શકતા નથી

NetworkManager પ્રોફાઇલ swanctl જેવું એ જ રૂપરેખાંકન ઇન્ટરફેસ નથી. તેની પાછળનું પ્લગઇન ઓળખ નિયંત્રણોનો સાંકડો સમૂહ આપે છે, અને કયા અસ્તિત્વમાં છે તે સ્થાપિત આવૃત્તિ પર આધાર રાખે છે.

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

વિકલ્પ ક્લાયન્ટ પર શોધવાની વસ્તુ નથી. ટેકાવાળી ગોઠવણ લેખિતમાં માંગો, પછી તે જવાબ પ્રોફાઇલ સાથે રાખો.

ઓળખની અસંગતિને સમાપ્ત પ્રમાણપત્રથી અલગ પાડો

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

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 50 --no-pager

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

સંબંધિત લેખો