બે સક્રિય IPsec ટનલને હજી પણ પરત માર્ગની યોજના જોઈએ

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

રૂટ દોરતા પહેલા ચાર ગેટવે દોરો

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

તે કોષ્ટક એ ડિઝાઇન છે. તેના પછીનું બધું એ પ્રશ્ન છે કે ઉપકરણો કોષ્ટક સાથે સંમત છે કે નહીં.

આગળનો માર્ગ કેવી રીતે પસંદ થાય છે

સમાન ખર્ચનો મલ્ટિપાથ રૂટિંગ સ્તર હેડર ક્ષેત્રોને હેશ કરીને પ્રવાહોને આગલા હોપ્સ પર વહેંચે છે, જે RFC 2992 વિગતવાર વર્ણવે છે. તે પસંદગી સંપૂર્ણ સ્થિતિ-રહિત હોઈ શકે છે: તેને કોઈ કનેક્શન-ટ્રેકિંગ એન્ટ્રીની જરૂર નથી, ફક્ત અપરિવર્તિત ક્ષેત્રો પર સ્થિર હેશની જરૂર છે. માર્ગ સમૂહ અને હેશ ઇનપુટ સ્થિર રાખો, અને પ્રવાહનું દરેક પેકેટ એ જ આગલું હોપ પસંદ કરશે.

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

પરત માર્ગને ખરેખર શું જોઈએ

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

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

જ્યાં અનુવાદ તમારા વતી નક્કી કરે છે

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

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

સ્વીકૃતિ ક્રમમાં પસાર કરો

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

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