CGNAT ਦੇ ਪਿੱਛਿਓਂ VPN ਕਲਾਇੰਟ ਪੋਰਟ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ: ਚੈੱਕਲਿਸਟ

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

ਪੱਕਾ ਕਰੋ ਕਿ ਸਰਵਰ ਬਿਲਕੁਲ ਫਾਰਵਰਡ ਕਰੇਗਾ

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

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1

ਚੱਲ ਰਹੇ ਕਰਨਲ ਵਿੱਚ ਇਸਨੂੰ ਸੈੱਟ ਕਰਨਾ ਰੀਬੂਟ ਦੌਰਾਨ ਸੈੱਟ ਕਰਨ ਦੇ ਬਰਾਬਰ ਨਹੀਂ ਹੈ। net.ipv4.ip_forward=1 ਨੂੰ /etc/sysctl.d/ ਹੇਠਾਂ ਫਾਈਲ ਵਿੱਚ ਲਿਖੋ, sysctl --system ਚਲਾਓ, ਅਤੇ ਫਿਰ ਫਾਈਲ ਚੁੱਕੀ ਗਈ ਹੋਣ ਦਾ ਭਰੋਸਾ ਕਰਨ ਦੀ ਬਜਾਏ ਮੁੱਲ ਦੁਬਾਰਾ ਪੜ੍ਹੋ। ਜੋ ਕੰਟੇਨਰ ਆਪਣਾ ਨੈੱਟਵਰਕ ਨਾਮਸਥਾਨ ਸੰਭਾਲਦਾ ਹੈ, ਉਸਨੂੰ ਉਸੇ ਨਾਮਸਥਾਨ ਦੇ ਅੰਦਰ ਵੀ ਉਹੀ ਮੁੱਲ ਚਾਹੀਦਾ ਹੈ, ਸਿਰਫ਼ ਹੋਸਟ ਉੱਤੇ ਨਹੀਂ।

ਜੇ ਦੁਬਾਰਾ ਪੜ੍ਹਨ ਉੱਤੇ ਵੀ ਸਿਫ਼ਰ ਹੈ, ਤਾਂ ਇੱਥੇ ਹੀ ਰੁਕੋ। ਹੇਠਾਂ ਕੁਝ ਵੀ ਕੰਮ ਨਹੀਂ ਕਰੇਗਾ।

ਕੋਈ ਵੀ ਨਿਯਮ ਇਸਦਾ ਜ਼ਿਕਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਟਨਲ ਦਾ ਪਤਾ ਥਿਰ ਕਰੋ

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

client-config-dir /etc/openvpn/ccd
ifconfig-push 10.77.0.14 10.77.0.13

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

ਜੇ ਦੁਬਾਰਾ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਪਤਾ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਰੁਕੋ। ਚੱਲਦੇ ਟਾਰਗੇਟ ਦਾ ਪਿੱਛਾ ਕਰਨ ਵਾਲਾ NAT ਨਿਯਮ ਵਿਚਕਾਰ ਵਿਚਕਾਰ ਫੇਲ੍ਹ ਹੋਵੇਗਾ ਅਤੇ ਤੁਹਾਨੂੰ ਕੁਝ ਨਹੀਂ ਸਿਖਾਏਗਾ।

ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰੋ

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

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 29443 -j DNAT --to-destination 10.77.0.14:29443
iptables -t nat -A POSTROUTING -d 10.77.0.14 -p tcp --dport 29443 -j SNAT --to-source 10.77.0.13

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

ਦੋਵੇਂ ਨਿਯਮ iptables -t nat -S ਨਾਲ ਦੁਬਾਰਾ ਪੜ੍ਹੋ ਅਤੇ ਪੱਕਾ ਕਰੋ ਕਿ ਇੰਟਰਫ਼ੇਸ ਦਾ ਨਾਮ ਉਹੀ ਹੈ ਜੋ ਜਨਤਕ ਪਤਾ ਰੱਖਦਾ ਹੈ। ਜਿਸ ਹੋਸਟ ਉੱਤੇ ਪਹਿਲਾਂ ਹੀ nftables ਨਾਲ ਫਿਲਟਰ ਹੁੰਦਾ ਹੈ, ਉੱਥੇ ਸਾਧਨ ਮਿਲਾਉਣ ਦੀ ਬਜਾਏ ਮੇਲ ਖਾਂਦੇ ਪਤਾ ਪਰਿਵਾਰ ਦੀ nftables NAT ਚੇਨ ਵਿੱਚ ਅਨੁਵਾਦ ਲਿਖੋ।

ਫਿਲਟਰ ਸਾਰਣੀ ਨੂੰ ਲੰਘਣ ਦਿਓ

NAT ਸਾਰਣੀਆਂ ਹੈਡਰ ਦੁਬਾਰਾ ਲਿਖਦੀਆਂ ਹਨ; ਉਹ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦੀਆਂ। ਡਿਫ਼ਾਲਟ DROP ਨੀਤੀ ਨਾਲ ਫਾਰਵਰਡ ਹੋਣ ਵਾਲੇ ਪ੍ਰਵਾਹ ਨੂੰ ਆਪਣੀ ਮਨਜ਼ੂਰੀ ਚਾਹੀਦੀ ਹੈ, ਨਾਲ ਹੀ ਵਾਪਸੀ ਦਿਸ਼ਾ ਜੋ ਜ਼ਿਆਦਾਤਰ ਨੀਤੀਆਂ ਪਹਿਲਾਂ ਹੀ established,related ਨਿਯਮ ਨਾਲ ਢਕਦੀਆਂ ਹਨ।

