સ્થિતિ ફાઇલ સેશન ગણે છે, તેમની પાછળનું LAN નહીં
સ્નેપશોટ VPN સેશન અને રાઉટિંગ સ્થિતિની યાદી આપે છે, સાઇટ પાછળનું દરેક મશીન નહીં. હેડર, રેકોર્ડ પ્રકારો અને ફાઇલની ઉંમર સાથે વાંચો.
કોઈ પૂછે છે કે VPN પર કેટલા મશીન છે, અને પુરાવા તરીકે સ્થિતિ ફાઇલ રજૂ કરવામાં આવે છે. તે વધુ સાંકડા પ્રશ્નનો જવાબ આપે છે: આ સ્નેપશોટમાં કેટલા સેશન છે અને સર્વર કયા વર્ચ્યુઅલ સરનામાં રાઉટ કરે છે. આ બે પ્રશ્નો વચ્ચેનું અંતર એ છે જ્યાં મોટાભાગની રિપોર્ટિંગ ભૂલો રહે છે, અને તેને બંધ કરવાની શરૂઆત ફાઇલના પોતાના હેડર વાંચવાથી થાય છે.
સ્નેપશોટમાં ખરેખર શું છે
જ્યારે તે સર્વર ઇન્સ્ટન્સ માટે સ્થિતિ આઉટપુટ ગોઠવાયેલું હોય ત્યારે ફાઇલ અંતરાલ પર લખાય છે, તેથી તે સામયિક ચિત્ર છે, લાઇવ ફીડ નહીં. તેના વિભાગો સેશન અને આંતરિક રાઉટિંગ સ્થિતિ અલગ રીતે સૂચિબદ્ધ કરે છે, અને ફોર્મેટ આવૃત્તિ કૉલમ લેઆઉટ નક્કી કરે છે.
status /run/openvpn/office.status 30
status-version 3આવૃત્તિ 3 હેડર પંક્તિ સાથે ટૅબ-અલગ ક્ષેત્રો લખે છે, જ્યારે જૂના ફોર્મેટ અલગ હોય છે અને પછીની આવૃત્તિઓ ક્ષેત્રો ઉમેરી શકે છે. કૉલમ નંબર હાર્ડકોડ કરવાને બદલે હેડર વાંચો, કારણ કે સ્થાનો ધારી લેતી સ્ક્રિપ્ટ આગલા અપગ્રેડમાં ચૂપચાપ તૂટી પડે છે.
| Record | What it describes | What it cannot tell you |
|---|---|---|
| Client list | A session in this snapshot | How many people or machines that session represents |
| Real address | The outer peer address and port | Which device is behind it |
| Routing rows | Virtual addresses and route ownership | Which downstream hosts are alive |
સેશન ગણો, લોકો કે મશીન નહીં
એક સાઇટ કનેક્શન તેની પાછળનાં ઘણાં અધિકૃત મશીનોનું ટ્રાફિક વહન કરી શકે છે. એક વ્યક્તિ પણ એક જ સમયે લેપટોપ અને ફોનથી એક કરતાં વધુ સેશન રાખી શકે છે. આમાંથી કોઈ પણ પૅટર્ન ગણતરીમાં દેખાતું નથી, તેથી કનેક્ટેડ વપરાશકર્તા ત્યારે જ અર્થપૂર્ણ છે જ્યારે તમે એકમ વ્યાખ્યાયિત કરો. કોઈ ગણવાનું શરૂ કરે તે પહેલાં પૂછો કે રિપોર્ટને કયું એકમ જોઈએ.
જો સંખ્યા લાઇસન્સિંગ કે ક્ષમતા માટે મહત્ત્વની હોય, તો એકમને રિપોર્ટ સાથેના એ જ દસ્તાવેજમાં વ્યાખ્યાયિત કરો. જે રિપોર્ટ કહેતો નથી કે તે સેશન, ઓળખ કે ઉપકરણ ગણે છે, તે વાચકે અપેક્ષા રાખેલા એકમ તરીકે વંચાશે.
બહારનું સરનામું ઓળખકર્તા નથી
વાસ્તવિક સરનામાનું ક્ષેત્ર સર્વર જેમ જુએ તેમ પીઅર સરનામું અને પોર્ટ છે. એક અનુવાદિત જાહેર સરનામા પાછળના ઘણા ક્લાયન્ટ તે સરનામું વહેંચે છે, તેથી તેના આધારે જૂથીકરણ સંબંધવિહીન સેશનને ભેગાં કરે છે. પોર્ટ પણ કનેક્શન વચ્ચે બદલાય છે, જે જોડીને સ્થિર કી તરીકે નકામી બનાવે છે. એ રીતે જૂથબદ્ધ રિપોર્ટ સચોટ દેખાય છે અને ખોટો છે.
જૂથીકરણ માટે અસરકારક ક્લાયન્ટ ઓળખ વાપરો, અને સરનામાને પરિવહન વિગત તરીકે ગણો. જ્યારે બે પંક્તિઓ એક ઓળખ વહેંચે છે, ત્યારે તેનો અર્થ સામાન્ય રીતે સમવર્તી સેશન છે, નકલી રેકોર્ડ નહીં.
રાઉટિંગ પંક્તિઓ હોસ્ટ ઇન્વેન્ટરી નથી
રાઉટિંગ એન્ટ્રી એવા સબનેટનું નામ આપી શકે છે જેના માટે એક પીઅર જવાબદાર છે, અને સબનેટ તેના હોસ્ટની યાદી નથી. સર્વર જાણે છે કે તે શ્રેણી ચોક્કસ સેશનને મોકલવી જોઈએ, અને તેમાંથી કયા મશીન ચાલુ છે, કોઈ એપમાં પ્રમાણિત છે કે કોઈને ઉપયોગી છે તેની તેને કોઈ જાણ નથી. રાઉટિંગ કોષ્ટક પહોંચતા વર્ણવે છે, કબજો નહીં. એ જ તફાવત એટલા માટે છે કે VPN ઇન્વેન્ટરી પ્રશ્નનો જવાબ આપી શકતું નથી.
ઘણી પંક્તિઓ એ જ પીઅર તરફ પણ ઇશારો કરી શકે છે, કારણ કે સાઇટ એક કરતાં વધુ શ્રેણી જાહેર કરી શકે છે. પંક્તિઓ ગણીને પરિણામને ઉપકરણ ગણતરી કહેવું તૈનાતીને મનસ્વી પરિબળથી વધારીને બતાવે છે.
જો જરૂરિયાત ખરેખર સંપત્તિ ઇન્વેન્ટરી હોય, તો જે નેટવર્કની માલિકી ધરાવે તે ઇન્વેન્ટરી પ્રક્રિયા વાપરો. VPN ઓળખી શકે છે કે કયો પીઅર રૂટ વહન કરે છે, અને તે તેની પાછળ કયા હોસ્ટ છે તેનાથી અલગ હકીકત છે.
ઉંમર, પરવાનગીઓ અને લાઇવ દૃશ્ય
દરેક જવાબ સાથે ફાઇલનો ફેરફાર સમય રાખો. કલાકો પહેલાં અટકેલો સર્વર તેનો છેલ્લો સ્નેપશોટ જગ્યાએ છોડી જાય છે, અને વર્તમાન તરીકે રજૂ થયેલી જૂની ફાઇલ કોઈ રિપોર્ટ ન હોવા કરતાં પણ ખરાબ છે.
ડિરેક્ટરી અસ્તિત્વમાં હોવી જોઈએ અને જે એકાઉન્ટ હેઠળ સેવા ખરેખર ચાલે છે તેનાથી લખી શકાય તેવી હોવી જોઈએ, જે હાર્ડનિંગ પાસ પછી ભૂલવું સહેલું છે. ફાઇલમાં સામાન્ય રીતે નામ અને સરનામાં હોય છે, તેથી તેને વહીવટી જગ્યાએ રાખો, વેબ સર્વર જ્યાંથી તેને પરોસી શકે એવી કોઈ પણ જગ્યાએ નહીં. પરવાનગીઓ સેવા એકાઉન્ટથી તપાસો, તમારા શેલથી નહીં. જે સ્નેપશોટ ચૂપચાપ અપડેટ થવાનું બંધ કરે છે તે શાંત નેટવર્ક જેવો જ દેખાય છે.
ઘટના-આધારિત જરૂરિયાતો માટે ઝડપી પોલિંગને બદલે સમર્થિત મેનેજમેન્ટ ઇન્ટરફેસ વાપરો. તે ઇન્ટરફેસને મેટ્રિક્સ નહીં, નિયંત્રણ તરીકે ગણો, અને ફક્ત સેશન ગણવા માટે તેને ક્યારેય ઇન્ટરનેટ પર ન ખોલો.