VPN એડ્રેસ સ્પેસ ફાળવણી પ્રમાણે પસંદ કરો, અસ્પષ્ટતા પ્રમાણે નહીં
બેન્ચમાર્ક, સહભાગી અને દસ્તાવેજીકરણ શ્રેણીઓમાં દરેકનો માલિક અને હેતુ છે. રજિસ્ટરમાંથી VPN સ્પેસ પસંદ કરો, પછી જે ઓવરલેપ દૂર ન કરી શકો તેની યોજના કરો.
અસામાન્ય દેખાતો પ્રીફિક્સ ઘર અને ઓફિસ વચ્ચેના એડ્રેસ સંઘર્ષમાંથી છટકું જેવું લાગે છે, અને સામાન્ય રીતે એવું નથી હોતું. IPv4 વિશેષ હેતુ રજિસ્ટરમાંના દરેક બ્લોકનો માલિક, હેતુ અને અસ્તિત્વનું કારણ છે, અને શાંત લાગે છે માટે એક ઉધાર લેવું અથડામણને દૂર કરવાને બદલે ખસેડે છે. આને ક્રમ તરીકે ચલાવો: ફાળવણી વાંચો, પહેલેથી શું ઓવરલેપ થાય છે તેની યાદી બનાવો, અને પછી જ નક્કી કરો કે તમે નંબર બદલી રહ્યા છો, અનુવાદ કરી રહ્યા છો કે નવી સ્પેસ બનાવી રહ્યા છો. ક્રમ મહત્વનો છે કારણ કે ત્રીજું પગલું પહેલા બેમાં શું મળ્યું તેના પર આધાર રાખે છે.
શ્રેણી ઉધાર લેતા પહેલાં ફાળવણી વાંચો
IANAનું વિશેષ હેતુ રજિસ્ટર પુનઃવાપરી શકાય તેવી ખાનગી સ્પેસની શ્રેણીઓને એક ચોક્કસ તકનીકી હેતુ પૂરો કરતી શ્રેણીઓથી અલગ કરે છે. ખાનગી વપરાશ, સહભાગી એડ્રેસ સ્પેસ, બેન્ચમાર્ક અને દસ્તાવેજીકરણ બ્લોક સ્પ્રેડશીટમાં સરખા દેખાય છે અને રૂટ થયા પછી સાવ અલગ વર્તે છે.
| Range | Category | What it means for a VPN plan |
|---|---|---|
| 172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8 | RFC 1918 private use | Reusable by any network, so remote sites may already use the same numbers |
| 100.64.0.0/10 | Shared address space | Intended for provider-side carrier-grade NAT arrangements, not a second private pool |
| 198.18.0.0/15 | Benchmarking | Reserved for test traffic measurement; not spare production space |
| 203.0.113.0/24, 198.51.100.0/24, 192.0.2.0/24 | Documentation (RFC 5737) | Illustration only; a guide that uses them is not assigning them to you |
| 169.254.0.0/16, 240.0.0.0/4 | Link-local, reserved | Never a routed site subnet, whatever the prefix length suggests |
ફક્ત બીજા ઓક્ટેટમાં ભિન્ન હોય તેવા બે પ્રીફિક્સ એક જ બ્લોક નથી: 198.18.0.0/15 બેન્ચમાર્ક અનામત ધરાવે છે, જ્યારે 192.18.0.0/16 એવું કંઈ ધરાવતું નથી. ફક્ત અનામત શ્રેણી જેવો દેખાતો નંબર તેનો અર્થ વારસામાં લેતો નથી. આ ગૂંચવણ ફાયરવોલ નિયમ સુધી પહોંચે તે પહેલાં બીજી નજરને લાયક છે.
ઉત્પાદનો ક્યારેક સંકલિત ઓવરલેની અંદર વિશેષ શ્રેણીનો જાણી જોઈને ઉપયોગ કરે છે અને તે તેમની રચના છે જેનું દસ્તાવેજીકરણ થવું જોઈએ. તેનાથી એ જ શ્રેણી અસંબંધિત LAN માટે ખાલી જગ્યા બનતી નથી. જાહેર સ્પેસ પણ છુપાવાની જગ્યા નથી: બીજાના એડ્રેસ તરફનો ખાનગી રૂટ તેના કાયદેસર લક્ષ્ય માટેના ટ્રાફિકને વાળી લે છે.
તમારી પાસે પહેલેથી હોય તેવા ઓવરલેપની યાદી બનાવો
પ્રીફિક્સ પસંદ કરતા પહેલાં, ટનલમાંથી પહોંચી શકાય તેવા દરેક નેટવર્કની યાદી બનાવો. સાઇટ્સ, ક્લાયન્ટ પૂલ, ક્લાઉડ VPC અને પાર્ટનર લિંક બધા ગણાય છે, અને પાર્ટનર લિંક એ છે જે લોકો પ્રથમ કનેક્શન પ્રયાસ નિષ્ફળ ન થાય ત્યાં સુધી ભૂલી જાય છે.
ip -4 route show table all ip -6 route show ip -br addr ip route get 192.168.1.10
પરિણામોને એક કોષ્ટકમાં દરેક શ્રેણીના માલિક સાથે બાજુમાં મૂકો. જે શ્રેણી માટે તમે માલિકનું નામ ન આપી શકો તે શ્રેણી પછી તમે નંબર બદલી નહીં શકો, અને યાદી જ «અસામાન્ય» પ્રીફિક્સ વિશેની દલીલને ચોક્કસ નંબરો વિશેના નિર્ણયમાં ફેરવે છે. તે તમને એ પણ કહે છે કે તમે ટાળવા માંગતા સંઘર્ષ વાસ્તવિક છે કે કલ્પિત.
જો દૂરસ્થ કર્મચારીનું ઘરનું નેટવર્ક ઓફિસ LAN જેવું જ પ્રીફિક્સ વાપરે, તો તે સંઘર્ષ યાદીમાં દેખાય છે અને તેને સ્પષ્ટ રીતે સંભાળી શકાય છે. તે એ પુરાવો નથી કે બેન્ચમાર્ક બ્લોક શાણો વિકલ્પ હશે, અને તેને એ રીતે ગણવો એ જ આગળની અથડામણ પેદા કરવાની રીત છે.
પ્રીફિક્સની નકલ કરવાને બદલે એક અનન્ય ULA બનાવો
IPv6 પુનઃવપરાશની સમસ્યાને વધુ સુંદર નંબરને બદલે અલગ મિકેનિઝમથી ઉકેલે છે. RFC 4193 સ્થાનિક રીતે ફાળવેલા અનન્ય સ્થાનિક એડ્રેસને 40-bit સ્યુડો-રેન્ડમ વૈશ્વિક ઓળખકર્તા સાથે વ્યાખ્યાયિત કરે છે, જે તમને એવી સાઇટ /48 આપે છે જે બીજા કોઈની સાથે અથડાય તેની શક્યતા ખૂબ ઓછી છે. સંભાવના ઊંચી છે, સંપૂર્ણ નહીં, અને ULA પ્રીફિક્સ હજી પણ ઇન્ટરનેટ પહોંચ આપતું નથી.
openssl rand -hex 5
દસ હેક્સાડેસિમલ અંક ચાલીસ બિટ છે. તેમની આગળ fd મૂકો અને /48માં જૂથ બનાવો: 3f9c1a7b02 આઉટપુટ fd3f:9c1a:7b02::/48 બને છે. દરેક સાઇટ માટે એક બનાવો અને નોંધો, દરેક ડિપ્લોયમેન્ટમાં એ જ અનુકૂળ fd00::/48 પેસ્ટ કરવાને બદલે.
પછી ખાતરી કરો કે આખો માર્ગ ખરેખર IPv6 બોલે છે. ક્લાયન્ટ, ગેટવે, રૂટ, ખાનગી DNS અને સેવા નીતિ બધાએ સંમત થવું પડે, અને ટનલને પ્રીફિક્સ સોંપવાથી ફક્ત IPv4 વાપરતી એપ્લિકેશન તેનો ઉપયોગ કરતી નથી.
જે ઓવરલેપ દૂર ન કરી શકો તેની યોજના કરો
કેટલાક ઓવરલેપ કાયમી હોય છે, સામાન્ય રીતે કારણ કે ભાગીદાર નંબર બદલશે નહીં અને તમે તેને ફરજ પાડી શકતા નથી. ત્યારે તમે જાણી જોઈને સમર્થિત મિકેનિઝમ પસંદ કરો છો: તમારી બાજુ નંબર બદલવો, અલગ રૂટિંગ સંદર્ભ, અથવા સીમા પર સ્પષ્ટ અનુવાદ. જાણી જોઈને પસંદ કરવાનો અર્થ છે કે તમે કયું પસંદ કર્યું અને બાકીના બે કેમ નકારાયા તે લખવું. એ નોંધ જ ભવિષ્યની ફેરફાર સમીક્ષા ખરેખર વાંચશે.
અનુવાદે પરત માર્ગ જાળવવો જોઈએ, એટલે કે મૂળ અને રજૂ કરેલા બંને પ્રીફિક્સ નોંધવા અને તેમને એમાં રિઝોલ્વ થતા ખાનગી DNS નામો સાથે મેળવવા. મેપ કરેલું ઉપનામ એક કનેક્શનને અસ્પષ્ટ કરી શકે છે; તે મૂળ એડ્રેસને વૈશ્વિક રીતે અનન્ય બનાવતું નથી અને બીજા મેપિંગ વિના બીજા ઓવરલેપિંગ ભાગીદારને ટકી શકશે નહીં.
ફાળવણી તેના અપવાદ સાથે લખો
એક દસ્તાવેજ સાથે પૂર્ણ કરો જે દરેક પ્રીફિક્સ, તેની શ્રેણી, તેનો માલિક અને પસંદગીનું કારણ સૂચવે. અપવાદો તેમના અનુવાદ કે નંબર બદલવાના નિયમ અને કોઈએ મંજૂરી આપેલી તારીખ સાથે ઉમેરો. તેને લાગુ કરતા ફાયરવોલ નિયમોની બાજુમાં રાખો, એવા વિકિમાં નહીં જે ઘટનાસમયે કોઈ ખોલતું નથી. દસ્તાવેજ જ ડિલિવરેબલ છે, તેનો સારાંશ નહીં.
એ નોંધ જ આગલા ઇજનેરને વધુ વિચિત્ર દેખાતો નંબર શોધતા રોકે છે, અને એ જ રીતે આ સમસ્યા દર થોડા વર્ષે નવા નામ હેઠળ ફરી શોધાય છે. તે ફેરફાર સમીક્ષાને પ્રીફિક્સ વિશેના મંતવ્યને બદલે મંજૂરી આપવા જેવું કંઈક ઠોસ આપે છે. તેને એક વાર, ફાળવણીના અંતે લખો, જ્યારે તર્ક હજી તમારી સામે છે.