net.ipv4.conf.default.forwarding tun0 ਨੂੰ ਕਿਉਂ ਨਹੀਂ ਛੂਹਦਾ

ਤੁਸੀਂ net.ipv4.conf.default.forwarding=1 ਸੈੱਟ ਕੀਤਾ, VPN ਦੁਬਾਰਾ ਚਲਾਇਆ, ਅਤੇ ਟਨਲ ਅਜੇ ਵੀ ਉਹ ਪੈਕਟ ਸੁੱਟ ਰਹੀ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਗੇਟਵੇ ਨੂੰ ਰੂਟ ਕਰਨਾ ਚਾਹੀਦਾ ਸੀ। ਫ਼ਾਈਲ ਵਿੱਚ ਸੈਟਿੰਗ ਠੀਕ ਦਿਖਦੀ ਹੈ, ਅਤੇ ਇੰਟਰਫ਼ੇਸ ਅਜੇ ਵੀ ਦੱਸਦਾ ਹੈ ਕਿ ਫ਼ਾਰਵਰਡਿੰਗ ਬੰਦ ਹੈ। ਕੁਝ ਵੀ ਟੁੱਟਿਆ ਨਹੀਂ: ਤੁਸੀਂ ਉਹ ਮੁੱਲ ਬਦਲਿਆ ਜੋ ਭਵਿੱਖ ਦੇ ਇੰਟਰਫ਼ੇਸ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਣਗੇ, ਉਹ ਨਹੀਂ ਜੋ ਜੀਵਤ ਟਨਲ ਵਰਤ ਰਹੀ ਹੈ।

ਇਹ ਉਸ ਹੋਸਟ 'ਤੇ ਵੇਖੋ ਜੋ ਟਨਲ ਦਾ ਮਾਲਕ ਹੈ, ਉਸ ਨੈੱਟਵਰਕ namespace ਵਿੱਚ ਜਿੱਥੇ ਟਨਲ ਅਸਲ ਵਿੱਚ ਮੌਜੂਦ ਹੈ। ਕੋਈ ਕੰਟੇਨਰ ਜਾਂ ਨੈੱਟਵਰਕ namespace ਇੰਟਰਫ਼ੇਸ ਰੱਖ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਹੋਸਟ ਹੋਰ ਸੰਖਿਆਵਾਂ ਦਿਖਾਉਂਦਾ ਹੈ।

ਤਿੰਨੇ ਮੁੱਲ ਇਕੱਠੇ ਪੜ੍ਹੋ

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

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

ਆਮ ਨਤੀਜਾ ਇਹ ਹੁੰਦਾ ਹੈ: ip_forward = 0, default.forwarding = 1 ਅਤੇ tun0.forwarding = 0। ਪਹਿਲੇ ਦੋ ਹੋਸਟ ਦੀ ਭੂਮਿਕਾ ਬਾਰੇ ਸਹਿਮਤ ਨਹੀਂ ਹਨ, ਅਤੇ ਤੀਜਾ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਇੰਟਰਫ਼ੇਸ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰ ਰਿਹਾ ਹੈ। ਇਹ ਸੁਮੇਲ ਅਜਿਹੇ ਹੋਸਟ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਜੋ ਕਦੇ ਰਾਊਟਰ ਵਜੋਂ ਕਨਫ਼ਿਗਰ ਨਹੀਂ ਹੋਇਆ, ਸਿਰਫ਼ ਟੈਂਪਲੇਟ ਮੁੱਲ ਮਿਲਿਆ। ਤਿੰਨੇ ਸੰਖਿਆਵਾਂ ਇੱਕ-ਦੂਜੇ ਦੇ ਵਿਰੁੱਧ ਨਹੀਂ ਹਨ; ਉਹ ਤਿੰਨ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੀਆਂ ਹਨ। ਟੈਂਪਲੇਟ ਮੁੱਲ ਲਿਖਣਾ ਵੀ ਹੋਸਟ ਦੀ ਭੂਮਿਕਾ ਤੈਅ ਨਹੀਂ ਕਰਦਾ।

ਕਿਉਂ ਗਲੋਬਲ ਸਵਿੱਚ ਹੀ ਹਿਲਦਾ ਹੈ

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

ਕਰਨਲ ਦਸਤਾਵੇਜ਼ ip_forward ਨੂੰ ਸੰਬੰਧਿਤ ਕਾਰਨ ਕਰਕੇ ਖ਼ਾਸ ਦੱਸਦੇ ਹਨ: ਇਸਨੂੰ ਬਦਲਣ ਨਾਲ ਹੋਰ ਕਈ IPv4 ਪੈਰਾਮੀਟਰ ਹੋਸਟ ਜਾਂ ਰਾਊਟਰ ਡਿਫ਼ਾਲਟ 'ਤੇ ਰੀਸੈੱਟ ਹੋ ਜਾਂਦੇ ਹਨ। ਇਹ ਇਸਨੂੰ ਇੱਕ ਭੁਜੰਗੀ ਔਜ਼ਾਰ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਗੇਟਵੇ ਭੂਮਿਕਾ ਸਥਾਪਿਤ ਕਰਨ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਇਸਨੂੰ ਇੱਕ ਵਾਰ ਸੈੱਟ ਕਰਨਾ ਠੀਕ ਹੈ; ਡੀਬੱਗਿੰਗ ਦੀ ਚਾਲ ਵਜੋਂ ਵਾਰ-ਵਾਰ ਟੌਗਲ ਕਰਨਾ ਉਸ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਨੂੰ ਚੁੱਪਚਾਪ ਦੁਬਾਰਾ ਲਿਖ ਸਕਦਾ ਹੈ ਜਿਸਨੂੰ ਠੀਕ ਕਰਨ ਵਿੱਚ ਤੁਸੀਂ ਸਮਾਂ ਲਾਇਆ।

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

ਸੈਟਿੰਗ ਨੂੰ ਸਹੀ ਥਾਂ 'ਤੇ ਸਥਾਈ ਬਣਾਓ

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

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

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

ਇਸਨੂੰ ਗ਼ਲਤ ਔਜ਼ਾਰ ਨਾਲ ਠੀਕ ਨਾ ਕਰੋ

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

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

IPv6 ਕੇਸ ਨੂੰ ਵੱਖਰਾ ਰੱਖੋ

ਇੱਥੇ ਸਭ ਕੁਝ IPv4 ਹੈ। IPv6 ਫ਼ਾਰਵਰਡਿੰਗ, ਰਾਊਟਰ ਐਲਾਨ ਅਤੇ accept_ra ਵਿਵਹਾਰ ਦੇ ਆਪਣੇ ਨਿਯੰਤਰਣ ਹਨ, ਅਤੇ ipv4 ਮਾਰਗ ਨੂੰ ipv6 ਸੈਟਿੰਗ ਵਿੱਚ ਕਾਪੀ ਕਰਨ ਨਾਲ ਅਜਿਹੀ ਫ਼ਾਈਲ ਬਣਦੀ ਹੈ ਜੋ ਭਰੋਸੇਯੋਗ ਦਿਖਦੀ ਹੈ ਪਰ ਲਾਹੇਵੰਦ ਕੁਝ ਨਹੀਂ ਕਰਦੀ। ਦੋਹਰੇ-ਸਟੈਕ ਗੇਟਵੇ ਨੂੰ ਦੋਵੇਂ ਸੈੱਟ ਜਾਣ-ਬੁੱਝ ਕੇ ਕਨਫ਼ਿਗਰ ਕਰਨੇ ਪੈਂਦੇ ਹਨ।

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