VPN એક્ઝિટ સરનામા રજિસ્ટરે ખરેખર શું રેકોર્ડ કરવું જોઈએ?
એક્ઝિટ રજિસ્ટર ત્યારે જ ઉપયોગી છે જ્યારે દરેક એન્ટ્રી તેનો અર્થ, તેનો પ્રકાશક અને તેની સમાપ્તિ જણાવે. વર્ગીકરણ એ ગ્રાહકની ઓળખ નથી.
એક્ઝિટ રજિસ્ટર યાદી જેવા લાગે છે, અને યાદી મુશ્કેલ ભાગ નથી. મુશ્કેલ ભાગ એ નક્કી કરવાનો છે કે દરેક એન્ટ્રી શું દાવો કરે છે, તેને કોણ પ્રકાશિત કરી શકે છે, અને જ્યારે દાવો સાચો રહેતો નથી ત્યારે શું થાય છે. આ પ્રસ્તાવોમાં ત્રણ અલગ સરનામા ભૂમિકાઓ ભેગી થઈ જાય છે, અને જે રજિસ્ટર તેમને ભેગી કરે છે તે કોઈ પણ પ્રશ્નનો વિશ્વસનીય જવાબ આપી શકતું નથી. એક એન્ટ્રીને પ્રકાશનથી પાછી ખેંચવા સુધી અનુસરો અને ડિઝાઇનની આવશ્યકતાઓ જાતે દેખાશે.
યાદીથી નહીં, રેકોર્ડથી શરૂ કરો
પહેલો પ્રશ્ન કેટલા સરનામાં સામેલ કરવા તે નથી, પણ એક પંક્તિનો અર્થ શું છે તે છે. શું તે વર્ણવે છે કે ગ્રાહકો ક્યાં જોડાય છે, કોઈ ગંતવ્ય કયો સ્રોત જોઈ શકે છે, અથવા કોણ રજિસ્ટરમાં ફાળવણી ધરાવે છે? આ ત્રણ દાવા છે, ત્રણ માલિકો અને ત્રણ નિષ્ફળતા પદ્ધતિઓ સાથે. જે રજિસ્ટર જણાવતું નથી કે તે તેમાંથી કયું રેકોર્ડ કરે છે તેની માન્યતા, સુધારો કે સમાપ્તિ થઈ શકતી નથી. અર્થને યોગ્ય રીતે સમજવો એ ડિઝાઇન કાર્ય છે, અને યાદી માત્ર પરિણામ છે.
કોઈ પણ સ્કીમા લખતા પહેલાં પંક્તિની વ્યાખ્યા લખો. જો વ્યાખ્યાને «અને» શબ્દની જરૂર હોય, તો તે સંભવતઃ બે રેકોર્ડ છે જે એક હોવાનો ઢોંગ કરે છે.
એકસરખી દેખાતી ત્રણ સરનામા ભૂમિકાઓ
ભૂમિકાઓને ભેગી કરવી સહેલી છે કારણ કે એક જ તૈનાતી એકસાથે ત્રણેયનો ઉપયોગ કરી શકે છે, અને ઘણી વાર કરે છે. એક સેવા એક સરનામા પર જોડાણો સમાપ્ત કરી શકે છે અને બીજા સરનામાથી ટ્રાફિક ફોરવર્ડ કરી શકે છે, જ્યારે રજિસ્ટર સંપૂર્ણપણે ત્રીજી હકીકત નોંધે છે.
| Address role | Who may publish | What it does not prove | Withdrawal trigger |
|---|---|---|---|
| Forwarded exit | The operator that forwards the traffic, or a feed it authorizes | That a subscriber is behind the address, or that all its traffic is tunnelled | The address stops forwarding for that operator, or the prefix is reassigned |
| Registered allocation | The registry, or the holder of the allocation | That the resource is used as a VPN exit, or which application uses it | The allocation is returned, transferred, or the holder changes |
| Tunnel entry | The operator that terminates the tunnel | That traffic exits from the same address, or that the client is a subscriber | The endpoint is decommissioned or its address changes |
હોસ્ટિંગ બ્લોકમાં VPN એક્ઝિટ અને અસંબંધિત વર્કલોડ સાથે સાથે હોઈ શકે છે, તેથી રજિસ્ટર મેળ કોઈ ચોક્કસ સરનામું ચોક્કસ ક્ષણે શું કરે છે તે વિશે કંઈ કહેતું નથી. જે એન્ટ્રી તેની ભૂમિકા જણાવતી નથી તે કોઈ ખાસ વસ્તુનો પુરાવો નથી. ભૂમિકાનું નામ આપવું એ જ રેકોર્ડને ખોટો ઠેરવી શકાય તેવો બનાવે છે. સરનામા કુટુંબ પણ જણાવો, કારણ કે ફક્ત IPv4 આવરી લેતું રજિસ્ટર ચૂપચાપ વિરુદ્ધ ધારણા કરનાર દરેકને ગેરમાર્ગે દોરશે.
એક એન્ટ્રીને પ્રકાશનથી પાછી ખેંચવા સુધી અનુસરો
એક કાલ્પનિક એક્ઝિટ લો અને તેને અનુસરો. ઓપરેટર જાહેર કરેલા અમલ સમયે પ્રીફિક્સ અને તેની ભૂમિકા પ્રકાશિત કરે છે, ગ્રાહકો તેને મેળવે છે, અને પછીથી સરનામું એક્ઝિટ તરીકે સેવા આપવાનું બંધ કરે છે. દરેક પગલાને નિયમની જરૂર છે: કોણ પ્રકાશિત કરી શકે, પ્રીફિક્સ ખરેખર શું આવરી લે છે, એન્ટ્રી ક્યારે અમલમાં આવે છે, અને તે કેવી રીતે પાછી ખેંચાય છે. પાછી ખેંચવાના માર્ગ વિનાનો ફીડ જૂના દાવાઓ એકઠા કરે છે જેને કોઈ વર્તમાન દાવાઓથી અલગ પાડી શકતું નથી.
પ્રકાશનની સત્તાને લેબલની ચોકસાઈથી અલગ કરો. સંસ્થાને સંસાધન સાથે જોડતો રજિસ્ટર રેકોર્ડ ફાળવણી સાબિત કરે છે, વર્તમાન ઉપયોગ નહીં, અને તે અલગ પુરાવાઓ સાથેના અલગ દાવાઓ છે. ગ્રાહકોએ જાણવું જોઈએ કે તેઓ બેમાંથી કોના પર ભરોસો કરે છે.
સુધારણાને પણ વ્યાખ્યાયિત કરો. ગ્રાહકને ફરી ફાળવેલું સરનામું, અથવા ખોટા લેબલથી પકડાયેલી અસંબંધિત સેવા, ટિકિટ કતારમાં દલીલને બદલે ઉકેલનો દસ્તાવેજી માર્ગ માંગે છે. પાછી ખેંચવાનું ટ્રિગર પ્રકાશન નિયમ સાથે જ સમાન દસ્તાવેજમાં હોવું જોઈએ.
પ્રકાશિત ફીડ શું ટેકો આપી શકે છે અને શું નહીં
પ્રકાશિત પ્રીફિક્સ લક્ષણો સ્થાપિત પેટર્ન છે, અને હાલનાં ઉદાહરણો વર્તનને બદલે ભૂગોળ અથવા માલિકીનું વર્ણન કરે છે. VPN ફીડને તેનું પોતાનું અર્થશાસ્ત્ર, પોતાના પુરાવા નિયમો અને પોતાની સમીક્ષા પ્રક્રિયા જોઈએ, અને દેશની યાદીનું નામ બદલવાથી તેમાંથી કંઈ મળતું નથી. ARIN રજિસ્ટ્રી માર્ગદર્શિકા દર્શાવે છે કે ફાળવણી રેકોર્ડ શું દાવો કરે છે અને શું નહીં, અને નવા ફીડે પોતાના દાવાઓ વિશે એટલી જ સ્પષ્ટતા મેળવવી પડશે. આ સ્પેસિફિકેશનનું કામ છે, ફરી લેબલ કરવાનું કામ નહીં.
આવો ફીડ જે ટેકો આપી શકે છે તે નેટવર્ક સ્રોત વિશેનો વર્ગીકરણ નિર્ણય છે. જે તે કરી શકતું નથી તે છે વહેંચાયેલા સરનામા પાછળની વ્યક્તિને ઓળખવી, તે સરનામેથી આવતો બધો ટ્રાફિક ટનલમાંથી પસાર થાય છે તે સાબિત કરવું, અથવા ચોક્કસ વિનંતી દુરુપયોગ છે કે નહીં તે નક્કી કરવું. આ ત્રણ અલગ પ્રશ્નો છે, ત્રણ અલગ પુરાવા આવશ્યકતાઓ સાથે.
કાનૂની પ્રશ્નને સ્પેસિફિકેશનની બહાર રાખો
ટેકનિકલ સ્પેસિફિકેશન નક્કી કરી શકતું નથી કે પ્રસ્તાવિત નોંધણી આવશ્યકતા કાયદેસર, પ્રમાણસર કે શાણપણભરી છે કે નહીં. તે મૂલ્યાંકનને વાસ્તવિક કાયદાકીય લખાણ, અસરગ્રસ્ત અધિકારો, અધિકારક્ષેત્ર અને કાનૂની વિશ્લેષણની જરૂર છે જે ડેટા ફોર્મેટ આપી શકતું નથી. ફોર્મેટ સારી રીતે રચાયેલું હોઈ શકે અને તોપણ ખરાબ નીતિને ટેકો આપી શકે.
સ્પેસિફિકેશન જે કરી શકે છે તે ચર્ચાને મૂર્ત બનાવવી છે. પહેલાં પ્રસ્તાવિત ડેટા, તેની મર્યાદાઓ અને તેની નિષ્ફળતા પદ્ધતિઓ વ્યાખ્યાયિત કરો, જેથી નીતિ ચર્ચા વાસ્તવિક મિકેનિઝમ વિશે હોય, એવી અવ્યાખ્યાયિત યાદી વિશે નહીં જે દરેક સહભાગી અલગ રીતે કલ્પે છે. કાનૂની પ્રશ્નમાં ટેકનિકલ દસ્તાવેજ આટલું જ મહત્તમ યોગદાન આપી શકે છે.