VPN ਰਾਹੀਂ DHCP: ਬਰਾਡਕਾਸਟ ਨੂੰ ਪੁਲ ਬਣਾਈਏ ਜਾਂ ਰੀਲੇ ਕਰੀਏ?

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

ਦੋ ਡਿਜ਼ਾਈਨ ਇਸਨੂੰ ਬਦਲ ਸਕਦੇ ਹਨ, ਅਤੇ ਉਹ ਬਰਾਬਰ ਨਹੀਂ ਹਨ। ਇੱਕ ਬਰਾਡਕਾਸਟ ਲੈ ਜਾਂਦਾ ਹੈ; ਦੂਜਾ ਬੇਨਤੀ ਰੀਲੇ ਕਰਦਾ ਹੈ।

ਬਰਾਡਕਾਸਟ ਕਦੇ ਰਾਊਟਰ ਨੂੰ ਪਾਰ ਨਹੀਂ ਕਰਦਾ

ਬਿਨਾਂ ਪਤੇ ਵਾਲਾ DHCPv4 ਕਲਾਇੰਟ 0.0.0.0 ਤੋਂ ਸੀਮਤ ਬਰਾਡਕਾਸਟ ਪਤੇ ’ਤੇ UDP ਪੋਰਟ 67 ਅਤੇ 68 ’ਤੇ ਭੇਜਦਾ ਹੈ। ਉਹ ਪੈਕੇਟ ਡਿਜ਼ਾਈਨ ਅਨੁਸਾਰ ਆਪਣੀ ਲਿੰਕ ’ਤੇ ਹੀ ਰਹਿੰਦਾ ਹੈ। ਜੋ ਰਾਊਟਰ ਇਸਨੂੰ ਅੱਗੇ ਭੇਜਦਾ, ਉਹ ਆਪਣੀ ਸੇਵਾ ਵਾਲੇ ਹਰ ਹਿੱਸੇ ਵਿੱਚ ਹੜ੍ਹ ਲਿਆਉਂਦਾ।

ਇਸ ਲਈ ਰੂਟ ਕੀਤੀ ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ ਸੁਰੰਗ ਰੀਲੇ ਨੂੰ ਸਰਵਰ ਨਾਲ ਜੋੜਦੀ ਹੈ। ਇਹ ਕਲਾਇੰਟ ਦੇ ਬਰਾਡਕਾਸਟ ਡੋਮੇਨ ਨੂੰ ਨਹੀਂ ਵਧਾਉਂਦੀ, ਅਤੇ ਕੋਈ ਫਾਇਰਵਾਲ ਨਿਯਮ ਇਸਨੂੰ ਅਜਿਹਾ ਨਹੀਂ ਕਰਾ ਸਕੇਗਾ।

ਪੁਲ ਬਣਾਈ ਸੁਰੰਗ ਅਸਲ ਵਿੱਚ ਕੀ ਵਧਾਉਂਦੀ ਹੈ

ਜਾਣ-ਬੁੱਝ ਕੇ ਪੁਲ ਬਣਾਈ VPN ਆਪਣੀ ਸਮਰਥਿਤ ਟੋਪੋਲੋਜੀ ਵਿੱਚ Ethernet ਬਰਾਡਕਾਸਟ ਲੈ ਜਾ ਸਕਦੀ ਹੈ, ਅਤੇ ਫਿਰ DHCP ਸਥਾਨਕ ਟ੍ਰੈਫਿਕ ਵਜੋਂ ਲੰਘ ਸਕਦਾ ਹੈ। ਇਹ ਅਸਲੀ ਵਿਕਲਪ ਹੈ, ਪਰ ਇਹ 2 ਪਰਤ ਦਾ ਡਿਜ਼ਾਈਨ ਫੈਸਲਾ ਹੈ। ਤੁਸੀਂ ਬਰਾਡਕਾਸਟ ਨਾਲ ਨਾਲ ਫੇਲ੍ਹ ਹੋਣ ਦਾ ਖੇਤਰ ਅਤੇ ਪਹੁੰਚ ਸੀਮਾ ਵੀ ਵਧਾ ਰਹੇ ਹੋ।

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

