સ્થિર OpenVPN સરનામાંઓએ ઓળખને અનુસરવું જોઈએ, સ્રોત IPને નહીં

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

સર્વર શું ચકાસી શકે તેનાથી શરૂ કરો, પછી સરનામું શેના માટે છે તે નક્કી કરો.

સરનામા પહેલાં ઓળખ કી પસંદ કરો

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

duplicate-cn સાથે, ઘણા એકસાથે સત્રો સમાન સામાન્ય નામ રજૂ કરી શકે છે, તેથી એક પિન કરેલું સરનામું તેમને અલગથી ઓળખી શકતું નથી. આ ઓળખ મોડેલની ગુણધર્મ છે, વધુ સારી સરનામાં યોજના સુધારી શકે તેવી વસ્તુ નથી.

ગતિશીલ શ્રેણીની બહાર સરનામાં આરક્ષિત કરો

10.90.0.0/24 જેવા સબનેટ-ટોપોલોજી નેટવર્કમાં, નામવાળા સભ્યો માટે નીચાં સરનામાં રાખો અને ગતિશીલ પૂલને અલગ શ્રેણીમાં મૂકો. પિન કરેલા સભ્ય માટેની સોંપણી આવી દેખાય છે ifconfig-push 10.90.0.10 255.255.255.0, જે ફાઇલ સર્વર તે ઓળખ માટે પસંદ કરે છે. બીજી દલીલ net30 હેઠળ કંઈક અલગ અર્થ ધરાવે છે, તેથી ઉદાહરણ ટોપોલોજી-તટસ્થ નથી. નકલ કરતા પહેલાં ટોપોલોજી વાંચો.

પૂલની સ્થિરતા તાજેતરના લીઝ નોંધે છે અને તે જ સરનામું પાછું આપવાની વૃત્તિ ધરાવે છે, જે સુવિધા છે, આરક્ષણ નહીં. સ્થિરતા ફાઇલને માલિકીનો રેકોર્ડ બનવા દેવું નહીં, કારણ કે તે નીતિ સાથે નહીં, કનેક્શન ઇતિહાસ સાથે બદલાય છે.

સોંપણીની અગ્રતા નક્કી કરે છે કોણ જીતશે

માર્ગદર્શિકા એક ક્રમનું દસ્તાવેજીકરણ કરે છે: client-connect દરમિયાન બનેલી સ્પષ્ટ સોંપણી client-config-dir એન્ટ્રી પહેલાં અમલમાં આવી શકે છે, જે પોતે સામાન્ય પૂલ ફાળવણી પહેલાં આવે છે. તે ક્રમ ‘પિન કરેલું સરનામું લાગુ ન થયું’ એવા મોટાભાગના અહેવાલો સમજાવે છે. તેનો અર્થ એ પણ છે કે દરેક સત્ર માટે રૂપરેખા લખતું ગતિશીલ ફાળવનાર તમે સત્તાવાહક માનેલી સ્થિર ફાઇલને ચૂપચાપ ઓવરરાઇડ કરી શકે છે.

સોંપણીઓનો માલિક એક સ્તરને બનાવો અને બાકીનાને ફક્ત-વાંચન બનાવો. બંને નિર્ણયનો દાવો કરતા બે સ્તર સમય-આધારિત સોંપણીઓ બનાવે છે.

ગતિશીલ ફાળવનારને પણ એ જ મોડેલ જોઈએ

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

ફાળવનારની સ્થિતિ ત્યાં રાખો જ્યાં આગલો સંચાલક તેને વાંચી શકે, અને ફક્ત સરનામું નહીં, ઓળખ-થી-સરનામું નિર્ણય લોગ કરો.

સરનામું નીતિ છે કે સુવિધા તે નક્કી કરો

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

યોજનાને દરેક એન્ટ્રી માટે માલિક સાથેની યાદી તરીકે લખો, પછી ઉપકરણ નિવૃત્ત થાય ત્યારે તેની સમીક્ષા કરો. વણવપરાયેલું આરક્ષણ એ જ છે જે અકસ્માતે ફરી વપરાય છે.