VPN ਗੇਟਵੇ ਮੁੜ ਚਾਲੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਵੀ IPv4 ਫਾਰਵਰਡਿੰਗ ਬਣੀ ਰਹੇ

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

ਗੇਟਵੇ ਤੱਕ ਪਹੁੰਚਣਾ ਫਾਰਵਰਡਿੰਗ ਵਰਗਾ ਨਹੀਂ ਹੈ

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

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

ਮੁੱਲ ਉੱਥੇ ਪੜ੍ਹੋ ਜਿੱਥੇ ਪੈਕਟ ਅਸਲ ਵਿੱਚ ਹਨ

ਹੋਸਟ ਨੇਮਸਪੇਸ ਵਿੱਚ ਰੂਟ ਕਰਨ ਵਾਲੇ ਗੇਟਵੇ 'ਤੇ, ਇੱਕ ਹੀ ਕਮਾਂਡ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ: sysctl net.ipv4.ip_forward। ਜਦੋਂ ਇਨਗ੍ਰੈਸ ਅਤੇ ਅਗਲਾ ਰਾਹ ਨਾਮਿਤ ਨੇਮਸਪੇਸ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ, ਤਾਂ ਉਸ ਨੇਮਸਪੇਸ ਨੂੰ ਪੁੱਛੋ: ip netns exec vpn-gw sysctl net.ipv4.ip_forward। ਹੋਸਟ ਦਾ ਮੁੱਲ ਨੇਮਸਪੇਸ ਦੇ ਮੁੱਲ ਦਾ ਬਦਲ ਨਹੀਂ ਹੈ, ਅਤੇ ਹੋਸਟ 'ਤੇ ਇੱਕ ਹੋਣਾ ਕਿਸੇ ਚੀਜ਼ ਦਾ ਸਬੂਤ ਨਹੀਂ ਹੈ।

ਹਰ ਰੂਟਿੰਗ ਸੰਦਰਭ ਕੋਲ ਉਹ ਲੇਬਲ ਨਹੀਂ ਹੁੰਦਾ ਜੋ ਤੁਸੀਂ ip netns ਨੂੰ ਦੇ ਸਕੋ। ਕੰਟੇਨਰ ਰਨਟਾਈਮ ਅਤੇ ਸੇਵਾਵਾਂ ਅਜਿਹੇ ਨੇਮਸਪੇਸ ਬਣਾਉਂਦੇ ਹਨ ਜੋ ਕਦੇ ਵੀ ਦੋਸਤਾਨਾ ਨਾਮ ਹੇਠ ਦਰਜ ਨਹੀਂ ਹੁੰਦੇ, ਅਤੇ ਉਨ੍ਹਾਂ ਲਈ ਤੁਸੀਂ ਰਨਟਾਈਮ ਦੇ ਜਾਂਚ ਸਾਧਨ ਵਰਤਦੇ ਹੋ। vpn-gw ਦੀ ਥਾਂ ਅਸਲ ਨਾਮ ਜਾਂ ਉਸੇ ਸੰਦਰਭ ਤੱਕ ਪਹੁੰਚਣ ਵਾਲੀ ਰਨਟਾਈਮ ਵਿਧੀ ਰੱਖੋ, ਅਤੇ ਹੋਸਟ ਪੱਧਰ 'ਤੇ ਅੰਦਾਜ਼ਾ ਲਾਉਣਾ ਬੰਦ ਕਰੋ।

ਸੈਟਿੰਗ ਨੂੰ ਇੱਕ ਹੀ ਮਾਲਕ ਦਿਓ

