આગલા ફરી-કનેક્શન પર પૂલ કયું સરનામું આપશે?
પૂલનાં સરનામાં એવા ક્રમને અનુસરે છે જે અવ્યવસ્થિત નથી: પહેલાં યાદ રાખેલું સરનામું, પછી સૌથી લાંબા સમયથી ન વપરાયેલું ખાલી સરનામું. નિયમ નક્કી કરતાં પહેલાં તે વાંચો.
ગઈકાલે મેળ ખાતો નિયમ આજે મેળ ખાતો નથી, કારણ કે ક્લાયન્ટ બીજા ટનલ સરનામા પર પાછો આવ્યો. વિતરક તો અવ્યવસ્થિત નથી, અને તેનો ક્રમ જાણવો તે આશ્ચર્યને અગાઉથી જાણી શકાય તેવી ઘટના બનાવે છે. તે એ જ ક્લાયન્ટનું પહેલાંનું સરનામું પસંદ કરે છે, સૌથી લાંબા સમયથી નિષ્ક્રિય ખાલી સરનામા પર પાછો જાય છે, અને જો તમે તેને યાદ રાખવાની જગ્યા ન આપો તો બધું ભૂલી જાય છે. ભાડા પર આધારિત નિયમો તે દિવસ સુધી મેળ ખાતા રહે છે જ્યારે તે ચુપચાપ એવું કરવાનું બંધ કરે છે.
વિતરક જે ક્રમ અનુસરે છે
પ્રતિ common name એક સત્ર હોય તો વિતરક પહેલાં તે સરનામું શોધે છે જે એ જ ક્લાયન્ટે પહેલાં વાપર્યું હતું અને જે હવે ખાલી છે. જો તે સરનામું ન હોય તો તે સૌથી લાંબા સમયથી નિષ્ક્રિય રહેલું ખાલી સરનામું લે છે. જ્યારે એ જ નામ માટે એકસાથે સત્રો સક્રિય હોય ત્યારે પહેલાંના સરનામાને પ્રાધાન્ય લાગુ પડતું નથી અને તેના બદલે પહેલું ખાલી સરનામું વપરાય છે, કારણ કે સત્રોને અલગ સમાન નોડ તરીકે ગણવામાં આવે છે.
| Situation | Address chosen | Practical effect |
|---|---|---|
| Reconnect, old address still free | The remembered address | Rules appear stable for days |
| Old address taken by another client | Least recently used free address | A working rule silently stops matching |
| Concurrent sessions, same name | First free address, per session | One identity can hold several leases |
આમાંથી તરત જ બે પરિણામ આવે છે. ઝડપથી ફરી જોડાતો ક્લાયન્ટ સામાન્ય રીતે પોતાનું સરનામું રાખે છે, તેથી કોઈ પણ પદ્ધતિ બદલાય ત્યાં સુધી તેને જોતું નથી. અને તે નાની બારીમાં જોડાતું બીજું ઉપકરણ સરનામું ત્યારે લઈ શકે છે જ્યારે તે થોડા સમય માટે ખાલી હોય, પછી પહેલા ક્લાયન્ટને બીજું કંઈક મળે છે અને જૂના નંબર પર આધારિત દરેક નિયમ ખોટો થાય છે. બંનેમાંથી કોઈ પણ ઘટના ખામી જેવી લાગે તેવી લોગ લાઇન બનાવતી નથી.
ભાડું સ્થિર કેમ દેખાય છે અને પછી ખસે છે
અહીં સ્થિરતા ફરી-જોડાણોની ઉદભવતી ગુણવત્તા છે જે બીજા કોઈ સરનામું માંગે તે પહેલાં આવે છે. આ વચન નથી, અને ક્લાયન્ટ ડિસ્કનેક્ટ હોય ત્યાં સુધી તે લાગુ પડતું નથી. સરનામું બદલાશે તેવી યોજના કરો, તેનાથી આશ્ચર્ય પામવાને બદલે. ઉપકરણોની સંખ્યા કરતાં ભાગ્યે જ મોટો પૂલ ટકરાવને રોજિંદા બનાવે છે, કારણ કે સૌથી લાંબા સમયથી ન વપરાયેલા સરનામા પર પાછા જવા પાસે પસંદ કરવા માટે લગભગ કંઈ જ હોતું નથી.
શિખર સમવર્તિતા એ સંખ્યા છે જેના પર માપ નક્કી કરવું જોઈએ, વપરાશકર્તાઓની સંખ્યા નહીં. કોઈ જે એકસાથે બે ઉપકરણોમાંથી પરીક્ષણ કરે છે, અથવા ક્લાયન્ટ જે જૂનું સત્ર પૂરું થાય તે પહેલાં ફરી જોડાય છે, થોડા સમય માટે બે ભાડાં રાખે છે. ફક્ત વ્યક્તિઓની સંખ્યા પર આધારિત પૂલ બરાબર એ જ અદલાબદલી પેદા કરશે જેનો દોષ લોકો સર્વર પર નાખે છે.
સ્થાયિત્વ ફાઇલ યાદ રાખે છે, અનામત રાખતી નથી
જે સરનામું સેવાના પુનઃપ્રારંભમાંથી ટકી રહે તેને સ્થાયિત્વ ફાઇલની જરૂર છે. તે બંધ કરતી વખતે ક્લાયન્ટનું નામ અને સરનામું સંગ્રહે છે અને સેવા શરૂ થાય ત્યારે તેને ફરી વાંચે છે, તેથી નિયોજિત પુનઃપ્રારંભ હવે તમે લખેલા બધા નિયમોને ઢવળતો નથી.
ifconfig-pool-persist /etc/openvpn/ipp.txt
server 10.8.0.0 255.255.255.0તે જે કરતી નથી તે એ છે કે ક્લાયન્ટ ગેરહાજર હોય ત્યારે સરનામું રોકી રાખતી નથી. તે અંતરાલમાં વિતરક નંબર બીજા કોઈને આપવા માટે મુક્ત છે, અને ફાઇલ પછી એવી જૂની પ્રાથમિકતા નોંધે છે જે આગળનું જોડાણ પૂરી કરી શકતું નથી. તેને પુનઃપ્રારંભના વર્તનને સુધારતા સંકેત તરીકે લો, સ્થિર સરનામાંકન તરીકે નહીં.
તમે ફાઇલમાં હો ત્યારે પૂલને દરેક રૂટ કરેલા સબનેટ સામે તપાસો. એકબીજા પર ચઢતી શ્રેણી એવાં સરનામાં વહેંચે છે જ્યાં સર્વર રૂટ કરી શકતું નથી, અને લક્ષણ એ છે કે ક્લાયન્ટ જોડાય છે, સરનામું મેળવે છે અને ક્યાંય પહોંચતો નથી.
સરનામું યોગ્ય રીતે સ્થિર કરવું
જ્યારે ફાયરવોલ નિયમ કે DNS રેકોર્ડને ખરેખર સ્થિર સરનામું જોઈએ ત્યારે આશા રાખવાને બદલે તે ફાળવો. પ્રતિ ક્લાયન્ટ રૂપરેખાંકન પ્રવેશ સીધું સરનામું અને માસ્ક મોકલી શકે છે, અને તે પ્રવેશ અસરકારક ક્લાયન્ટ નામ પર કી કરેલો છે.
# client-config-dir entry for "laptop-acme"
ifconfig-push 10.8.0.50 255.255.255.0સ્થિર સરનામાં ગતિશીલ પૂલની બહાર રાખો જેથી વિતરક કદી એ જ નંબર બીજા સત્રને ન આપે. પછી ટનલની રચના તપાસો, કારણ કે તે બદલે છે કે દરેક ક્લાયન્ટ કેટલાં પૂલ સરનામાં વાપરે છે: જૂનું બિંદુ-થી-બિંદુ લેઆઉટ પ્રતિ ક્લાયન્ટ એક નાનો બ્લોક વાપરે છે, જ્યારે સબનેટ લેઆઉટ દરેક પર એક સરનામું વાપરે છે. જે પૂલ એક રચનામાં ઉદાર દેખાય છે તે બીજીમાં ખતમ થઈ શકે છે.
પરિણામ ક્લાયન્ટ પર ખાતરી કરો, સર્વરના હિસાબ પર ભરોસો રાખવાને બદલે. જ્યારે સત્ર પાછું આવે ત્યારે ઇન્ટરફેસનું સરનામું અને મોકલેલો રૂટ જુઓ, કારણ કે સર્વરનો લોગ માંગેલું સરનામું જણાવી શકે છે જ્યારે ઇન્ટરફેસ પોતે બીજું રાખે છે.
દૂરનું સરનામું અલગ પ્રશ્ન છે
ક્લાયન્ટની remote લાઇનમાંનું સરનામું કોઈ પણ ટનલ હોવા પહેલાં પહોંચી શકાય તેવું હોવું જોઈએ. ત્યાં પૂલનું સરનામું મૂકવું, જેમ કે સર્વરનું પોતાનું ટનલ અંતિમ બિંદુ, એટલે કે ક્લાયન્ટ હજી ન બનાવેલી ટનલ દ્વારા અંતિમ બિંદુ સુધી પહોંચવાનો પ્રયત્ન કરે છે, અને પરિણામ ટૂંકા રસ્તાને બદલે લૂપ કે શાંત પ્રતીક્ષા હોય છે.
ઓપરેટરે આપેલું જાહેર અંતિમ બિંદુ વાપરો, અને પૂલને જે માટે બન્યો તે માટે રાખો: ટનલની અંદરનાં સરનામાં. પૂલની શ્રેણી, સ્થિર ફાળવણી અને સ્થાયિત્વ માર્ગ એક જ જગ્યાએ લખવાથી આગલી વ્યક્તિને દરેક ભાડાને મનસ્વી ગણવાથી બચાવે છે.