બે માલિકો, એક સરનામું: TAP બ્રિજ પર ડુપ્લિકેટ IP

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

બ્રિજને સ્પર્શ કરતા પહેલા સંઘર્ષના પુરાવા વાંચો

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

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

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

સેગમેન્ટ પરના દરેક દાવાની યાદી બનાવો

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

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

ip -4 addr show | grep -E 'inet |^[0-9]+: '
bridge link show
ip neigh show dev br0

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

બ્રિજને ફક્ત ત્યાં જ નંબર આપો જ્યાં ઓળખની જરૂર હોય

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

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

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

સુધારો રીબૂટમાં ટકી રહે તેમ કરો

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

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

DHCP શ્રેણીની અંદરના બ્રિજ સરનામાંને બાકાત તરીકે અનામત રાખો, અથવા તેમને બહાર ખસેડો. ફક્ત સ્પ્રેડશીટમાં રહેલું અનામત બાકાત નથી, અને ફાળવનાર તેને વાંચશે નહીં.

દરેક ક્લાયન્ટ ઑનલાઇન હોય ત્યારે તે સાબિત કરો

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

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

arping -D -I br0 10.8.0.2
ip neigh show dev br0 | grep 10.8.0.2

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