ਤੁਹਾਡਾ VPN ਪੂਲ LAN ਦੀ DHCP ਰੇਂਜ ਨਹੀਂ ਹੈ: ਇਹ ਕਿਉਂ ਟੁੱਟਦਾ ਹੈ

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

ਦੋ ਵੰਡਕਰਤਾ, ਇੱਕ ਪਤਾ-ਥਾਂ

LAN ਦਾ DHCP ਸਰਵਰ ਜਾਣਦਾ ਹੈ ਕਿ ਉਸ ਨੇ ਕਿਹੜੇ ਪਤੇ ਕਿਹੜੇ MAC ਪਤੇ ਨੂੰ ਲੀਜ਼ ਉੱਤੇ ਦਿੱਤੇ ਹਨ, ਅਤੇ ARP ਨਾਲ ਉਹਨਾਂ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ। VPN ਸਰਵਰ ਦਾ ਆਪਣਾ ਪੂਲ ਹੈ ਅਤੇ ਉਹਨਾਂ ਲੀਜ਼ਾਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਜਾਣਦਾ। ਦੋਵੇਂ ਗ਼ਲਤ ਨਹੀਂ ਹਨ; ਉਹਨਾਂ ਦੀ ਕਦੇ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਜਾਣ-ਪਛਾਣ ਨਹੀਂ ਕਰਵਾਈ ਗਈ।

VPN ਸਰਵਰ ਵੱਲੋਂ LAN ਪੂਲ ਵਿੱਚੋਂ ਦਿੱਤਾ ਪਤਾ ਪਹਿਲਾਂ ਹੀ ਕਿਸੇ ਪ੍ਰਿੰਟਰ ਦਾ ਹੋ ਸਕਦਾ ਹੈ। ਹੁਣ ਦੋ ਡਿਵਾਈਸ ਇੱਕੋ ਪ੍ਰੀਫਿਕਸ ਉੱਤੇ ਇੱਕ ਪਤੇ ਦਾ ਦਾਅਵਾ ਕਰਦੇ ਹਨ, ਅਤੇ ਸਵਿੱਚ ਦੀ ਫਾਰਵਰਡਿੰਗ ਟੇਬਲ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਕੌਣ ਜਵਾਬ ਦੇਵੇਗਾ।

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

ਰਾਊਟਰ VPN ਪਤੇ ਕਿਉਂ ਨਹੀਂ ਵੰਡਦਾ

DHCP ਖੋਜ ਇੱਕ ਬ੍ਰਾਡਕਾਸਟ ਹੈ, ਅਤੇ ਬ੍ਰਾਡਕਾਸਟ ਰਾਊਟਡ ਸੀਮਾ ਉੱਤੇ ਰੁਕ ਜਾਂਦੇ ਹਨ। ਜੇ ਡਿਜ਼ਾਈਨ ਟਨਲ ਨੂੰ ਬ੍ਰਿਜ ਨਾ ਕਰੇ ਜਾਂ ਮੇਲ ਖਾਂਦੇ ਅਧਿਕਾਰ ਵਾਲਾ DHCP ਰੀਲੇ ਨਾ ਚਲਾਏ, ਤਾਂ ਕਲਾਇੰਟ ਦੀ ਬੇਨਤੀ ਕਦੇ LAN ਸਰਵਰ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦੀ।

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

ਉਹੀ ਤਰਕ ਦੱਸਦਾ ਹੈ ਕਿ DHCP ਸਕੋਪ ਬਦਲਣ ਨਾਲ ਉਹ VPN ਕਲਾਇੰਟ ਕਿਉਂ ਠੀਕ ਨਹੀਂ ਹੁੰਦਾ ਜਿਸ ਨੂੰ ਕਦੇ ਪਤਾ ਨਹੀਂ ਮਿਲਦਾ। ਕਲਾਇੰਟ LAN ਸਰਵਰ ਨੂੰ ਨਹੀਂ ਪੁੱਛ ਰਿਹਾ, ਅਤੇ ਸਕੋਪ ਦੀ ਕੋਈ ਵੀ ਸੋਧ ਉਸ ਨੂੰ ਪੁੱਛਣ ਲਈ ਮਜਬੂਰ ਨਹੀਂ ਕਰਦੀ।

ਓਵਰਲੈਪ ਹੌਲੀ ਨੈੱਟਵਰਕ ਵਜੋਂ ਨਹੀਂ, ਟਕਰਾਅ ਵਜੋਂ ਦਿਖਦਾ ਹੈ

