એક જ સબનેટ ધરાવતી બે સાઇટ્સ એક LAN કેમ નથી

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

હોસ્ટ રાઉટર પહેલાં નિર્ણય લે છે

192.168.77.10/24 સરનામું ધરાવતું હોસ્ટ ગંતવ્યને પોતાના પ્રીફિક્સ સાથે સરખાવે છે. તે પ્રીફિક્સની અંદરનું બધું સીધી લિંક પર છે, તેથી હોસ્ટ ગંતવ્યનું લિંક-સ્તર સરનામું સીધું ઉકેલે છે. બહારનું બધું ડિફોલ્ટ ગેટવે પર જાય છે.

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

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

ARP સ્થાનિક લિંકનો પ્રશ્ન છે

ARP પૂછે છે કે આ લિંક પર સરનામું કોનું છે, અને જવાબ એવી વસ્તુથી આવવો જોઈએ જે પ્રસારણ સાંભળે. IPsec ટનલના બીજા છેડેનું રાઉટર તેને સાંભળતું નથી, સિવાય કે ડિઝાઇન બંને સાઇટને એક પ્રસારણ ડોમેન બનાવે.

એક જ સરનામું ધરાવતાં બે ઉપકરણો સ્થિતિ વધુ ખરાબ કરે છે: સફળ ઉકેલ પણ કહી શકતો નથી કે કયું જવાબ આપ્યો.

નકલી સરનામાંકન રાઉટિંગ ભૂલ નથી અને કોઈ રૂટ તેને સુધારતો નથી. કાં તો સાઇટ્સ અલગ પ્રીફિક્સમાં ફરી-ક્રમાંકિત થાય છે, અથવા જાણી જોઈને એક લિંક-સ્તર ડોમેન બને છે.

વિસ્તૃત સેગમેન્ટ ફ્રેમ વહે છે, રૂટ નહીં

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

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

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

Proxy ARP ત્રીજી ડિઝાઇન છે

રાઉટર દૂરના સરનામા માટે ARPનો જવાબ આપી શકે છે અને પછી ત્યાં રાઉટ કરી શકે છે. આ મોકલનાર માટે દૂરના હોસ્ટને પ્રસારણ ડોમેન લંબાવ્યા વિના સીધી લિંક પર દેખાડે છે.

તે બ્રિજિંગ કરતાં સાંકડું સાધન છે: તે ફોરવર્ડિંગ, પરત રૂટ અને દરેક સરનામાના સ્પષ્ટ માલિક પર આધાર રાખે છે.

તે મનસ્વી બિન-IP પ્રોટોકોલને રાઉટ કરી શકાય તેવા પણ બનાવતું નથી, અને ઇથરનેટ પ્રસારણ ડોમેન ફરી ઉત્પન્ન કરતું નથી. જ્યારે જરૂરિયાત બરાબર એ જ અવેજી હોય ત્યારે વાપરો, મુલતવી રાખેલા ફરી-ક્રમાંકનના શોર્ટકટ તરીકે નહીં.

જરૂરિયાત પરથી પસંદ કરો, પછી ચકાસો

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

તમારી પાસે ખરેખર કઈ ડિઝાઇન છે તે નિશ્ચિત કરો હોસ્ટને પૂછીને કે તે ગંતવ્ય સાથે શું કરે છે:

ip route get 192.168.77.20
ip neigh show 192.168.77.20

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