ਇੱਕੋ ਸਬਨੈੱਟ ਵਾਲੀਆਂ ਦੋ ਸਾਈਟਾਂ ਇੱਕ LAN ਕਿਉਂ ਨਹੀਂ ਹਨ

ਦੋ ਦਫ਼ਤਰ ਦੋਵੇਂ 192.168.77.0/24 ਵਰਤਦੇ ਹਨ, ਅਤੇ ਕੋਈ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ ਕਿ ਇੱਕ ਸੁਰੰਗ ਬਣਾਈ ਜਾਵੇ ਤਾਂ ਜੋ ਉਹ ਇੱਕ ਨੈੱਟਵਰਕ ਹੋਣ। ਇਹ ਵਾਕ ਸਰਲ ਲੱਗਦਾ ਹੈ ਅਤੇ ਤਿੰਨ ਵੱਖਰੇ ਡਿਜ਼ਾਈਨ ਲੁਕਾਉਂਦਾ ਹੈ: ਟਕਰਾਉਂਦੀਆਂ ਦੋ ਸੁਤੰਤਰ LAN, WAN ਉੱਤੇ ਜਾਣ-ਬੁੱਝ ਕੇ ਖਿੱਚਿਆ ਗਿਆ ਇੱਕ ਈਥਰਨੈੱਟ ਹਿੱਸਾ, ਅਤੇ ਦੂਰ ਦੇ ਪਤਿਆਂ ਲਈ ਜਵਾਬ ਦੇਣ ਵਾਲੀ proxy-ARP ਵਿਵਸਥਾ। ਤੁਹਾਡੇ ਕੋਲ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਹੈ ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਹੋਸਟ ਪੈਕਟ ਨਾਲ ਕੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਜਵਾਬ VPN ਗੇਟਵੇ ਸ਼ਾਮਲ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਦਿਸਦਾ ਹੈ।

ਹੋਸਟ ਰਾਊਟਰ ਤੋਂ ਪਹਿਲਾਂ ਫ਼ੈਸਲਾ ਕਰਦਾ ਹੈ

192.168.77.10/24 ਪਤਾ ਵਾਲਾ ਹੋਸਟ ਮੰਜ਼ਿਲ ਦੀ ਤੁਲਨਾ ਆਪਣੇ ਪ੍ਰੀਫ਼ਿਕਸ ਨਾਲ ਕਰਦਾ ਹੈ। ਉਸ ਪ੍ਰੀਫ਼ਿਕਸ ਦੇ ਅੰਦਰ ਸਭ ਕੁਝ ਸਿੱਧੇ ਲਿੰਕ ਉੱਤੇ ਹੈ, ਇਸ ਲਈ ਹੋਸਟ ਮੰਜ਼ਿਲ ਦਾ ਲਿੰਕ-ਲੇਅਰ ਪਤਾ ਸਿੱਧਾ ਹੱਲ ਕਰਦਾ ਹੈ। ਬਾਹਰ ਦਾ ਸਭ ਕੁਝ ਡਿਫ਼ਾਲਟ ਗੇਟਵੇ ਵੱਲ ਜਾਂਦਾ ਹੈ।

ਇਹ ਫ਼ੈਸਲਾ ਹੋਸਟ ਦੇ ਸਟੈਕ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਸੁਰੰਗ ਵਿੱਚ ਨਹੀਂ। ਗੇਟਵੇ ਉੱਤੇ ਜੋੜਿਆ ਰੂਟ ਉਸ ਪੈਕਟ ਨੂੰ ਨਹੀਂ ਬਚਾ ਸਕਦਾ ਜੋ ਹੋਸਟ ਕਦੇ ਉੱਥੇ ਨਹੀਂ ਭੇਜਦਾ।

ਇਸ ਲਈ ਜਦੋਂ 192.168.77.20 ਸਿਰਫ਼ ਦੂਜੀ ਸਾਈਟ ਉੱਤੇ ਹੁੰਦਾ ਹੈ, ਸਥਾਨਕ ਹੋਸਟ ਉਸ ਲਈ ARP ਕਰਦਾ ਹੈ ਅਤੇ ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਮਿਲਦਾ। VPN ਹੈਂਡਸ਼ੇਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਿਹਤਮੰਦ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਇਹ ਅਸਫਲ ਹੁੰਦਾ ਹੈ। ਇਹ ਅਸਫਲਤਾ ਰਾਊਟਿੰਗ ਸਮੱਸਿਆ ਵਾਂਗ ਨਹੀਂ, ਮਰੇ ਹੋਸਟ ਵਾਂਗ ਦਿਸਦੀ ਹੈ। ਇਹ ਨਿਸ਼ਾਨ ਪਛਾਣਨਾ ਸੁਰੰਗ ਡੀਬੱਗਿੰਗ ਦਾ ਇੱਕ ਘੰਟਾ ਬਚਾਉਂਦਾ ਹੈ।

ARP ਸਥਾਨਕ ਲਿੰਕ ਦਾ ਸਵਾਲ ਹੈ

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

ਇੱਕੋ ਪਤੇ ਵਾਲੇ ਦੋ ਯੰਤਰ ਸਥਿਤੀ ਨੂੰ ਹੋਰ ਖਰਾਬ ਕਰਦੇ ਹਨ: ਸਫਲ ਹੱਲ ਵੀ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਕਿ ਕਿਸ ਨੇ ਜਵਾਬ ਦਿੱਤਾ।

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

