OpenVPN સર્વર nopool સાથે: સ્પષ્ટ પૂલ શ્રેણી જાહેર કરો

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

આ ચાલુ સેવામાં ફેરફાર છે, તેથી તેને સંચાલન કાર્ય તરીકે ગણો: પહેલાં યાદી, સામાન્ય જીવનચક્ર દ્વારા અમલ, નવા ક્લાયન્ટ સાથે ચકાસણી અને તૈયાર પુનઃપ્રાપ્તિ.

તમારી પાસે પહેલેથી જ હોય તે સબનેટથી શરૂ કરો

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

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

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

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

nopool ઉમેરો અને શ્રેણી જાહેર કરો

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

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

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

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

સ્થિર સોંપણીઓ ગતિશીલ શ્રેણીની બહાર રાખો

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

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

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

જીવનચક્ર દ્વારા લાગુ કરો, પછી ચકાસો

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

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

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

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

શ્રેણી ફેરફાર પાછો ખેંચવો

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

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

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