RADIUS VPN વપરાશકર્તાનામની જગ્યાએ IP સરનામું કેમ જુએ છે

strongSwan કોઈપણ EAP વિનિમય પહેલાં IKE ઓળખને RADIUS User-Name માં મૂકી શકે છે. ખાતાની ઓળખ કોણ માંગે છે તે નક્કી કરો, પછી એક પ્રયાસને સહસંબંધિત કરો.

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

એક જ જોડાણમાં બે ઓળખ મુસાફરી કરે છે

એક જોડાણમાં બે નામ દેખાઈ શકે છે. IKE ઓળખ ટનલ સેટઅપ દરમિયાન સાથીને ઓળખે છે, અને eap-radius પ્લગઇન શરૂઆતમાં તેને RADIUS User-Name માં નકલ કરે છે. EAP ઓળખ એક અલગ મૂલ્ય છે, જે વપરાશકર્તા પ્રમાણીકરણ માટે વપરાય છે, અને જો કોઈ ન માંગે તો તે કદાચ ક્યારેય મોકલાશે નહીં.

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

ગેટવેને EAP ઓળખ માંગવા કહો

એક સમર્થિત ગોઠવણીમાં ગેટવે પ્રમાણીકરણ RADIUS ને સોંપતા પહેલાં EAP ઓળખ માંગે છે. જોડાણના દૂરસ્થ પ્રમાણીકરણ વિભાગમાં, પદ્ધતિને eap-radius પર સેટ કરો અને EAP ઓળખ સ્પષ્ટપણે માંગો. નીચેનો ટુકડો પોતાની ફાઇલમાં નહીં, હાલના જોડાણ બ્લોકની અંદર આવે છે. બીજા તૈનાતીમાંથી સિન્ટેક્સ નકલ કરતા પહેલાં જોડાણ અને રૂપરેખા બેકએન્ડની ખાતરી કરો.

remote {
    auth = eap-radius
    eap_id = %any
}

તેનાથી બેકએન્ડને IKE સરનામા વત્તે ક્લાયન્ટ EAP વિનિમયમાં જે ઓળખ આપે છે તે મળે છે. જોડાણમાં બીજું કંઈ બદલાતું નથી.

અથવા RADIUS ને EAP વિનિમય શરૂ કરવા દો

બીજી ગોઠવણી પ્રથમ પગલું RADIUS બાજુ પર મૂકે છે. પ્લગઇન પ્રારંભિક ઓળખ પ્રતિસાદની રાહ જોવાને બદલે EAP-Start સંકેત મોકલી શકે છે, જે સર્વરને વિનિમય ચલાવવા દે છે. આ પ્લગઇન-સ્તરની રૂપરેખા છે, તેથી તે પ્લગઇન વાપરતા દરેક જોડાણને અસર કરે છે.

charon {
    plugins {
        eap-radius {
            eap_start = yes
        }
    }
}

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

એક પ્રયાસને બંને લોગમાં અનુસરો

એક જ પ્રયાસને બંને લોગમાં સહસંબંધિત કરો. IKE ઓળખ જુઓ, પછી EAP-Identity વિનિમય થાય છે કે નહીં, અને પછી પ્રમાણીકરણ પગલાને કયું નામ મળે છે. EAP વિનિમય પહેલાં સરનામું નકારતું બેકએન્ડ તમારી ઇચ્છિત ઓળખ કદી દેખાય તે પહેલાં પ્રક્રિયા થોભાવી શકે છે.

journalctl -u strongswan -f

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

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

સંબંધિત લેખો