VPN ਸਾਥੀ ਹੋਰ ਇੰਟਰਫੇਸਾਂ ’ਤੇ ਪਿੰਗ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹ ਸਥਾਨਕ ਹਨ

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

ਇੱਕ ਮਾਰਗ ਕਿਸੇ ਹੋਰ ਲਈ ਪੈਕਟ ਫਾਰਵਰਡ ਕਰਦਾ ਹੈ; ਦੂਜਾ ਉਹਨਾਂ ਨੂੰ ਹੋਸਟ ਕੋਲ ਹੀ ਪਹੁੰਚਾਉਂਦਾ ਹੈ।

ਹੋਸਟ ਨੂੰ ਭੇਜਿਆ ਪੈਕਟ ਹੋਸਟ ਵਿੱਚ ਹੀ ਰਹਿੰਦਾ ਹੈ

ਦੂਰਸਥ ਕਲਾਇੰਟ ਹੋਸਟ ਕੋਲ ਮੌਜੂਦ ਪਤੇ ’ਤੇ IP ਪੈਕਟ ਭੇਜਦਾ ਹੈ। ਰੂਟਿੰਗ ਉਸ ਪੈਕਟ ਬਾਰੇ ਇੱਕ ਸਵਾਲ ਪੁੱਛਦੀ ਹੈ: ਕੀ ਇਹ ਮੰਜ਼ਿਲ ਸਥਾਨਕ ਹੈ? ਹੋਸਟ ਕੋਲ ਮੌਜੂਦ ਹਰ ਪਤਾ ਸਥਾਨਕ ਰੂਟਿੰਗ ਸਾਰਣੀ ਵਿੱਚ ਦਿਸਦਾ ਹੈ, ਅਤੇ ਉਹ ਸਾਰਣੀ ਮੁੱਖ ਸਾਰਣੀ ਤੋਂ ਪਹਿਲਾਂ ਵੇਖੀ ਜਾਂਦੀ ਹੈ, ਇਸ ਲਈ ਪੈਕਟ ਕਿਸੇ ਹੋਰ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਬਾਹਰ ਜਾਣ ਦੀ ਬਜਾਏ ਹੋਸਟ ਦੇ ਆਪਣੇ ਸਟੈਕ ਵਿੱਚ ਜਾਂਦਾ ਹੈ। ਜਵਾਬ ਸਥਾਨਕ ਤੌਰ ’ਤੇ ਬਣਦਾ ਹੈ, ਅਤੇ ਇਹ ਟਨਲ ਰਾਹੀਂ ਵਾਪਸ ਆਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਸਵਾਲ ਉੱਥੋਂ ਹੀ ਆਇਆ ਸੀ।

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

ip_forward ਲਾਗੂ ਕਿਉਂ ਨਹੀਂ ਹੁੰਦਾ

ਫਾਰਵਰਡਿੰਗ ਉਹਨਾਂ ਪੈਕਟਾਂ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਜਿਸ ਇੰਟਰਫੇਸ ’ਤੇ ਆਏ ਸਨ, ਉਸ ਤੋਂ ਵੱਖਰੇ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਬਾਹਰ ਜਾਣਾ ਹੁੰਦਾ ਹੈ। ਹੋਸਟ ਨੂੰ ਹੀ ਪਿੰਗ ਕਦੇ ਉਹ ਮਾਰਗ ਨਹੀਂ ਲੈਂਦੀ: ਪੈਕਟ ਸਥਾਨਕ ਤੌਰ ’ਤੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਜਵਾਬ ਸਥਾਨਕ ਤੌਰ ’ਤੇ ਬਣਦਾ ਹੈ। ਇਸ ਲਈ net.ipv4.ip_forward=0 ਸੈੱਟ ਕਰਨ ਨਾਲ ਇੱਥੇ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ, ਅਤੇ ਫਾਰਵਰਡ ਚੇਨ ਦਾ ਨਿਯਮ ਉਹ ਟ੍ਰੈਫਿਕ ਕਦੇ ਨਹੀਂ ਵੇਖਦਾ। ਸਹੀ ਨਿਯੰਤਰਣ ਇਨਪੁਟ ਮਾਰਗ ’ਤੇ ਹੈ, ਆਉਣ ਵਾਲੇ ਇੰਟਰਫੇਸ ਜਾਂ ਸਰੋਤ ਦੁਆਰਾ ਸੀਮਤ।

ਇਸ ਲਈ ਫਾਰਵਰਡਿੰਗ ਬੰਦ ਕਰਨਾ ਅਤੇ ਹੋਸਟ ਨੂੰ ਵੱਖਰਾ ਮੰਨਣਾ ਸੁਰੱਖਿਆ ਦੀ ਝੂਠੀ ਭਾਵਨਾ ਪੈਦਾ ਕਰਦਾ ਹੈ।

ਫੈਸਲਾ ਕਰਨ ਵਾਲੀ ਸਥਾਨਕ ਸਾਰਣੀ ਪੜ੍ਹੋ

ip rule show ਆਮ ਤੌਰ ’ਤੇ ਜ਼ੀਰੋ ਤਰਜੀਹ ਵਾਲਾ ਨਿਯਮ ਦੱਸਦਾ ਹੈ ਜੋ ਸਾਰੀਆਂ ਖੋਜਾਂ ਪਹਿਲਾਂ ਸਥਾਨਕ ਸਾਰਣੀ ਵਿੱਚ ਭੇਜਦਾ ਹੈ, ਅਤੇ ip route show table local ਹੋਸਟ ਦੇ ਆਪਣੇ ਪਤਿਆਂ ਨੂੰ ਸਥਾਨਕ ਦਾਇਰੇ ਨਾਲ ਸੂਚੀਬੱਧ ਕਰਦਾ ਹੈ। ਉਸ ਸਾਰਣੀ ਵਿੱਚ ਪ੍ਰਸ਼ਾਸਨਿਕ ਤੌਰ ’ਤੇ ਬੰਦ ਪਰ ਅਜੇ ਵੀ ਸੰਰਚਿਤ ਇੰਟਰਫੇਸਾਂ ਦੇ ਪਤੇ ਵੀ ਸ਼ਾਮਲ ਹਨ। ਸਥਿਰ ਤੌਰ ’ਤੇ ਦਿੱਤੇ IPv4 ਪਤੇ ਆਮ ਤੌਰ ’ਤੇ ਲਿੰਕ ਟੁੱਟਣ ’ਤੇ ਵੀ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ ਇਸੇ ਕਰਕੇ ਬੰਦ ਪੁਲ ’ਤੇ ਪਿੰਗ ਅਜੇ ਵੀ ਸਫਲ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ ਆਪਰੇਟਰ ਨੂੰ ਹੈਰਾਨ ਕਰ ਸਕਦੀ ਹੈ।

IPv6 ਠੀਕ ਇਸੇ ਮੁੱਦੇ ’ਤੇ ਵੱਖਰਾ ਹੈ। ਲਿੰਕ ਡਿੱਗਣ ’ਤੇ ਇਸ ਦੇ ਪਤੇ ਆਮ ਤੌਰ ’ਤੇ ਵਾਪਸ ਲਏ ਜਾਂਦੇ ਹਨ, ਜਦੋਂ ਤੱਕ keep_addr_on_down ਸੈੱਟ ਨਹੀਂ ਹੁੰਦਾ। ਇੱਕ ਨਿਯਮ ਦੋਵਾਂ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ ਇਹ ਮੰਨਣ ਦੀ ਬਜਾਏ ਪਰਿਵਾਰਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ।

ਇੱਕ ਸਾਥੀ ਅਸਲ ਵਿੱਚ ਕਿੱਥੋਂ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ

ਕਿਸੇ ਸੈਗਮੈਂਟ ’ਤੇ ਰਾਊਟਰ ਦੇ ਆਪਣੇ ਪਤੇ ਤੋਂ ਆਇਆ ਜਵਾਬ ਉਸ ਸੈਗਮੈਂਟ ਪਿੱਛੇ ਦੀਆਂ ਮਸ਼ੀਨਾਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ। ਸਾਥੀ ਇਸ ਮਾਰਗ ਰਾਹੀਂ ਦੂਜੇ ਇੰਟਰਫੇਸ ਪਿੱਛੇ ਦੇ ਹੋਸਟ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ; ਇਹ ਸਿਰਫ਼ ਉਹਨਾਂ ਪਤਿਆਂ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ ਜੋ ਰਾਊਟਰ ਆਪ ਰੱਖਦਾ ਹੈ। ਰਾਊਟਰ ਦੇ ਪਤੇ ’ਤੇ ਪਿੰਗ ਕਰਨ ਦੀ ਬਜਾਏ ਵੱਖਰੇ LAN ਹੋਸਟ ’ਤੇ ਸੇਵਾ ਦੀ ਜਾਂਚ ਕਰਨਾ ਹੀ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਫਾਰਵਰਡਿੰਗ ਦੀ ਆਗਿਆ ਹੈ ਜਾਂ ਨਹੀਂ।

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

ਉਹ ਪਤੇ ਵੀ ਜਾਂਚੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਹਟਾਉਣਾ ਚਾਹੁੰਦੇ ਸੀ। ਇੰਟਰਫੇਸ ਤੋਂ ਪਤਾ ਹਟਾਉਣਾ ਪੁਰਾਣੇ ਪਤੇ ’ਤੇ ਫਾਇਰਵਾਲ ਨਿਯਮ ਢੇਰ ਕਰਨ ਨਾਲੋਂ ਵਧੇਰੇ ਭਰੋਸੇਯੋਗ ਹੈ।