ਜਦੋਂ CGNAT ਪੋਰਟ ਬਲਾਕ ਕਰਦਾ ਹੈ ਤਾਂ VPS ਰਾਹੀਂ ਘਰ ਦਾ ਸਰਵਰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨਾ

ਮੈਂ ਬਾਹਰੋਂ ਸ਼ੁਰੂ ਕੀਤਾ, ਜਿਵੇਂ ਕੋਈ ਵਰਤੋਂਕਾਰ ਕਰਦਾ: ਨਾਮ ਮੋਬਾਈਲ ਡੇਟਾ ’ਤੇ ਫ਼ੋਨ ਦੇ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਲਿਖਿਆ ਅਤੇ ਵੇਖਿਆ ਕਿ ਕਨੈਕਸ਼ਨ ਸਮਾਂ ਖ਼ਤਮ ਹੋਣ ਤੱਕ ਲਟਕਦਾ ਰਿਹਾ। ਨਾਮ ਹੱਲ ਹੋ ਰਿਹਾ ਸੀ, ਯਾਨੀ DNS ਠੀਕ ਸੀ। ਘਰ ਦੇ ਰਾਊਟਰ ਦਾ ਪੋਰਟ-ਫ਼ਾਰਵਰਡਿੰਗ ਸਫ਼ਾ ਵੀ ਬੰਦ ਗਲੀ ਸੀ, ਕਿਉਂਕਿ ਉਸ ਦਾ WAN ਪਤਾ 100.64.31.42 ਦਿਖਾ ਰਿਹਾ ਸੀ, ਅਤੇ ਇਹ ਉਹ ਪਤਾ ਨਹੀਂ ਜਿੱਥੇ ਕੋਈ ਸੇਵਾ ਪ੍ਰਦਾਤਾ ਮੈਨੂੰ ਇੰਟਰਨੈੱਟ ਤੋਂ ਭੇਜੇ। ਇਹ ਸੰਖਿਆ ਪੂਰੀ ਖ਼ਰਾਬੀ ਸਮਝਾਉਂਦੀ ਹੈ: ਲਾਈਨ carrier-grade NAT ਦੇ ਪਿੱਛੇ ਹੈ, ਇਸ ਲਈ ਸੁਰੰਗ ਦੇ ਮੇਰੇ ਪਾਸੇ ਦਾ ਜਨਤਕ ਪਤਾ ਸੇਵਾ ਪ੍ਰਦਾਤਾ ਦਾ ਹੈ। ਅੱਗੇ ਉਹ ਰਾਹ ਹੈ ਜੋ ਮੈਂ ਉਸ ਅਟਕੇ ਟੈਬ ਤੋਂ ਜਵਾਬ ਦੇਣ ਵਾਲੀ ਸੇਵਾ ਤੱਕ ਤੈਅ ਕੀਤਾ।

ਕਲਾਇੰਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਅੰਦਰ ਵੱਲ ਵਧੋ

ਕੋਈ ਵੀ ਨਿਯਮ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਸਾਬਤ ਕਰੋ ਕਿ ਜ਼ੰਜੀਰ ਕਿੱਥੇ ਰੁਕਦੀ ਹੈ। ਲੈਪਟਾਪ ’ਤੇ ਮੈਂ dig +short files.example.net ਚਲਾਇਆ ਅਤੇ VPS ਦਾ ਪਤਾ ਵਾਪਸ ਮਿਲਿਆ, ਜਿਸ ਨੇ ਮੇਰੀ ਮਸ਼ੀਨ ’ਤੇ ਪੁਰਾਣਾ DNS ਰੱਦ ਕਰ ਦਿੱਤਾ। ਫਿਰ curl -v --connect-timeout 5 files.example.net:5022 ਨਾਂ-ਮਨਜ਼ੂਰ ਹੋਣ ਦੀ ਥਾਂ ਸਮਾਂ ਖ਼ਤਮ ਹੋਣ ’ਤੇ ਅਟਕ ਗਿਆ। ਇਹ ਫ਼ਰਕ ਮਾਅਨੇ ਰੱਖਦਾ ਹੈ: ਸਮਾਂ ਖ਼ਤਮ ਹੋਣਾ ਆਮ ਤੌਰ ’ਤੇ ਮਤਲਬ ਹੈ ਕਿ ਪੈਕਟ ਰਾਹ ਵਿੱਚ ਸੁੱਟੇ ਜਾ ਰਹੇ ਹਨ, ਜਦਕਿ ਨਾਂ-ਮਨਜ਼ੂਰੀ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕਿਸੇ ਚੀਜ਼ ਨੇ ਜਵਾਬ ਦਿੱਤਾ ਅਤੇ ਨਾਂਹ ਕਿਹਾ।

ਅੰਦਰ ਵੱਲ ਅਗਲਾ ਕਦਮ ਖ਼ੁਦ VPS ਸੀ। ss -ltnp ਨੇ ਅਜਿਹਾ ਕੁਝ ਨਹੀਂ ਦਿਖਾਇਆ ਜੋ 5022 ’ਤੇ ਸੁਣ ਰਿਹਾ ਹੋਵੇ, ਜੋ DNAT ਨਿਯਮ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਆਸ ਕੀਤੀ ਜਾਂਦੀ ਸੀ। ਉਸੇ ਮਸ਼ੀਨ ’ਤੇ wg show (ਜਾਂ OpenVPN ਲਈ ip -br a show tun0) ਨੇ ਪੁਸ਼ਟੀ ਕੀਤੀ ਕਿ ਘਰ ਦਾ peer ਸਰਗਰਮ ਹੈ ਅਤੇ ਉਸ ਦਾ handshake ਤਾਜ਼ਾ ਹੈ। ਜੇ peer ਕੰਮ ਨਾ ਕਰੇ ਤਾਂ ਕੋਈ NAT ਨਿਯਮ ਮਦਦ ਨਹੀਂ ਕਰੇਗਾ, ਅਤੇ ਘਰ ਦੇ ਰਾਊਟਰ ਦੇ VPN ਸਫ਼ੇ ’ਤੇ ਹਰੀ ਬੱਤੀ ਕੁਝ ਵੀ ਮਾਅਨੇ ਨਹੀਂ ਰੱਖਦੀ।

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਘਰ ਦੀ ਲਾਈਨ ਸੱਚਮੁੱਚ CGNAT ਦੇ ਪਿੱਛੇ ਹੈ

ਰਾਊਟਰ ਜੋ ਪਤਾ ਆਪਣੇ WAN ਇੰਟਰਫ਼ੇਸ ’ਤੇ ਦੱਸਦਾ ਹੈ, ਉਸ ਦੀ ਤੁਲਨਾ ਉਸ ਨਾਲ ਕਰੋ ਜੋ ਕੋਈ ਬਾਹਰੀ ਸੇਵਾ ਵੇਖਦੀ ਹੈ। 100.64.0.0/10 ਵਿੱਚ ਜੋ ਕੁਝ ਹੈ, ਯਾਨੀ 100.64.x.x ਤੋਂ 100.127.x.x ਤੱਕ, RFC 6598 ਦਾ ਸਾਂਝਾ ਪਤਾ-ਘੇਰਾ ਹੈ ਅਤੇ ਇੰਟਰਨੈੱਟ ਤੋਂ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਹੈ। ਉਸੇ ਨਤੀਜੇ ’ਤੇ ਤੁਸੀਂ ਤਦ ਵੀ ਪਹੁੰਚਦੇ ਹੋ ਜਦੋਂ ਰਾਊਟਰ ਕੋਈ ਆਮ ਨਿੱਜੀ ਪਤਾ ਹੋਣ ਦਾ ਦਾਅਵਾ ਕਰੇ ਅਤੇ ਜਨਤਕ ਖੋਜ ਕੋਈ ਅਸੰਬੰਧਿਤ ਚੀਜ਼ ਮੋੜ ਦੇਵੇ। CGNAT ਲਾਈਨ ਨਾਲ ਅਜਿਹਾ ਜਨਤਕ ਪਤਾ ਵੀ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਸਿਰਫ਼ ਅਗਲੇ lease ਤੱਕ ਰਹਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਪੋਰਟ ਫ਼ਾਰਵਰਡਿੰਗ ਇੱਕ ਘੰਟਾ ਕੰਮ ਕਰਦੀ ਦਿਸਦੀ ਹੈ ਅਤੇ ਫਿਰ ਚੁੱਪਚਾਪ ਮਰ ਜਾਂਦੀ ਹੈ।

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

