એક IKEv2 લોગિનમાં બે ઓળખ: પહેલા મશીન, પછી વપરાશકર્તા

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

લક્ષણ: સફળ પ્રથમ પુરાવા પછી નિષ્ફળતા

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

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

એક્સટેન્શન શું ઉમેરે છે અને શું નહીં

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

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

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

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

એ જ ફાઇલ ગેટવે પર અલગ રીતે વંચાય છે

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

વિભાગનું સ્થાન તેનો ક્રમ નક્કી કરે છે, સિવાય કે રાઉન્ડ નંબર તેને ઓળંગે. તેથી વધારાના local અથવા remote વિભાગો વિકલ્પોને બદલે વધારાના રાઉન્ડ વર્ણવે છે, અને swanctl.conf સંદર્ભ માંનો સ્પષ્ટ રાઉન્ડ નંબર બરાબર એ ક્રમને જાણી જોઈને બનાવવા માટે છે. એના વિના બ્લોક ખસેડવાથી વર્તન બદલાય છે. તેથી જ કાગળ પર સમાન દેખાતી બે ગોઠવણીઓ વિરુદ્ધ ક્રમમાં વર્તી શકે છે.

એ ક્રમ-નિયમ યાદ રાખવા લાયક નિષ્ફળતાની રીત ઉત્પન્ન કરે છે. બીજો remote બ્લોક બીજો સ્વીકાર્ય વિકલ્પ નથી, તે બીજી માંગ છે, તેથી જ કાં તો/અથવા જેવી વંચાતી નીતિ અને-પછી જેવી વર્તે છે. ગેટવે નીતિ નોંધાયેલા મશીનનું પ્રમાણપત્ર સ્વીકારી શકે છે અને પછી એ વપરાશકર્તાનો EAP વિનિમય એ જ ક્રમમાં માંગી શકે છે.

રાઉન્ડને સ્વતંત્ર પરિબળોથી અલગ પાડો

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

મશીન પ્રમાણપત્ર તેની સ્વીકૃત કીના કબજાને સાબિત કરે છે, વધુ કંઈ નહીં. તે હાર્ડવેર એટેસ્ટેશન નથી કે ઉપકરણ-આરોગ્ય અહેવાલ નથી, તેથી સ્થિતિની માહિતી જોઈતી નીતિને બીજી પદ્ધતિ જોઈએ. subject ક્ષેત્ર પણ વિશ્વસનીય ઇન્વેન્ટરી ટેગ નથી, કારણ કે subject એ પસંદ કરે છે જેણે પ્રમાણપત્ર બહાર પાડ્યું કે નોંધ્યું છે. જો ડિઝાઇનને મશીન સ્વસ્થ છે તેવો પુરાવો જોઈએ, તો એ પુરાવો મશીનને માપતા ઘટકમાંથી આવવો જોઈએ.

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

જોડાણ-નિયમ લખો અને નકાર ચકાસો

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

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

swanctl --list-conns
swanctl --list-sas

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