ਸਮਰਥਿਤ ਡਿਜ਼ਾਈਨ ਤੋਂ ਬਿਨਾਂ ਇੱਕੋ ਪ੍ਰੀਫਿਕਸ ਸਾਂਝਾ ਕਰਨ ਵਾਲੇ ਦੋ ਨੈੱਟਵਰਕ ਦੋਹਰੀ ਮਾਲਕੀ ਤੋਂ ਵੱਖਰੀ ਸਮੱਸਿਆ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਅਕਸਰ ਰਲਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਜੇ VPN ਪੂਲ ਵੱਖਰਾ ਪ੍ਰੀਫਿਕਸ ਹੈ, ਤਾਂ ਓਵਰਲੈਪ ਤਦ ਹੀ ਮਾਅਨੇ ਰੱਖਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਰੂਟ ਟ੍ਰੈਫਿਕ ਨੂੰ ਗ਼ਲਤ ਪਾਸੇ ਭੇਜਦਾ ਹੈ। ਜੇ ਪੂਲ LAN ਪ੍ਰੀਫਿਕਸ ਦੇ ਅੰਦਰ ਹੈ, ਤਾਂ ਟਕਰਾਅ ਤੁਰੰਤ ਅਤੇ ਸਥਾਨਕ ਹੈ।

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

ਰਿਟਰਨ ਰਾਹ ਵੱਖਰੀ ਸਮੱਸਿਆ ਹੈ

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

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਰਾਹ ਨੂੰ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਪੜ੍ਹੋ। ਗੇਟਵੇ ਉੱਤੇ ਪੁੱਛੋ ਕਿ ਕਰਨਲ ਕਲਾਇੰਟ ਪਤੇ ਲਈ ਕਿਹੜਾ ਇੰਟਰਫੇਸ ਵਰਤੇਗਾ; ਕਲਾਇੰਟ ਉੱਤੇ ਪੁੱਛੋ ਕਿ ਇਹ LAN ਪਤੇ ਲਈ ਕਿਹੜਾ ਰੂਟ ਵਰਤਦਾ ਹੈ।

ਇਹ ਕਮਾਂਡਾਂ ਗੇਟਵੇ ਉੱਤੇ ਫਾਰਵਰਡਿੰਗ ਫੈਸਲਾ ਅਤੇ ਡੁਪਲੀਕੇਟ ਦਾ ਪਰਦਾਫਾਸ਼ ਕਰਨ ਵਾਲੀਆਂ ਗੁਆਂਢੀ ਐਂਟਰੀਆਂ ਦਿਖਾਉਂਦੀਆਂ ਹਨ:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

ਜੇ ਪਹਿਲੀ ਕਮਾਂਡ ਟਨਲ ਇੰਟਰਫੇਸ ਨਾਲ ਜਵਾਬ ਦੇਵੇ, ਤਾਂ ਰਿਟਰਨ ਰੂਟ ਮੌਜੂਦ ਹੈ। ਜੇ ਇਹ LAN ਇੰਟਰਫੇਸ ਨਾਲ ਜਵਾਬ ਦੇਵੇ, ਤਾਂ ਰਾਊਟਰ ਮੰਨਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਤਾਰ ਉੱਤੇ ਹੈ ਅਤੇ ਇਸ ਲਈ ARP ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗਾ।

ਬ੍ਰਿਜਡ ਡਿਜ਼ਾਈਨ ਮੌਜੂਦ ਹਨ, ਪਰ ਉਹਨਾਂ ਨੂੰ ਚੁਣਨਾ ਪੈਂਦਾ ਹੈ

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

ਜੋ ਕੰਮ ਨਹੀਂ ਕਰਦਾ ਉਹ ਨੰਬਰ ਕਾਪੀ ਕਰਕੇ ਨਤੀਜੇ ਦੀ ਨਕਲ ਕਰਨਾ ਹੈ। ਬ੍ਰਿਜ ਤੋਂ ਬਿਨਾਂ ਸਾਂਝਾ ਪੂਲ ਤੁਹਾਨੂੰ ਖੋਜ ਤੋਂ ਬਿਨਾਂ ਟਕਰਾਅ ਦਿੰਦਾ ਹੈ, ਜੋ ਦੋਵੇਂ ਪ੍ਰਬੰਧਾਂ ਵਿੱਚੋਂ ਸਭ ਤੋਂ ਮਾੜਾ ਹੈ।

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