ਰਵਾਇਤੀ systemd ਹੋਸਟ ਗੇਟਵੇ 'ਤੇ, ਟਿਕਾਊ ਰੂਪ ਪ੍ਰਬੰਧਕ ਵੱਲੋਂ ਚੁਣੇ ਨਾਮ ਵਾਲੀ drop-in ਫ਼ਾਈਲ ਹੈ, ਜਿਵੇਂ /etc/sysctl.d/60-vpn-forwarding.conf, ਜਿਸ ਵਿੱਚ net.ipv4.ip_forward = 1 ਹੁੰਦਾ ਹੈ। ਫ਼ਾਈਲ ਲਿਖੋ, ਫਿਰ ਉਹੀ ਖ਼ਾਸ ਫ਼ਾਈਲ ਲੋਡ ਕਰੋ ਤਾਂ ਜੋ ਜੀਵੰਤ ਸਥਿਤੀ ਵੀ ਬਦਲੇ: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, ਅਤੇ ਫਿਰ ਵਾਪਸ ਪੜ੍ਹ ਕੇ ਜਾਂਚੋ। ਫ਼ਾਈਲ ਦਾ ਨਾਮ ਉਦਾਹਰਨ ਹੈ, ਰਾਖਵਾਂ VPN ਰਾਹ ਨਹੀਂ, ਅਤੇ ਸ਼ੁਰੂਆਤੀ ਅੰਕ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਬਾਅਦ ਵਿੱਚ ਤਰਤੀਬ ਦਿੱਤੀਆਂ ਫ਼ਾਈਲਾਂ ਜਿੱਤਦੀਆਂ ਹਨ।

ਤਰਜੀਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਟਿਕਾਊਪਨ ਚੁੱਪਚਾਪ ਟੁੱਟਦਾ ਹੈ। ਵੰਡ ਦੇ ਲੋਡਰ ਅਤੇ ਆਪਣੀ drop-in ਦੋਵੇਂ ਜਾਂਚੋ, ਕਿਉਂਕਿ procps sysctl --system ਅੰਤ ਵਿੱਚ /etc/sysctl.conf ਵੀ ਪੜ੍ਹਦਾ ਹੈ, ਜਦਕਿ systemd ਦਾ sysctl.d ਕ੍ਰਮ ਬਿਲਕੁਲ ਵੱਖਰਾ ਕ੍ਰਮ ਹੈ। ਬਾਅਦ ਦੀ ਅਲਾਟਮੈਂਟ ਉਹੀ ਕੁੰਜੀ ਤੁਰੰਤ ਵਾਪਸ ਰੱਖ ਸਕਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਤੁਹਾਡੀ ਫ਼ਾਈਲ ਸਹੀ ਪਰ ਪ੍ਰਭਾਵੀ ਮੁੱਲ ਗ਼ਲਤ ਰਹਿ ਜਾਂਦਾ ਹੈ। ਉਹ ਬਹਿਸ ਜਿੱਤਣ ਲਈ ਮੌਜੂਦਾ ਪ੍ਰਬੰਧਕ ਫ਼ਾਈਲ ਨੂੰ ਮੁੜ ਨਾ ਲਿਖੋ; ਮਾਲਕ ਲੱਭੋ ਅਤੇ ਉੱਥੇ ਬਦਲੋ।

ਬੂਟ ਤੋਂ ਬਾਅਦ ਬਣਾਇਆ ਨੇਮਸਪੇਸ ਹੋਸਟ drop-in ਦੁਆਰਾ ਬਿਲਕੁਲ ਨਿਯੰਤਰਿਤ ਨਹੀਂ ਹੁੰਦਾ। ਇਸਦੀ ਸੈਟਿੰਗ ਉਸ ਚੀਜ਼ ਦੀ ਹੁੰਦੀ ਹੈ ਜੋ ਇਸਨੂੰ ਬਣਾਉਂਦੀ ਹੈ, ਭਾਵੇਂ ਉਹ ਕੰਟੇਨਰ ਰਨਟਾਈਮ ਹੋਵੇ ਜਾਂ ਨੇਮਸਪੇਸ ਦੀ ਪ੍ਰੋਵੀਜ਼ਨਿੰਗ ਯੂਨਿਟ। ਸਵਾਲ ਤੋਂ ਬਚਣ ਲਈ ਕੰਟੇਨਰ ਨੂੰ ਵਿਆਪਕ ਹੋਸਟ ਅਧਿਕਾਰ ਦੇਣਾ ਸਹੀ ਮਾਲਕ ਪਛਾਣਨ ਲਈ ਦਸ ਮਿੰਟ ਲਾਉਣ ਤੋਂ ਵੀ ਮਾੜਾ ਸੌਦਾ ਹੈ।

ਸਵਿੱਚ ਘੁਮਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸਦੀ ਕੀਮਤ ਜਾਣੋ

