ਟਨਲ ਚਾਲੂ ਹੈ, ਇੰਟਰਨੈੱਟ ਨਹੀਂ: ਫ਼ਾਰਵਰਡਿੰਗ ਕਿੱਥੇ ਰੁਕਦੀ ਹੈ

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

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਇੰਟਰਨੈੱਟ ਨਿਕਾਸ ਕਦੇ ਡਿਜ਼ਾਈਨ ਸੀ ਜਾਂ ਨਹੀਂ

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

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

ਇੱਕ ਜਨਤਕ ਬੇਨਤੀ ਨੂੰ ਲੰਘਾਓ

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

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

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

ਫ਼ਾਰਵਰਡਿੰਗ, ਰੂਟ ਅਤੇ ਅਨੁਵਾਦ ਜਾਂਚੋ

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

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

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

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

ਜਵਾਬ ਦਾ ਰਾਹ ਅਤੇ ਰਿਜ਼ੌਲਵਰ ਦੋ ਵੱਖਰੇ ਜਵਾਬ ਹਨ

ਸਿਰਫ਼ ਬੇਨਤੀ ਨਹੀਂ, ਜਵਾਬ 'ਤੇ ਵੀ ਨਜ਼ਰ ਰੱਖੋ। ਜੇ ਬੇਨਤੀ ਅਨੁਵਾਦ ਹੋ ਕੇ ਨਿਕਲਦੀ ਹੈ ਅਤੇ ਜਵਾਬ ਅਨੁਵਾਦਿਤ ਪ੍ਰਵਾਹ ਵਿੱਚ ਵਾਪਸ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਫ਼ਾਰਵਰਡਿੰਗ ਕੰਮ ਕਰਦੀ ਹੈ ਭਾਵੇਂ ਐਪ ਅਜੇ ਵੀ ਫੇਲ੍ਹ ਹੋਵੇ, ਅਤੇ ਅਗਲੀ ਜਾਂਚ ਐਪ ਜਾਂ DNS ਦੀ ਹੈ।

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

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