ਨਾਮ ਨੂੰ VPS ਦੇ ਪਤੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰੋ

DNS ਟ੍ਰੈਫ਼ਿਕ ਅੱਗੇ ਨਹੀਂ ਭੇਜਦਾ, ਇਸ ਲਈ ਸੇਵਾ ਦੇ A ਰਿਕਾਰਡ ਵਿੱਚ VPS ਦਾ ਜਨਤਕ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। 192.168.1.20 ਵੱਲ A ਰਿਕਾਰਡ ਸਿਰਫ਼ ਉਨ੍ਹਾਂ ਕਲਾਇੰਟਾਂ ਲਈ ਲਾਹੇਵੰਦ ਢੰਗ ਨਾਲ ਹੱਲ ਹੁੰਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ VPN ਵਿੱਚ ਹਨ; ਇੰਟਰਨੈੱਟ ਤੋਂ ਇਹ ਅਜਿਹੇ ਪਤੇ ’ਤੇ ਹੱਲ ਹੁੰਦਾ ਹੈ ਜਿਸ ਨੂੰ ਕੋਈ ਰੂਟ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਖ਼ੁਦ VPS ਦੀ ਪ੍ਰਬੰਧਕੀ ਪਹੁੰਚ ਲਈ ਮੈਂ ਵੱਖਰਾ ਨਾਮ ਰੱਖਦਾ ਹਾਂ, ਤਾਂ ਜੋ ਕਦੇ ਇਹ ਨਾ ਉਲਝਾਵਾਂ ਕਿ ਰਿਕਾਰਡ ਕਿਸ ਹੋਸਟ ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ।

ਜੇ VPS ਅਤੇ ਘਰ ਦੀ ਮਸ਼ੀਨ ਦੋਵੇਂ HTTP ਪਰੋਸਦੇ ਹਨ, ਤਾਂ ਹਰ ਇੱਕ ਨੂੰ ਆਪਣਾ ਨਾਮ ਦਿਓ ਅਤੇ VPS ਨੂੰ ਫ਼ੈਸਲਾ ਕਰਨ ਦਿਓ ਕਿ ਕੌਣ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਦੋਵਾਂ ਨੂੰ ਇੱਕ ਨਾਮ ਵਿੱਚ ਸਮੇਟ ਕੇ ਇਹ ਆਸ ਕਰਨਾ ਕਿ ਪ੍ਰੌਕਸੀ ਸਹੀ backend ਚੁਣੇਗੀ, ਠੀਕ ਉਹੀ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਸਾਰੀ ਦੁਪਹਿਰ ਗ਼ਲਤ ਹੋਸਟ ’ਤੇ ਗ਼ਲਤੀ ਲੱਭਦੇ ਹੋ।

ਇੱਕ ਪੋਰਟ DNAT ’ਤੇ, SSH 22 ’ਤੇ ਰਹੇ

ਸਿੱਧਾ ਵਿਕਲਪ VPS ’ਤੇ ਮੰਜ਼ਿਲ NAT ਹੈ। ਚੱਲ ਰਹੇ ਕਰਨਲ ਲਈ forwarding ਚਾਲੂ ਕਰੋ ਅਤੇ ਨਿਯਮ ਵਿੱਚ ਘਰ ਦੇ ਸਰਵਰ ਦਾ ਸੁਰੰਗ ਪਤਾ ਰੱਖੋ, ਉਸ ਦਾ LAN ਪਤਾ ਨਹੀਂ:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -p tcp -d 198.51.100.10 --dport 5022 -j DNAT --to-destination 10.8.0.2

ਖ਼ੁਦ VPS ਤੱਕ SSH ਨੂੰ 22 ’ਤੇ ਰਹਿਣ ਦਿਓ ਅਤੇ ਕੋਈ ਹੋਰ ਪੋਰਟ, ਜਿਵੇਂ 5022, ਘਰ ਦੀ ਮਸ਼ੀਨ ਵੱਲ ਭੇਜੋ। ਜੇ 22 ਕਿਸੇ ਬੰਦ ਮਸ਼ੀਨ ਵੱਲ ਭੇਜੋਗੇ ਤਾਂ ਉਹ ਇਕੱਲਾ ਰਾਹ ਗੁਆ ਦੇਵੋਗੇ ਜੋ ਉਸ ਨੂੰ ਠੀਕ ਕਰ ਸਕਦਾ ਸੀ। ਇਹੀ ਤਰਕ ਪ੍ਰੌਕਸੀ ’ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: VPS ਦਾ ਪ੍ਰਬੰਧਕੀ ਪੋਰਟ relay ਨਿਯਮਾਂ ਤੋਂ ਬਾਹਰ ਰੱਖੋ।

ਨਿਯਮ ਕੰਮ ਕਰਨ ਲੱਗਣ ’ਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਪੱਕੇ ਕਰੋ। Debian ਜਾਂ Ubuntu ’ਤੇ apt install iptables-persistent ਅਤੇ ਫਿਰ netfilter-persistent save ਉਨ੍ਹਾਂ ਨੂੰ /etc/iptables/rules.v4 ਵਿੱਚ ਲਿਖਦੇ ਹਨ। firewalld ਵਾਲੇ ਹੋਸਟ ’ਤੇ ਇਸ ਦਾ ਬਰਾਬਰ ਹੈ ਜ਼ੋਨ ਵਿੱਚ ਪੱਕੀ ਪੋਰਟ ਫ਼ਾਰਵਰਡਿੰਗ, ਜਿਸ ਨੂੰ ਲਾਗੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ firewall-cmd --reload ਚਾਹੀਦਾ ਹੈ। ਸਿਰਫ਼ ਮੈਮੋਰੀ ਵਿੱਚ ਰਹਿਣ ਵਾਲੇ ਨਿਯਮ ਸੇਵਾ ਪ੍ਰਦਾਤਾ ਦੇ ਪਹਿਲੇ ਰੱਖ-ਰਖਾਅ ਰੀਬੂਟ ’ਤੇ ਗ਼ਾਇਬ ਹੋ ਜਾਂਦੇ ਹਨ, ਆਮ ਤੌਰ ’ਤੇ ਕਿਸੇ ਮਾੜੇ ਸਮੇਂ।

ਵਾਪਸੀ ਦਾ ਰਾਹ ਠੀਕ ਕਰੋ ਜਾਂ ਉਸ ਦੀ ਲੋੜ ਤੋਂ ਬਚੋ

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

ਦੋ ਸੁਧਾਰ ਕੰਮ ਕਰਦੇ ਹਨ। ਘਰ ਦੀ ਮਸ਼ੀਨ ਨੂੰ ਨੀਤੀ-ਰਾਹ ਦਿਓ ਤਾਂ ਜੋ ਸੁਰੰਗ ਤੋਂ ਆਉਣ ਵਾਲਾ ਟ੍ਰੈਫ਼ਿਕ ਸੁਰੰਗ ਰਾਹੀਂ ਵਾਪਸ ਜਾਵੇ:

ip rule add from 10.8.0.2 table 100
ip route add default dev wg0 table 100

ਜਾਂ VPS ਨੂੰ ਸਰੋਤ ਮੁੜ ਲਿਖਣ ਦਿਓ ਤਾਂ ਜੋ ਜਵਾਬ ਕੋਲ ਅਜਿਹਾ ਪਤਾ ਹੋਵੇ ਜਿੱਥੇ ਉਹ ਪਹੁੰਚ ਸਕੇ, ਅਤੇ conntrack ਉਸ ਨੂੰ ਬਾਹਰ ਜਾਂਦਿਆਂ ਪਲਟ ਦੇਵੇ:

iptables -t nat -A POSTROUTING -d 10.8.0.2 -p tcp --dport 5022 -j SNAT --to-source 10.8.0.1