iptables -A FORWARD -i eth0 -o tun0 -p tcp --dport 29443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

ਕੁਝ ਵੀ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ FORWARD ਚੇਨ ਦੀ ਨੀਤੀ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਜਲਦੀ ਆਉਣ ਵਾਲੇ DROP ਦਾ ਕ੍ਰਮ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਡਾ ਨਿਯਮ ਕਦੇ ਵੇਖਿਆ ਜਾਵੇਗਾ ਜਾਂ ਨਹੀਂ। ਜਿਸ ਹੋਸਟ ਦੀ ਫਿਲਟਰਿੰਗ nftables ਵਿੱਚ ਰਹਿੰਦੀ ਹੈ, ਉੱਥੇ inet ਸਾਰਣੀ ਦੇ forward ਹੁੱਕ ਵਿੱਚ ਬਰਾਬਰ ਦਾ ਨਿਯਮ ਜੋੜੋ ਅਤੇ ਪੱਕਾ ਕਰੋ ਕਿ ਅਧਾਰ ਚੇਨ ਸਿਰਫ਼ ਸਥਾਨਕ ਇਨਪੁੱਟ ਨਹੀਂ, ਸਗੋਂ ਸੱਚਮੁੱਚ ਫਾਰਵਰਡ ਹੋਣ ਵਾਲਾ ਟਰੈਫ਼ਿਕ ਦੇਖਦੀ ਹੈ। ਜੇ ਨਵੇਂ ਨਿਯਮ ਉੱਤੇ ਪੈਕਟ ਕਾਊਂਟਰ ਸਿਫ਼ਰ ਰਹੇ ਅਤੇ NAT ਕਾਊਂਟਰ ਵਧਣ, ਤਾਂ ਪੈਕਟ ਤੁਹਾਡੇ ਨਿਯਮ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਸੁੱਟਿਆ ਜਾ ਰਿਹਾ ਹੈ। ਇਹ ਚੇਨਾਂ ਦਾ ਕ੍ਰਮ ਪੜ੍ਹਨ ਦਾ ਸੰਕੇਤ ਹੈ, ਉਸੇ ਨਿਯਮ ਦੀ ਦੂਜੀ ਕਾਪੀ ਜੋੜਨ ਦਾ ਨਹੀਂ।

ਇਸਨੂੰ ਬਾਹਰੀ ਨੈੱਟਵਰਕ ਤੋਂ ਸਾਬਤ ਕਰੋ

ਗੈਰ-ਸੰਬੰਧਿਤ ਨੈੱਟਵਰਕ ਤੋਂ ਟੈਸਟ ਕਰੋ। ਉਸੇ LAN ਦੀ ਹੋਰ ਮਸ਼ੀਨ ਤੋਂ ਜਾਂਚ hairpin NAT ਸਹਿਯੋਗ ਰਾਹੀਂ ਲੰਘ ਸਕਦੀ ਹੈ ਅਤੇ ਦੂਰਲੇ ਕਲਾਇੰਟ ਵੱਲੋਂ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਰਸਤਾ ਕਦੇ ਨਹੀਂ ਅਜ਼ਮਾਉਂਦੀ, ਇਸ ਲਈ ਉੱਥੋਂ ਦਾ ਹਰਾ ਨਤੀਜਾ ਗਲਤ ਚੀਜ਼ ਸਾਬਤ ਕਰਦਾ ਹੈ।

tcpdump -ni any port 29443
conntrack -L | grep 29443

ਸਰਵਰ ਉੱਤੇ ਅਤੇ ਕਲਾਇੰਟ ਉੱਤੇ ਇੱਕੋ ਸਮੇਂ ਕੈਪਚਰ ਚਲਾਓ। ਸਰਵਰ ਦਾ ਕੈਪਚਰ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਅਨੁਵਾਦਿਤ ਪੈਕਟ ਟਨਲ ਵੱਲ ਨਿਕਲਦਾ ਹੈ ਜਾਂ ਨਹੀਂ; ਕਲਾਇੰਟ ਦਾ ਕੈਪਚਰ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਬੇਨਤੀ ਪਹੁੰਚਦੀ ਹੈ ਜਾਂ ਨਹੀਂ ਅਤੇ ਜਵਾਬ ਕਿੱਥੇ ਸੰਬੋਧਿਤ ਹੈ। conntrack -L ਵਿੱਚ ਅਨੁਵਾਦ ਐਂਟਰੀ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਨਿਯਮ ਮੇਲ ਖਾਧਾ, ਅਤੇ ਇਸਦੀ ਗੈਰ-ਹਾਜ਼ਰੀ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਪੈਕਟ ਕਦੇ NAT ਚੇਨ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਿਆ।

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