VPN ગેટવે દ્વારા EAP: પદ્ધતિ કોણ સમાપ્ત કરે છે

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

લોગમાં સરખા દેખાતા બે પ્રમાણીકરણ માર્ગ

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

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

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

પદ્ધતિ ખરેખર ક્યાં ચાલે છે

RFC 3579 પાસ-થ્રુ ગોઠવણી નક્કી કરે છે: NAS RADIUS એટ્રિબ્યુટમાં EAP પેકેટ લઈ જાય છે અને દરેક EAP પ્રકાર માટે પદ્ધતિ-વિશિષ્ટ કોડની જરૂર નથી. તેથી ગેટવે PEAP અને EAP-TLS ને કોઈપણ અમલમાં મૂક્યા વિના સમર્થન આપી શકે છે.

જે ગેટવે પાસવર્ડ સબમિટ કરે છે તે PEAP લઈ જતું નથી, ભલે બેકએન્ડ બીજા ક્લાયન્ટ તરફથી PEAP સ્વીકારે. સર્વર નીતિમાં PEAP સક્ષમ કરવાથી એવા ક્લાયન્ટને પદ્ધતિ ઉમેરાતી નથી જેણે ક્યારેય એક પણ ઓફર કરી નથી.

PPP પ્રમાણીકરણ સેટિંગ્સ PPP સેવાની છે. તે સમાન AAA સર્વર વાપરતા દરેક IPsec અથવા જૂના XAuth માર્ગને શાંતિથી ફરીથી ગોઠવતા નથી, તેથી એક એક્સેસ પ્રકાર માટે કામ કરતો ફેરફાર બીજાને અસ્પૃષ્ટ રાખી શકે છે.

NAS એ શું સમર્થન આપવું જોઈએ

પાસ-થ્રુ જરૂરિયાતને પદ્ધતિ કોડથી વાહક સમર્થન તરફ ખસેડે છે. ગેટવે પોતાના VPN પ્રોટોકોલ પર EAP લઈ જઈ શકવું જોઈએ, અને તેના પરનો RADIUS ક્લાયન્ટ સંબંધિત માપના EAP-Message એટ્રિબ્યુટ મોકલી અને સ્વીકારી શકવો જોઈએ.

IKEv2 માટે EAP નિર્ધારિત પ્રમાણીકરણ પ્રવાહનો ભાગ છે, અને સર્વર ઓળખ તથા વિશ્વાસ તપાસ તે પ્રવાહમાંથી આવે છે. 802.1X જમાવટમાંથી લીધેલું PEAP લેબલ આપમેળે પસાર થતું નથી, કારણ કે તેની આસપાસની વાટાઘાટ અલગ છે.

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

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

ગેટવે અને પ્રમાણીકરણ સર્વર પર એક મંજૂર પ્રયાસ કેપ્ચર કરો. RADIUS વિનંતીમાં EAP-Message એટ્રિબ્યુટ શોધો. તેમની હાજરી કહે છે કે પાસ-થ્રુ માર્ગ વપરાય છે; તેમની ગેરહાજરી ઓળખપત્ર આદાનપ્રદાન તરફ ઇશારો કરે છે.

Linux ગેટવે પર RADIUS પોર્ટ પરનું કેપ્ચર દર્શાવે છે કે તાર પર કયા એટ્રિબ્યુટ છે:

sudo tcpdump -ni any -X 'udp port 1812' -c 20

પછી નકાર બિંદુની તુલના કરો. કોઈપણ RADIUS પેકેટ પહેલાં ગેટવે પર નિષ્ફળતા એટલે ક્લાયન્ટ અને ગેટવે પદ્ધતિ પર સહમત ન હતા. EAP એટ્રિબ્યુટ ધરાવતો RADIUS નકાર એટલે બંને છેડાએ પદ્ધતિ ચલાવી અને તેમાંથી એકે પરિણામ નકાર્યું.

સ્થળાંતરને એક જ શરૂઆતથી-અંત સુધીના ફેરફાર તરીકે યોજો

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

જે સંયોજન કામ કરે તે નોંધો: VPN પ્રોટોકોલ, EAP વાહક, સાથી પદ્ધતિ, સર્વર પદ્ધતિ, ઓળખપત્ર પ્રકાર અને સર્વર ઓળખ તપાસ.

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