LAN ਹੋਸਟ OpenVPN ਕਲਾਇੰਟ ਦੇ ਪਤੇ ਲਈ ARP ਕਿਉਂ ਭੇਜਦਾ ਹੈ

LAN ਹੋਸਟ ਅਤੇ VPN ਕਲਾਇੰਟ ਵਿਚਕਾਰ ਪਹੁੰਚ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਅਕਸਰ ਪਤਿਆਂ ਦੀ ਯੋਜਨਾ ਵੱਲ ਹੀ ਮੁੜਦੀਆਂ ਹਨ। ਉਸ ਹੋਸਟ ਨੂੰ 10.0.100.0/22 'ਤੇ ਇੰਟਰਫ਼ੇਸ ਦਿਓ ਅਤੇ ਇਹ 10.0.100.0 ਤੋਂ 10.0.103.255 ਤੱਕ ਹਰ ਪਤੇ ਨੂੰ ਸਿੱਧਾ ਜੁੜਿਆ ਮੰਨੇਗਾ, ਜਿਸ ਵਿੱਚ 10.0.101.0/24 'ਤੇ ਚੁੱਪਚਾਪ ਰੱਖਿਆ ਕਲਾਇੰਟ ਪੂਲ ਵੀ ਸ਼ਾਮਲ ਹੈ। ਜਵਾਬ ਕਦੇ ਰਾਊਟਰ ਕੋਲ ਨਹੀਂ ਜਾਂਦਾ, ਕਿਉਂਕਿ ਹੋਸਟ ਦੇ ਨਜ਼ਰੀਏ ਤੋਂ ਕੋਈ ਰਾਊਟਰ ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦਾ। ਪੈਕੇਟ ਕਿਸੇ ਗੁਆਂਢੀ ਨੂੰ ਸੰਬੋਧਿਤ ਹੈ ਅਤੇ ਤਾਰ 'ਤੇ ਮੰਗਿਆ ਜਾਂਦਾ ਹੈ।

ਇਹ ਵਿਧੀ ਰਿਪੋਰਟਾਂ ਦੇ ਪੂਰੇ ਪਰਿਵਾਰ ਪਿੱਛੇ ਹੈ: ਟਨਲ ਚਾਲੂ ਹੈ, ਸਰਵਰ ਕੋਲ ਰੂਟ ਹੈ, ਅਤੇ LAN ਹੋਸਟ ਫਿਰ ਵੀ ਕਲਾਇੰਟ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ।

ਉਹ /22 ਜੋ /24 ਨੂੰ ਨਿਗਲ ਜਾਂਦਾ ਹੈ

ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਰੇਂਜ ਵਜੋਂ ਪੜ੍ਹੋ, ਸਟ੍ਰਿੰਗ ਵਜੋਂ ਨਹੀਂ। ਇੱਕ /22 ਵਿੱਚ 1024 ਪਤੇ ਹੁੰਦੇ ਹਨ, ਅਤੇ 10.0.100.0/22 10.0.100.0 ਤੋਂ 10.0.103.255 ਤੱਕ ਫੈਲਿਆ ਹੈ, ਇਸ ਲਈ 10.0.101.0/24 'ਤੇ ਪੂਲ ਪੂਰੀ ਤਰ੍ਹਾਂ ਇਸਦੇ ਅੰਦਰ ਹੈ। ਇਹ ਗਲਤੀ ਸਮੀਖਿਆ ਤੋਂ ਬਚ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਪੂਲ ਦੇ ਪਹਿਲੇ ਆਕਟੈਟ LAN ਦੇ ਪਹਿਲੇ ਆਕਟੈਟ ਨਾਲੋਂ ਵੱਖਰੇ ਦਿਖਦੇ ਹਨ, ਅਤੇ ਸਿਰਫ਼ ਤੀਜਾ ਆਕਟੈਟ ਇਸ ਸਮਾਵੇਸ਼ ਨੂੰ ਖੋਲ੍ਹਦਾ ਹੈ। ਦੋਵੇਂ ਰੇਂਜਾਂ ਅੰਕਾਂ ਵਿੱਚ ਲਿਖੋ, ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖਰਾ ਐਲਾਨਣ ਤੋਂ ਪਹਿਲਾਂ।

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

ਸਿੱਧੇ ਕਨੈਕਸ਼ਨ ਦਾ ਅਰਥ ARP ਹੈ, ਰਾਊਟਿੰਗ ਨਹੀਂ

/22 ਇੰਟਰਫ਼ੇਸ ਵਾਲਾ ਹੋਸਟ ਜਦੋਂ 10.0.101.25 'ਤੇ ਭੇਜਦਾ ਹੈ, ਕਰਨਲ ਮੰਜ਼ਿਲ ਦੀ ਤੁਲਨਾ ਇੰਟਰਫ਼ੇਸ ਦੇ ਪ੍ਰੀਫਿਕਸ ਨਾਲ ਕਰਦਾ ਹੈ ਅਤੇ ਮੇਲ ਲੱਭਦਾ ਹੈ। ਪੈਕੇਟ ਰਾਊਟ ਕੀਤੇ ਪੈਕੇਟ ਦੀ ਥਾਂ ਗੁਆਂਢੀ ਦੀ ਖੋਜ ਬਣ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਈਥਰਨੈੱਟ 'ਤੇ ਗੁਆਂਢੀ ਦੀ ਖੋਜ ਉਸ ਪਤੇ ਲਈ ARP ਬੇਨਤੀ ਹੈ। ਜੇ ਪਤਾ ਰਾਊਟਡ ਗੇਟਵੇ ਪਿੱਛੇ ਦੇ VPN ਕਲਾਇੰਟ ਦਾ ਹੈ, ਤਾਂ LAN 'ਤੇ ਕੋਈ ਹੋਸਟ ਇਸਦਾ ਮਾਲਕ ਨਹੀਂ, ਇਸ ਲਈ ਬੇਨਤੀ ਬਿਨਾਂ ਜਵਾਬ ਰਹਿ ਜਾਂਦੀ ਹੈ ਅਤੇ ਪੈਕੇਟ ਸੁੱਟ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ। ਟਨਲ ਦੋਸ਼ੀ ਨਹੀਂ, ਅਤੇ ਕਲਾਇੰਟ ਟ੍ਰੈਫਿਕ ਕਦੇ ਨਹੀਂ ਦੇਖਦਾ।