ip_forward ਨੁਕਸਾਨ ਰਹਿਤ ਬੂਲੀਅਨ ਨਹੀਂ ਹੈ। ਕਰਨਲ ਦਸਤਾਵੇਜ਼ ਦੱਸਦੇ ਹਨ ਕਿ ਇਸਨੂੰ ਬਦਲਣ ਨਾਲ ਕਈ ਹੋਰ IPv4 ਪੈਰਾਮੀਟਰ ਹੋਸਟ ਜਾਂ ਰਾਊਟਰ ਦੇ ਡਿਫ਼ਾਲਟ 'ਤੇ ਰੀਸੈੱਟ ਹੋ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਨਿਦਾਨ ਵਾਲਾ ਘੁਮਾਅ ਕਿਤੇ ਹੋਰ ਕੀਤੀ ਟਿਊਨਿੰਗ ਨੂੰ ਸੁੱਟ ਸਕਦਾ ਹੈ ਅਤੇ ਇਸਦਾ ਜ਼ਿਕਰ ਵੀ ਨਹੀਂ ਕਰਦਾ। ਇਸਨੂੰ ਲਾਪਰਵਾਹੀ ਨਾਲ ਚਲਾਈ ਜਾ ਸਕਣ ਵਾਲੀ ਜਾਂਚ ਨਹੀਂ, ਸਗੋਂ ਮਾੜੇ ਪ੍ਰਭਾਵਾਂ ਵਾਲੀ ਸੰਰਚਨਾ ਤਬਦੀਲੀ ਮੰਨੋ।

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

ਟਿਕਾਊਪਨ ਸਾਬਤ ਕਰੋ, ਫਿਰ ਬਾਕੀ ਰਾਹ ਜਾਂਚੋ

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

ਫਾਰਵਰਡਿੰਗ ਸਮਰਥ ਹੋਣ 'ਤੇ ਵੀ ਤਿੰਨ ਚੀਜ਼ਾਂ ਜਾਂਚਣੀਆਂ ਬਾਕੀ ਰਹਿੰਦੀਆਂ ਹਨ। ਕਲਾਇੰਟ ਨੂੰ ਮੰਜ਼ਿਲ ਤੱਕ ਰੂਟ ਚਾਹੀਦਾ ਹੈ, ਗੇਟਵੇ ਨੂੰ ਅਗਲਾ ਰੂਟ ਅਤੇ ਇਸਨੂੰ ਵਰਤਣ ਦੀ ਇਜਾਜ਼ਤ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਮੰਜ਼ਿਲ ਨੂੰ ਕਲਾਇੰਟ ਦੇ ਟਨਲ ਪਤੇ ਤੱਕ ਵਾਪਸੀ ਰਾਹ ਚਾਹੀਦਾ ਹੈ। ਨਿੱਜੀ ਰੂਟ ਕੀਤੇ LAN ਨੂੰ ਆਪਣੇ ਆਪ NAT ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ, ਇਸ ਲਈ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕੀ ਗ਼ਾਇਬ ਹੈ ਇਹ ਜਾਣਨ ਤੋਂ ਪਹਿਲਾਂ masquerading ਨਾ ਜੋੜੋ, ਅਤੇ ਗੇਟਵੇ ਤੋਂ ਨਹੀਂ ਸਗੋਂ ਲੋੜੀਂਦੇ ਕਲਾਇੰਟ ਤੋਂ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਗੇਟਵੇ 'ਤੇ ਸ਼ੁਰੂ ਹੋਈ ਬੇਨਤੀ ਤੁਹਾਡੇ ਵੱਲੋਂ ਹੁਣੇ ਸਮਰਥ ਕੀਤੇ ਫਾਰਵਰਡਿੰਗ ਰਾਹ ਨੂੰ ਕਦੇ ਨਹੀਂ ਛੂਹਦੀ। IPv6 ਦੀ ਆਪਣੀ ਫਾਰਵਰਡਿੰਗ ਅਤੇ ਰੂਟਿੰਗ ਨੀਤੀ ਹੈ, ਇਸ ਲਈ ਕੰਮ ਕਰਨ ਵਾਲੀ IPv4 ਜਾਂਚ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ।

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