વાયરલેસ લિંક બેકઅપ: રાઉટેડ ફેલઓવર કે એક સેગમેન્ટ?

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

બંધ દરમિયાન શું ટકવું જોઈએ તે નક્કી કરો

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

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

રાઉટેડ ફેલઓવર: બે પ્રીફિક્સ, એક પસંદગીનો માર્ગ

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

ip route show | grep -E '10.44\.|10.45\.'
ip route get 10.45.0.10
ip route get 10.45.0.10 from 10.44.0.1

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

બ્રિજ્ડ ફેલઓવર: એક સેગમેન્ટ, એક અવરોધક માર્ગ

જો નિકટતા ખરેખર જરૂરી હોય, તો બેકઅપે ઇથરનેટ ફ્રેમ વહન કરવી પડે, જે રાઉટેડ IP ટનલ કરતું નથી. કેટલાક પ્લેટફોર્મ VPN ઇન્ટરફેસને સ્થાનિક સેગમેન્ટમાં બ્રિજ કરવાનું સમર્થન આપે છે, અને તે ઇન્ટરફેસ પછી સંબંધિત પરિણામો સાથે બ્રિજ સભ્ય બને છે. એક સાથે ફોરવર્ડ કરતા બે Layer 2 માર્ગ લૂપ બનાવે છે, તેથી ડિઝાઇનને બંને સાઇટને આવરી લેતું સ્પેનિંગ ટ્રી અને કયો માર્ગ અવરોધાવો જોઈએ તે અંગે સ્પષ્ટ નિવેદન જોઈએ છે.

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

જે સીમા મહત્ત્વની છે તેનું નિરીક્ષણ કરો

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

ping -c 3 -W 2 10.45.0.10
ip -brief link show dev wlan0
ip route get 10.45.0.10

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

ભાર હેઠળ બંને દિશાનો અભ્યાસ કરો

બીજાની ટોપોલોજીમાંથી એક જ કન્વર્જન્સ લક્ષ્ય નકલ ન કરો. શોધ સમય, રૂટ કે બ્રિજ કન્વર્જન્સ, ટનલ તૈયારી અને એપ્લિકેશન પુનઃપ્રાપ્તિ — દરેક પોતાનો વિલંબ ઉમેરે છે, અને તમારા સાધનો પરનો સરવાળો જ એકમાત્ર આંકડો છે જે મહત્ત્વનો છે. પ્રતિનિધિ ટ્રાફિક ચાલુ હોય ત્યારે અભ્યાસ કરો, જેથી માપમાં ઉત્પાદનમાં રહેલી કતારો અને સત્રો સમાય.

sudo ip link set dev wlan0 down
ip route get 10.45.0.10
sudo ip link set dev wlan0 up
ip route get 10.45.0.10

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