SNAT ਵਾਲਾ ਰੂਪ ਅਸਲ ਕਲਾਇੰਟ ਪਤਾ ਘਰ ਦੇ ਸਰਵਰ ਤੋਂ ਲੁਕਾ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਲੌਗ peer ਵਜੋਂ 10.8.0.1 ਦਿਖਾਉਂਦੇ ਹਨ। ਮੂਲ ਪਤਾ ਐਪਲੀਕੇਸ਼ਨ ਪਰਤ ’ਤੇ ਅੱਗੇ ਭੇਜੋ, ਜਾਂ ਪ੍ਰਤੀ ਕਲਾਇੰਟ ਲੌਗਿੰਗ ਦਾ ਨੁਕਸਾਨ ਮਨਜ਼ੂਰ ਕਰੋ, ਪਰ ਇਹ ਫ਼ੈਸਲਾ ਸੋਚ-ਸਮਝ ਕੇ ਕਰੋ, ਕਿਸੇ ਘਟਨਾ ਦੌਰਾਨ ਇਸ ਨੂੰ ਲੱਭਣ ਦੀ ਥਾਂ।

ਪੂਰਾ ਰਾਹ ਬਾਹਰੋਂ ਜਾਂਚੋ

ਅਜਿਹੇ ਨੈੱਟਵਰਕ ਤੋਂ ਤਸਦੀਕ ਕਰੋ ਜੋ ਨਾ VPS ਹੈ ਨਾ ਘਰ: ਮੋਬਾਈਲ ਡੇਟਾ ’ਤੇ ਫ਼ੋਨ, ਜਾਂ ਕਿਤੇ ਹੋਰ ਸਸਤਾ shell। nc -vz files.example.net 5022 ਨੂੰ ਸਫਲ ਕਨੈਕਸ਼ਨ ਦੀ ਰਿਪੋਰਟ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ openssl s_client -connect files.example.net:443 -servername files.example.net ਨੂੰ ਜਨਤਕ ਨਾਮ ਲਈ ਸਰਟੀਫ਼ਿਕੇਟ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਫਿਰ ਸੇਵਾ ਪ੍ਰਦਾਤਾ ਦਾ ਸੁਰੱਖਿਆ ਸਮੂਹ ਜਾਂ ਕਲਾਊਡ ਫ਼ਾਇਰਵਾਲ ਵੇਖੋ। ਅਜਿਹਾ DNAT ਨਿਯਮ ਜੋ ਕਦੇ ਪੈਕਟ ਨਹੀਂ ਵੇਖਦਾ, ਆਮ ਤੌਰ ’ਤੇ ਹੋਸਟ ਤੋਂ ਇੱਕ ਪਰਤ ਉੱਪਰ ਬਲਾਕ ਹੁੰਦਾ ਹੈ।

ਅੰਤ ਵਿੱਚ ਤੈਅ ਕਰੋ ਕਿ ਸੁਰੰਗ ਡਿੱਗਣ ’ਤੇ ਕੀ ਹੋਵੇਗਾ। DNAT ਨਿਯਮ ਕਨੈਕਸ਼ਨ ਲੈਂਦਾ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਚੁੱਪਚਾਪ ਮੁਰਦਾ ਸੁਰੰਗ ਵਿੱਚ ਭੇਜਦਾ ਹੈ, ਜੋ ਬਿਲਕੁਲ ਖ਼ਰਾਬ ਸੇਵਾ ਵਾਂਗ ਦਿਸਦਾ ਹੈ। VPS ’ਤੇ ਸਿਹਤ ਜਾਂਚ ਜੋ ਪੋਰਟ ਨਾਂ-ਮਨਜ਼ੂਰ ਕਰੇ ਜਦ ਤੱਕ peer ਕੰਮ ਨਾ ਕਰੇ, ਕੁਝ ਲਾਈਨਾਂ ਦੀ ਲਾਗਤ ਹੈ ਅਤੇ ਇੱਕ ਘੰਟੇ ਦਾ ਅੰਦਾਜ਼ਾ ਬਚਾਉਂਦੀ ਹੈ। ਉਸ ਤੋਂ ਬਾਅਦ ਨਿਯਮ ਸੰਪਾਦਿਤ ਕਰਨਾ ਛੱਡ ਦਿਓ ਅਤੇ ਇਸ ’ਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਦਿਨ ਵੇਖੋ।