ਇਸ ਲਈ ਨਾਕਾਮੀ ਅਸਮਮਿਤ ਅਤੇ ਕਦੇ-ਕਦਾਈਂ ਰੁਕ-ਰੁਕ ਕੇ ਦਿਖਦੀ ਹੈ। VPN ਹੋਸਟ ਅਕਸਰ LAN ਤੱਕ ਪਹੁੰਚ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਸਦੇ ਆਪਣੇ ਰੂਟ ਸਹੀ ਦਿਸ਼ਾ ਦਰਸਾਉਂਦੇ ਹਨ, ਜਦੋਂ ਕਿ LAN ਹੋਸਟ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦਾ, ਅਤੇ ਪੁਰਾਣੀ ARP ਐਂਟਰੀ ਕੈਸ਼ ਕਰਨ ਵਾਲੀ ਕੋਈ ਵੀ ਚੀਜ਼ ਲੱਛਣ ਨੂੰ ਟਿਮਟਿਮਾਉਂਦੀ ਰੱਖਦੀ ਹੈ।

TUN, TAP ਅਤੇ ਹਰ ਇੱਕ ਕੀ ਢੋਂਦਾ ਹੈ

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

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

ਅਜਿਹਾ ਪੂਲ ਡਿਜ਼ਾਈਨ ਕਰੋ ਜੋ ਓਵਰਲੈਪ ਨਾ ਹੋ ਸਕੇ

ਹਰ ਜੁੜੇ ਪ੍ਰੀਫਿਕਸ ਅਤੇ ਹਰ ਐਲਾਨੇ ਸਾਈਟ ਪ੍ਰੀਫਿਕਸ ਤੋਂ ਬਾਹਰ ਪੂਲ ਚੁਣੋ, ਫਿਰ ਉਹ ਰੂਟ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਇਸਨੂੰ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਪਹੁੰਚਯੋਗ ਬਣਾਉਂਦੇ ਹਨ। ਯੋਜਨਾ ਦੇ ਅਣਵਰਤੇ ਹਿੱਸੇ ਵਿੱਚ 10.8.0.0/24 ਵਰਗੀ ਰੇਂਜ ਬਾਰੇ ਸੋਚਣਾ ਸੌਖਾ ਹੈ, ਅਤੇ ਜਿਸ LAN ਨੂੰ ਉੱਥੇ ਪਹੁੰਚਣਾ ਹੈ ਉਸਨੂੰ VPN ਸਰਵਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ ਸਥਿਰ ਰੂਟ ਮਿਲਦਾ ਹੈ। ਅਲਾਟਮੈਂਟ, ਐਲਾਨੇ ਰੂਟ, ਮਨਜ਼ੂਰ ਸਰੋਤ ਪਤੇ ਅਤੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਇਕੱਠੇ ਬਦਲੋ, ਕਿਉਂਕਿ ਇਹ ਚਾਰ ਸੈਟਿੰਗਾਂ ਨਹੀਂ ਸਗੋਂ ਇੱਕ ਡਿਜ਼ਾਈਨ ਦੱਸਦੇ ਹਨ।

ਸਰਵਰ 'ਤੇ Source NAT ਪੂਲ ਨੂੰ LAN ਤੋਂ ਰਾਊਟਯੋਗ ਪਤੇ ਪਿੱਛੇ ਲੁਕਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹ ਜਾਇਜ਼ ਮਾਈਗ੍ਰੇਸ਼ਨ ਸਾਧਨ ਹੈ। ਇਹ ਸਰੋਤ ਵੀ ਮੁੜ ਲਿਖਦਾ ਹੈ, ਇਸ ਲਈ LAN ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਵੱਖਰੇ ਕਲਾਇੰਟਾਂ ਨਾਲ ਜੋੜਨ ਅਤੇ ਪ੍ਰਤੀ-ਕਲਾਇੰਟ ਨਿਯਮ ਲਾਗੂ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਗੁਆ ਦਿੰਦਾ ਹੈ।

ਸਵੀਕ੍ਰਿਤੀ ਲਈ ਅਸਲ ਕਲਾਇੰਟ ਦਾ ਅਸਲ ਵੰਡਿਆ ਪਤਾ ਅਤੇ LAN ਹੋਸਟ ਤੋਂ ਅਸਲ ਐਪਲੀਕੇਸ਼ਨ ਬੇਨਤੀ ਵਰਤੋ, ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਜਵਾਬ ਤਾਰ ਦੀ ਥਾਂ ਯੋਜਨਾਬੱਧ ਗੇਟਵੇ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ।