OpenVPN ਰਾਹੀਂ ਦੋ ਬੋਰਡਾਂ ਵਿਚਕਾਰ ਇਕੱਲਾ TAP ਬ੍ਰਿਜ

ਦੋ ਵਿਕਾਸ ਬੋਰਡਾਂ ਨੂੰ ਇੱਕ Ethernet ਭਾਗ ਸਾਂਝਾ ਕਰਨਾ ਹੈ, ਜਦੋਂ ਕਿ ਉਨ੍ਹਾਂ ਦੇ ਬੈਂਚ ਵੱਖ-ਵੱਖ ਇਮਾਰਤਾਂ ਵਿੱਚ ਹਨ। ਸੁਰੰਗ ਪਹਿਲਾਂ ਹੀ ਹੈ ਅਤੇ ਪਹਿਲਾਂ ਹੀ Ethernet ਢੋਂਦੀ ਹੈ, ਇਸ ਲਈ ਬਾਕੀ ਕੰਮ ਤਿੰਨ ਕਮਾਂਡਾਂ ਵਰਗਾ ਲੱਗਦਾ ਹੈ ਅਤੇ ਅਜਿਹਾ ਨਹੀਂ ਹੈ। ਹੋਸਟ ਬ੍ਰਿਜ ਕੀਤੇ ਫਰੇਮ ਨਾਲ ਕੀ ਕਰਦਾ ਹੈ, ਕੰਪਿਊਟਰ ਦਾ ਆਪਣਾ ਪਤਾ ਕਿੱਥੇ ਆਉਂਦਾ ਹੈ, ਅਤੇ ਬ੍ਰਿਜ ਕਿਹੜੀ ਹੱਦ ਨਹੀਂ ਬਣਾਉਂਦਾ—ਇਹ ਤਿੰਨ ਵੱਖਰੇ ਤੱਥ ਹਨ, ਅਤੇ ਦੂਜੇ ਵਿੱਚ ਗਲਤੀ ਕਰਨਾ ਹੀ ਆਮ ਤੌਰ 'ਤੇ ਇਸਦਾ ਕਾਰਨ ਹੁੰਦਾ ਹੈ ਕਿ ਲੈਬ ਰੁਕ-ਰੁਕ ਕੇ ਚੱਲਦੀ ਹੈ ਅਤੇ ਉਸਦੀ ਪ੍ਰਬੰਧਨ ਪਹੁੰਚ ਚੁੱਪਚਾਪ ਕਮਜ਼ੋਰ ਹੁੰਦੀ ਜਾਂਦੀ ਹੈ। ਇਨ੍ਹਾਂ ਤਿੰਨਾਂ ਤੱਥਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਟੋਪੋਲੋਜੀ ਚਿੱਤਰ ਵਿੱਚ ਨਹੀਂ ਦਿਸਦਾ।

ਹੇਠਾਂ ਦਿੱਤਾ ਮਾਰਗ ਦੋ Linux ਕੰਪਿਊਟਰਾਂ ਵਿਚਕਾਰ ਪ੍ਰਮਾਣਿਤ 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

ਦੋਵਾਂ ਕੰਪਿਊਟਰਾਂ ਤੇ ਇੱਕੋ ਨਾਮ ਸਥਾਨਕ ਨਾਮ ਹਨ, ਸਾਂਝੀਆਂ ਵਸਤੂਆਂ ਨਹੀਂ। ਬੈਂਚਾਂ ਵਿਚਕਾਰ ਇੱਕ Ethernet ਮਾਰਗ ਹੈ, ਦੂਜੀ ਕੇਬਲ ਅਤੇ ਲੂਪ ਬੰਦ ਕਰਨ ਵਾਲੀ ਦੂਜੀ ਸੁਰੰਗ ਤੋਂ ਬਿਨਾਂ; ਇੱਕੋ 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 ਅਡਾਪਟਰ ਹੋਰ ਵੀ ਮਾੜਾ ਹੈ: ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਮੋਡ ਵਿੱਚ ਤਾਰ ਰਹਿਤ ਇੰਟਰਫੇਸ ਬ੍ਰਿਜ ਕਰਨਾ Ethernet ਬ੍ਰਿਜ ਕਰਨ ਵਾਂਗ ਵਿਵਹਾਰ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਫੇਲ ਹੋਣਾ ਸਾਫ਼ ਨਹੀਂ ਸਗੋਂ ਉਲਝਾਉਣ ਵਾਲਾ ਹੁੰਦਾ ਹੈ।