ਇਹ ਪਤਾ ਦੇਣ ਨਾਲੋਂ ਵੱਡਾ ਫੈਸਲਾ ਹੈ, ਅਤੇ ਇਹ ਜਾਣ-ਬੁੱਝ ਕੇ ਲਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਇਸ ਦੀ ਬਜਾਏ ਬੇਨਤੀ ਰੀਲੇ ਕਰੋ

ਆਮ ਜਵਾਬ ਕਲਾਇੰਟ ਦੇ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ’ਤੇ ਇੱਕ ਰੀਲੇ ਹੈ। ਇਹ ਬਰਾਡਕਾਸਟ ਲੈਂਦਾ ਹੈ, ਇਸਨੂੰ unicast ਬੇਨਤੀ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਆਪਣਾ ਪਤਾ ਗੇਟਵੇ-ਪਤਾ ਖੇਤਰ ਵਿੱਚ ਰੱਖਦਾ ਹੈ। ਸਰਵਰ ਉਸ ਰੀਲੇ ਪਤੇ ’ਤੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।

ਉਦਾਹਰਨ ਵਜੋਂ ਦੂਰ ਦਫ਼ਤਰ ਲਈ, ਰੀਲੇ ਦਫ਼ਤਰ ਦੇ LAN ’ਤੇ ਬੈਠਦਾ ਹੈ ਅਤੇ ਸਰਵਰ ਤੱਕ ਸਾਈਟ VPN ਰਾਹੀਂ ਪਹੁੰਚਿਆ ਜਾਂਦਾ ਹੈ। ਉਸ ਦਫ਼ਤਰ ਲਈ ਸਕੋਪ, ਰੀਲੇ ਅਤੇ ਸਰਵਰ ਦੀ ਪਛਾਣ, ਅਤੇ ਪੂਰਾ ਵਾਪਸੀ ਰਾਹ ਸੰਰਚਿਤ ਕਰੋ। ਸੁਰੰਗ ਰਾਹੀਂ UDP 67 ਦੀ ਆਗਿਆ ਦੇਣਾ ਸਰਵਰ ਨੂੰ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਕਿਹੜਾ ਪੂਲ ਵਰਤਣਾ ਹੈ।

ਅੱਗੇ ਭੇਜਣ ਵਾਲਾ ਪਰ ਕਦੇ ਜਵਾਬ ਨਾ ਲੈਣ ਵਾਲਾ ਰੀਲੇ ਆਮ ਤੌਰ ’ਤੇ ਵਾਪਸੀ ਰਾਹ ਦੀ ਸਮੱਸਿਆ ਹੈ। ਸਕੋਪ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਰੀਲੇ ਪਤੇ ਵੱਲ ਵਾਪਸੀ ਰਾਹ ਜਾਂਚੋ।

DHCP ਨੂੰ ARP ਤੋਂ ਅਤੇ ਸੁਰੰਗ ਦੇ ਪਤਿਆਂ ਤੋਂ ਵੱਖ ਰੱਖੋ

DHCP UDP/IP ਉੱਤੇ ਚੱਲਦਾ ਹੈ। Ethernet ’ਤੇ, ਹੋਸਟ ARP ਵਰਤ ਕੇ ਵੀ ਜਾਂਚ ਸਕਦਾ ਹੈ ਕਿ ਉਮੀਦਵਾਰ ਪਤਾ ਪਹਿਲਾਂ ਹੀ ਵਰਤੋਂ ਵਿੱਚ ਹੈ ਜਾਂ ਨਹੀਂ। ਉਹ ਟਕਰਾਅ-ਜਾਂਚ ਇੱਕ ਵੱਖਰੀ ਲਿੰਕ-ਸਥਾਨਕ ਕਿਰਿਆ ਹੈ, DHCP ਸੁਨੇਹਿਆਂ ਦੀ ਢੋਆ-ਢੁਆਈ ਨਹੀਂ। DHCP ਮੂਲ ਰੂਪ ਵਿੱਚ ARP ਹੈ, ਇਹ ਕਹਿਣਾ ਗ਼ਲਤ ਹੈ; ਦੋਵਾਂ ਦਾ ਕਦੇ ਸੰਬੰਧ ਨਹੀਂ, ਇਹ ਕਹਿਣਾ ਬਹੁਤ ਵਿਆਪਕ ਹੈ।

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

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