രണ്ട് ഉടമകൾ, ഒരു വിലാസം: 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 ഇവന്റ് നൽകിയ അതേ തെളിവ്. ആ ഔട്ട്പുട്ട് മാറ്റരേഖയ്ക്കൊപ്പം സൂക്ഷിക്കുക, കാരണം വിലാസം അദ്വിതീയമായി കൈവശം വയ്ക്കുന്നു എന്നതിന് അതാണ് ഏക തെളിവ്.