ਲੈਬ ਰੇਂਜ ਨੂੰ ਕਿਸੇ ਵੀ ਉਤਪਾਦਨ DHCP ਖੇਤਰ ਤੋਂ ਬਾਹਰ ਰੱਖੋ। ਜੇ ਬੋਰਡਾਂ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਗਤੀਸ਼ੀਲ ਪਤੇ ਚਾਹੀਦੇ ਹੋਣ, ਤਾਂ ਇੱਕ ਪੂਲ ਵਾਲਾ ਇੱਕ ਅਧਿਕਾਰਤ ਵੰਡਣ ਵਾਲਾ ਹੀ ਇੱਕੋ-ਇੱਕ ਅਜਿਹਾ ਪ੍ਰਬੰਧ ਹੈ ਜੋ ਅਨੁਮਾਨਯੋਗ ਰਹਿੰਦਾ ਹੈ; ਇੱਕੋ ਭਾਗ ਤੇ ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਦੋ ਥਾਵਾਂ ਦੇ ਆਮ ਰਾਊਟਰ ਅਜਿਹੇ ਪਤੇ ਬਣਾਉਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਵਿਆਖਿਆ ਕੋਈ ਨਹੀਂ ਕਰ ਸਕਦਾ।

ਉਹ ਹੱਦ ਜੋ ਬ੍ਰਿਜ ਨਹੀਂ ਬਣਾਉਂਦਾ

ਬ੍ਰਿਜ ਕਰਨਾ ਰਾਊਟਿੰਗ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਹ ਅਲੱਗ ਕਰਨਾ ਵੀ ਨਹੀਂ ਹੈ। ਬ੍ਰਿਜ ਪਾਰ ਕਰਨ ਵਾਲੇ ਫਰੇਮ ਹੋਸਟ ਦੇ ਫਿਲਟਰਿੰਗ ਹੁੱਕਾਂ ਤੱਕ ਅਜੇ ਵੀ ਪਹੁੰਚ ਸਕਦੇ ਹਨ, ਸਥਾਪਿਤ bridge-netfilter ਮਾਰਗ ਦੇ ਆਧਾਰ ਤੇ, ਇਸ ਲਈ ਪ੍ਰਭਾਵੀ ਨੀਤੀ ਨੂੰ ਮੰਨਣ ਦੀ ਬਜਾਏ ਜਾਂਚਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਫਰੇਮ ਗੁੰਮ ਹੋਣ ਕਾਰਨ ਫਾਇਰਵਾਲ ਬੰਦ ਕਰਨਾ ਇੱਕ ਖਾਸ ਬੱਗ ਨੂੰ ਆਮ ਬੱਗ ਨਾਲ ਬਦਲਦਾ ਹੈ।

ਬ੍ਰਿਜ ਅਤੇ ਹਰ ਪ੍ਰਬੰਧਨ ਜਾਂ ਅਪਲਿੰਕ ਇੰਟਰਫੇਸ ਵਿਚਕਾਰ IP ਫਾਰਵਰਡਿੰਗ ਬੰਦ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ ਜਾਂ ਸਪੱਸ਼ਟ ਤੌਰ ਤੇ ਰੱਦ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਇਹ ਬ੍ਰਿਜ ਮੈਂਬਰਸ਼ਿਪ ਤੋਂ ਵੱਖਰਾ ਨਿਯੰਤਰਣ ਹੈ। ਕੰਪਿਊਟਰ ਦੇ ਲੈਬ ਪਤੇ ਨੂੰ ਗੇਟਵੇ ਚੁਣਨ ਵਾਲਾ ਬੋਰਡ ਬਿਲਕੁਲ ਇਹੀ ਪਰਖਦਾ ਹੈ: ਜੇ ਪ੍ਰਬੰਧਨ ਲੰਘਣਾ ਸਫਲ ਹੋਵੇ, ਤਾਂ ਤੁਹਾਡੀ ਸੋਚੀ ਹੱਦ ਕਦੇ ਸੀ ਹੀ ਨਹੀਂ।

ਹੋਰ ਦੋ ਪਰਿਵਾਰ ਸਪੱਸ਼ਟ ਫੈਸਲੇ ਦੇ ਹੱਕਦਾਰ ਹਨ। ਪਤਾ ਯੋਜਨਾ ਬ੍ਰਿਜ ਨੂੰ ਸਿਰਫ਼ IPv4 ਨਹੀਂ ਬਣਾਉਂਦੀ, ਇਸ ਲਈ IPv6 ਅਤੇ ਹੋਰ EtherType ਨੂੰ ਆਪਣੀ ਯੋਜਨਾ ਜਾਂ ਫਿਲਟਰ ਚਾਹੀਦਾ ਹੈ। ਅਤੇ ਸਫਲ ping ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ ਕਿ ਬੋਰਡ ਦੇ ਖੋਜ ਪ੍ਰਸਾਰਣ, ਮਲਟੀਕਾਸਟ ਸਮੂਹ ਜਾਂ ਜੰਬੋ ਫਰੇਮ ਮਾਰਗ ਪਾਰ ਕਰਨਗੇ ਜਾਂ ਨਹੀਂ, ਕਿਉਂਕਿ ਉਹ ਵੱਖਰੇ ਡਿਫਾਲਟ ਵਾਲੇ ਵੱਖਰੇ ਟ੍ਰੈਫਿਕ ਵਰਗ ਹਨ।

