ਕੀ ਤੁਹਾਨੂੰ VPN ਸਬਨੈੱਟ ਵਿੱਚ ਪੋਰਟ ਫਾਰਵਰਡ 'ਤੇ SNAT ਲਾਗੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?

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

ਜਵਾਬ ਵੱਖਰਾ ਰਾਹ ਕਿਉਂ ਲੈਂਦਾ ਹੈ

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

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

ਭਰੋਸੇ ਯੋਗ ਤੰਗ ਸਰੋਤ ਨਿਯਮ

ਰਾਊਟਰ ਨੂੰ ਉਹ ਸਰੋਤ ਬਣਾਓ ਜਿਸ ਨੂੰ ਦੂਰ ਦਾ ਹੋਸਟ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਇਸ ਬੰਦੋਬਸਤ ਵਿੱਚ WAN ਪਤਾ 203.0.113.24 ਹੈ, LAN 192.168.88.0/24 ਹੈ, ਰਾਊਟਰ ਦਾ ਟਨਲ ਪਤਾ 172.20.5.1 ਹੈ, ਅਤੇ ਸੇਵਾ 172.20.5.40:8443 'ਤੇ ਜਵਾਬ ਦਿੰਦੀ ਹੈ। ਹੇਠਾਂ ਦਿੱਤਾ ਨਿਯਮ ਮੰਜ਼ਿਲ ਅਨੁਵਾਦ ਤੋਂ ਬਾਅਦ ਦੇ ਪੈਕੇਟ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਜਨਤਕ ਦੀ ਥਾਂ ਅਨੁਵਾਦਿਤ ਪਤੇ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ। ਇਸ ਵਿੱਚ ਕੁਝ ਵੀ ਕਲਾਇੰਟ ਦੇ ਪਤੇ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਇਹੀ ਮੁੱਖ ਗੱਲ ਹੈ।

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

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

ਕਦੋਂ ਸਰਵਵਿਆਪੀ ਮਾਸਕਰੇਡ ਇਮਾਨਦਾਰ ਚੋਣ ਹੈ

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

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

ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਾਊਂਟਰ ਜਾਂਚੋ

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

iptables -t nat -L POSTROUTING -v -n --line-numbers

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