સ્થિર VPN IP: RADIUS Framed-IP-Address કે પૂલ રિઝર્વેશન

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

સ્થિર સરનામું રહી શકે તેવી ત્રણ જગ્યાઓ

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

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

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

RADIUS જવાબ શું વચન આપી શકે છે અને શું નહીં

RFC 2865Framed-IP-Address ને વપરાશકર્તા માટે રૂપરેખાંકિત કરવાના IPv4 સરનામા તરીકે વ્યાખ્યાયિત કરે છે, અને તે Access-Accept માં આવે છે. Access-Request માં તે જ લક્ષણ ફક્ત સંકેત છે જેને સર્વર અવગણી શકે છે, અને જ્યારે ક્લાયંટ કે ગેટવે પ્રિફેર્ડ સરનામું આપે ત્યારે આ મહત્વનું છે. પ્રોટોકોલમાં કંઈ પણ ગેટવેને જવાબનું પાલન કરવા મજબૂર કરતું નથી, કારણ કે નેટવર્ક એક્સેસ સર્વર એ ઘટક છે જે તેને સત્ર પર લાગુ કરે છે.

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

ગેટવે જે જવાબ અવગણે છે તે કદી ન મોકલાયેલા જવાબ જેવો જ દેખાય છે. Access-Accept અને સત્રનું સરનામું બાજુમાં બાજુ વાંચવું એ બે કિસ્સાઓ અલગ કરવાનો એકમાત્ર રસ્તો છે.

તમે પહેલેથી રૂટ કરો છો તે પૂલની અંદર સરનામું અનામત રાખો

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

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

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

રિઝર્વેશન પર ભરોસો કરતા પહેલા જવાબ ચકાસો

AAA બાજુ અને સત્ર બાજુ અલગ રીતે ચકાસો, કારણ કે તે અલગ કારણોસર નિષ્ફળ જાય છે. સ્થાનિક radtest ગેટવેને સામેલ કર્યા વગર સર્વર એકાઉન્ટ માટે શું પરત કરે છે તે બતાવે છે, અને વપરાશકર્તા ફાઇલની એન્ટ્રી બતાવે છે કે સર્વરે શું મેળવવું જોઈએ. પછી ક્લાયંટ ફરીથી કનેક્ટ કરો અને મળેલા સરનામાને જવાબમાંના લક્ષણ સાથે તુલના કરો.

Authenticated member: survey-tablet-17
Reply attribute:      Framed-IP-Address = 172.28.4.77

survey-tablet-17  Cleartext-Password := "REPLACE_ME"
                  Framed-IP-Address = 172.28.4.77

radtest survey-tablet-17 REPLACE_ME 127.0.0.1 0 testing123

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

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

એક માલિક પસંદ કરો અને તેને લખો

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

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