ਦੋ ਮਾਲਕ, ਇੱਕ ਪਤਾ: 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 ਘਟਨਾ ਨੇ ਦਿੱਤਾ ਸੀ। ਉਹ ਆਉਟਪੁੱਟ ਤਬਦੀਲੀ ਰਿਕਾਰਡ ਨਾਲ ਰੱਖੋ, ਕਿਉਂਕਿ ਪਤਾ ਵਿਲੱਖਣ ਰੂਪ ਵਿੱਚ ਰੱਖਿਆ ਗਿਆ ਹੈ ਇਸ ਦਾ ਉਹੀ ਇੱਕੋ-ਇੱਕ ਸਬੂਤ ਹੈ।