ਖਿੱਚਿਆ ਹੋਇਆ ਹਿੱਸਾ ਫ਼ਰੇਮ ਢੋਂਦਾ ਹੈ, ਰੂਟ ਨਹੀਂ

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

ਇੱਥੇ ਦੂਰ ਦਾ ਗੇਟਵੇ ਦੋ ਇੱਕੋ ਜਿਹੇ ਸਬਨੈੱਟਾਂ ਵਿਚਕਾਰ ਬਿਲਕੁਲ ਰਾਊਟਿੰਗ ਨਹੀਂ ਕਰਦਾ। ਫ਼ਰੇਮ ਸਵੈ-ਰਾਊਟਿੰਗ IP ਵਾਲੀ ਹੇਠਲੀ ਪਰਤ ਵਿੱਚੋਂ ਲੰਘਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਪੁਲ ਈਥਰਨੈੱਟ ਗੱਲਬਾਤ ਲੰਮੀ ਕਰਦੇ ਹਨ।

ਕੀਮਤ ਵੱਡਾ ਪ੍ਰਭਾਵ ਘੇਰਾ ਹੈ। ਅਣਜਾਣ ਮੰਜ਼ਿਲਾਂ ਵੱਲ ਹੜ੍ਹ, ਲੂਪ, DHCP ਵੰਡ ਅਤੇ ਵਿਲੱਖਣ ਪਤਾ—ਸਭ ਲਈ ਦੋਵੇਂ ਸਾਈਟਾਂ ਨੂੰ ਕਵਰ ਕਰਨ ਵਾਲੀ ਇੱਕ ਯੋਜਨਾ ਚਾਹੀਦੀ ਹੈ। WAN ਡਿੱਗਣ ’ਤੇ ਹੋਸਟ ਉਹ ਟ੍ਰੈਫ਼ਿਕ ਗੁਆ ਦਿੰਦੇ ਹਨ ਜਿਸ ਨੂੰ ਉਹ ਸਥਾਨਕ ਸਮਝਦੇ ਹਨ। ਪੁਲ ਉੱਤੇ ਫ਼ਿਲਟਰਿੰਗ ਅਤੇ VLAN ਨਿਯਮ ਸੀਮਤ ਕਰ ਸਕਦੇ ਹਨ ਕਿ ਕੀ ਲੰਘਦਾ ਹੈ, ਪਰ ਢੋਆਈ ਅਜੇ ਵੀ ਵਾਅਦਾ ਨਹੀਂ ਕਰਦੀ ਕਿ ਹਰ ਸਥਾਨਕ ਨਿਯੰਤਰਣ ਫ਼ਰੇਮ ਪਹੁੰਚੇਗਾ।

Proxy ARP ਤੀਜਾ ਡਿਜ਼ਾਈਨ ਹੈ

ਰਾਊਟਰ ਦੂਰ ਦੇ ਪਤੇ ਲਈ ARP ਦਾ ਜਵਾਬ ਦੇ ਕੇ ਫਿਰ ਉੱਧਰ ਰਾਊਟ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਪ੍ਰਸਾਰਣ ਡੋਮੇਨ ਖਿੱਚੇ ਬਿਨਾਂ ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਦੂਰ ਦਾ ਹੋਸਟ ਸਿੱਧੇ ਲਿੰਕ ਉੱਤੇ ਦਿਖਾਉਂਦਾ ਹੈ।

ਇਹ ਪੁਲ ਬਣਾਉਣ ਨਾਲੋਂ ਤੰਗ ਸਾਧਨ ਹੈ: ਇਹ ਅੱਗੇ ਭੇਜਣ, ਵਾਪਸੀ ਰੂਟ ਅਤੇ ਹਰ ਪਤੇ ਦੇ ਸਪਸ਼ਟ ਮਾਲਕ ’ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

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

ਲੋੜ ਤੋਂ ਚੁਣੋ, ਫਿਰ ਜਾਂਚੋ

ਦਫ਼ਤਰਾਂ ਵਿਚਕਾਰ ਆਮ ਐਪਲੀਕੇਸ਼ਨ ਪਹੁੰਚ ਲਈ ਵੱਖਰੇ ਪ੍ਰੀਫ਼ਿਕਸ ਅਤੇ ਸਪਸ਼ਟ ਰੂਟ ਸਾਫ਼ ਹੱਦ ਦਿੰਦੇ ਹਨ। ਜਦੋਂ ਲੋੜ ਸੱਚਮੁੱਚ ਲਿੰਕ-ਲੇਅਰ ਨੇੜਤਾ ਹੋਵੇ ਤਾਂ ਪੁਲ ਬਣਾਓ। ਜਦੋਂ ਸਾਂਝੇ ਪ੍ਰੀਫ਼ਿਕਸ ਦਾ ਇੱਕੋ ਕਾਰਨ ਇਹ ਹੋਵੇ ਕਿ ਕਿਸੇ ਨੇ ਅਜੇ ਨਹੀਂ ਕੀਤਾ, ਤਾਂ ਮੁੜ-ਸੰਖਿਆ ਕਰੋ।

ਪੱਕਾ ਕਰੋ ਕਿ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਡਿਜ਼ਾਈਨ ਤੁਹਾਡੇ ਕੋਲ ਹੈ ਹੋਸਟ ਨੂੰ ਪੁੱਛ ਕੇ ਕਿ ਉਹ ਮੰਜ਼ਿਲ ਨਾਲ ਕੀ ਕਰਦਾ ਹੈ:

ip route get 192.168.77.20
ip neigh show 192.168.77.20

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