બે સાઇટ, એક સબનેટ: દરેક માટે એલિયાસ દૃશ્ય બનાવો

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

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

દરેક સાઇટ માટે એક એલિયાસ પ્રીફિક્સ પસંદ કરો

દરેક સાઇટને સંપૂર્ણ એલિયાસ પ્રીફિક્સ આપો જે પર્યાવરણમાં બીજા કોઈની ન હોય. બે સાઇટની યોજના સાઇટ A ના 192.168.50.0/24 ને 172.21.10.0/24 સાથે અને સાઇટ B ના સમાન LAN ને 172.21.20.0/24 સાથે મેપ કરી શકે છે. દરેક ભાગ લેતા નેટવર્ક સામે ઉમેદવારો તપાસો, જેમાં ક્લાઉડ VPC અને અન્ય VPN પૂલનો સમાવેશ થાય છે. ખાનગી સરનામા જગ્યા દરેક સંસ્થા વચ્ચે વહેંચાયેલી છે, તેથી કોઈ શ્રેણી RFC 1918 હોવાનો અર્થ એ નથી કે તે અહીં મુક્ત છે.

દૂરસ્થ વપરાશકર્તાઓને મૂળ સબનેટ નહીં, એલિયાસ પ્રકાશિત કરો. મૂળ શ્રેણી સ્થાનિક હકીકત રહે છે.

બંને દિશામાં અનુવાદ કરો

બંને દિશામાં અનુવાદ કરો. લક્ષ્ય મેપિંગ એલિયાસ સરનામાને માલિક સાઇટ પર મૂળ સરનામામાં ફરીથી લખે છે. સ્રોત મેપિંગ દૂરસ્થ કૉલરને એવા એલિયાસમાં ફરીથી લખે છે જે અન્ય સાઇટ અલગ પાડી શકે.

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

નીતિ, સિલેક્ટર અને રૂટ કયા તબક્કે લાગુ પડે છે તે પોલિસી-આધારિત IPsec, રૂટ-આધારિત ટનલ અને અન્ય ઉત્પાદનો વચ્ચે અલગ પડે છે. તમે ચલાવો છો તેના માટે ડિઝાઇન કરો.

યોજનાને ઓવરલે દ્વારા લઈ જાઓ

હબમાં, દરેક એલિયાસ પ્રીફિક્સને તેની માલિક સાઇટ-પથને સોંપો અને ફક્ત કાર્યને જરૂરી ટ્રાન્ઝિટની પરવાનગી આપો. મેશમાં, દરેક સંબંધિત પીઅરને સમાન પ્રીફિક્સ અને નીતિ-જ્ઞાનની જરૂર છે. ટનલ ઉમેરવાથી અસ્પષ્ટ સરનામાંકન એકલાથી ઠીક થતું નથી.

આખા સબનેટનું પ્રકાશન એક સેવાના પ્રકાશન કરતાં વિશાળ છે. જો ફક્ત થોડા મશીન કે પોર્ટની જરૂર હોય, તો એક્સેસ નિયમોને મેપિંગ કરતાં સાંકડા રાખો.

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

દરેક કૉલર જે નામો જુએ છે તે સુધારો

જાળવણી નામોને કૉલરના દૃશ્ય સાથે મેળ ખાતા જવાબો આપો. જો દૂરસ્થ ઇજનેર હોસ્ટનામ રિઝોલ્વ કરે, તો તે તે સાઇટનું એલિયાસ સરનામું પરત આપવું જોઈએ, વહેંચાયેલી મૂળ શ્રેણી નહીં.

પ્રથમ જાળવણી વિન્ડો પહેલાં દરેક સાઇટ માટે DNS દૃશ્યો તપાસો. જે નામ મૂળ સબનેટમાં રિઝોલ્વ થાય છે તે કૉલરને તે અસ્પષ્ટતામાં પાછું મોકલે છે જે યોજનાએ દૂર કરવાની હતી.

દરેક સાઇટ માટે રેકોર્ડ કરો અને ચકાસો

વાસ્તવિક કૉલરથી દરેક સાઇટ અલગથી સ્વીકારો અને પુષ્ટિ કરો કે કયું મશીન જવાબ આપ્યો. મૂળ સરનામું, એલિયાસ, માલિક ગેટવે અને મંજૂર સેવા સાથે રેકોર્ડ કરો.

જ્યારે ત્રીજી સાઇટ સમાન ડિફૉલ્ટ LAN સાથે આવે છે ત્યારે આ ઇન્વેન્ટરી જ ભેદ જાળવે છે. પોલિસી-આધારિત IPsec NAT માર્ગદર્શિકા એક ઠોસ અનુવાદ મોડેલનું દસ્તાવેજીકરણ કરે છે; તે દરેક પ્લેટફોર્મ માટે કરાર નથી.