ਅੰਤ ਵਿੱਚ, ਢੋਆ-ਢੁਆਈ ਅਤੇ ਗੋਪਨੀਯਤਾ ਦੋ ਵੱਖਰੀਆਂ ਖਰੀਦਾਂ ਹਨ। TAP Ethernet ਢੋਂਦਾ ਹੈ; OpenVPN ਸੇਵਾ ਇਸਦੇ ਦੁਆਲੇ ਸੁਰੱਖਿਆ ਦਿੰਦੀ ਹੈ। VXLAN ਓਵਰਲੇ ਵੀ Ethernet ਢੋਂਦਾ ਹੈ ਅਤੇ ਆਪਣੇ ਆਪ ਕੋਈ ਗੋਪਨੀਯਤਾ ਨਹੀਂ ਦਿੰਦਾ, ਇਸ ਲਈ ਇੱਕ ਨੂੰ ਦੂਜੇ ਨਾਲ ਬਦਲਣਾ ਟੋਪੋਲੋਜੀ ਚਿੱਤਰ ਇੱਕੋ ਜਿਹਾ ਦਿਸਣ ਤੇ ਵੀ ਸੁਰੱਖਿਆ ਗੁਣ ਬਦਲ ਦਿੰਦਾ ਹੈ।

ਟਿਕਾਊਪਨ ਅਤੇ ਇਸਨੂੰ ਸਾਬਤ ਕਰਨ ਵਾਲੇ ਪਰਖ

ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਇੱਕ ਵਾਰ ਟਾਈਪ ਕੀਤਾ ਆਦੇਸ਼ ਸੰਰਚਨਾ ਨਹੀਂ ਹੈ। ਬ੍ਰਿਜ, ਪੋਰਟ ਮੈਂਬਰਸ਼ਿਪ ਅਤੇ ਇੱਕੋ ਹੋਸਟ ਪਤੇ ਨੂੰ ਕੰਪਿਊਟਰ ਦੇ ਮੌਜੂਦਾ ਨੈੱਟਵਰਕ ਮੈਨੇਜਰ ਰਾਹੀਂ ਟਿਕਾਊ ਬਣਾਓ, ਅਤੇ ਜੁੜਾਅ ਨੂੰ TAP ਡਿਵਾਈਸ ਦੇ ਦਿਸਣ ਨਾਲ ਬੰਨ੍ਹੋ ਤਾਂ ਜੋ ਦੁਬਾਰਾ ਜੁੜਨ ਤੇ ਮੈਂਬਰ ਗੁੰਮ ਹੋਇਆ ਬ੍ਰਿਜ ਨਾ ਰਹੇ।

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

ਫਿਰ ਬੋਰਡਾਂ ਨੂੰ ਦੋਵਾਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਅਸਲ ਵਿੱਚ ਕੀ ਚਾਹੀਦਾ ਹੈ ਪਰਖੋ, ਸੁਰੰਗ ਦੁਬਾਰਾ ਜੋੜੋ, ਅਤੇ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਰਿਕਵਰੀ ਯੋਜਨਾ ਤਹਿਤ ਇੱਕ ਕੰਪਿਊਟਰ ਦੁਬਾਰਾ ਚਾਲੂ ਕਰੋ। ਫਿਰ ਤਿੰਨ ਗੱਲਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ: ਪ੍ਰਬੰਧਨ ਪਹੁੰਚ ਅਜੇ ਵੀ ਸੁਤੰਤਰ ਤੌਰ ਤੇ ਕੰਮ ਕਰਦੀ ਹੈ, ਦੁਹਰਾਇਆ ਲੈਬ ਪਤਾ ਨਹੀਂ ਦਿਸਦਾ, ਅਤੇ ਕੋਈ ਅਣਕਿਆਸਿਆ ਉਤਪਾਦਨ ਇੰਟਰਫੇਸ ਬ੍ਰਿਜ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਹੋਇਆ। ਇਹੀ ਸੰਜੋਗ ਸਾਬਤ ਹੈ ਕਿ ਪ੍ਰਯੋਗ ਆਪਣੇ ਬੈਂਚ ਦੇ ਅੰਦਰ ਹੀ ਰਿਹਾ।