OpenVPN દ્વારા બે બોર્ડ વચ્ચે અલગ TAP બ્રિજ

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

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

બ્રિજ ખરેખર શું ખસેડે છે

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

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

Board A -- bench0 -- br-test -- tap-bench
                                 |  OpenVPN TAP
Board B -- bench0 -- br-test -- tap-bench

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

બ્રિજને સરનામું આપો, તેના સભ્ય પોર્ટને નહીં

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

ip link add br-test type bridge
ip link set bench0 master br-test
ip link set tap-bench master br-test
ip address add 172.30.90.2/24 dev br-test
ip link set bench0 up
ip link set tap-bench up
ip link set br-test up

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

દરેક બેન્ચ માટે એક સમર્પિત પોર્ટ કેમ

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

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

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

બ્રિજ ન બનાવતી સીમા

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

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

બીજા બે પરિવાર સ્પષ્ટ નિર્ણયને લાયક છે. સરનામાં યોજના બ્રિજને ફક્ત IPv4 નથી બનાવતી, તેથી IPv6 અને અન્ય EtherTypes ને પોતાની યોજના કે ફિલ્ટરની જરૂર છે. અને સફળ ping એ કંઈ કહેતું નથી કે બોર્ડના ડિસ્કવરી બ્રોડકાસ્ટ, મલ્ટિકાસ્ટ જૂથો કે જમ્બો ફ્રેમ માર્ગ પાર કરશે કે નહીં, કારણ કે તે અલગ ડિફોલ્ટ સાથેના અલગ ટ્રાફિક વર્ગો છે.

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

ટકાઉપણું અને તેને સાબિત કરતી કસોટીઓ

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

bridge link show
ip -d link show br-test
bridge fdb show br br-test | head

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