CGNAT ਪਿੱਛੇ ਵਾਲਾ VPN ਸਰਵਰ ਕਦੇ ਕਨੈਕਸ਼ਨ ਕਿਉਂ ਨਹੀਂ ਸਵੀਕਾਰਦਾ

ਰਾਊਟਰ 100.72 ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ WAN ਪਤਾ ਦੱਸਦਾ ਹੈ, ਡਾਇਨਾਮਿਕ DNS ਨਾਮ ਕਿਸੇ ਹੋਰ ਜਨਤਕ ਪਤੇ 'ਤੇ ਹੱਲ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਸ ਰਾਊਟਰ ਦਾ VPN ਸਰਵਰ ਬਾਹਰੋਂ ਕਦੇ ਹੈਂਡਸ਼ੇਕ ਪੂਰਾ ਨਹੀਂ ਕਰਦਾ। ਪੋਰਟ ਫਾਰਵਰਡਿੰਗ ਸੰਰਚਿਤ ਹੈ, ਸੇਵਾ ਚੱਲ ਰਹੀ ਹੈ, ਅਤੇ LAN ਤੋਂ ਟੈਸਟ ਅਜੇ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ। ਰਾਊਟਰ ਲਾਗ ਵਿੱਚ ਕੋਈ ਗਲਤੀ ਵਰਗੀ ਚੀਜ਼ ਨਹੀਂ ਦਿਸਦੀ। ਉਹ ਸੰਜੋਗ ਕੈਰੀਅਰ-ਗਰੇਡ NAT ਹੈ, ਅਤੇ ISP ਕੋਲ ਰਹਿੰਦੇ ਪਤੇ 'ਤੇ ਕੋਈ ਫਾਇਰਵਾਲ ਨਿਯਮ ਪੋਰਟ ਨਹੀਂ ਖੋਲ੍ਹ ਸਕਦਾ।

ਸਾਂਝੇ ਪਤੇ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਵਿੱਚ ਦੋ ਮਿੰਟ ਲੱਗਦੇ ਹਨ ਅਤੇ ਇੱਕ ਹਫ਼ਤੇ ਦੀਆਂ ਸੰਰਚਨਾ ਤਬਦੀਲੀਆਂ ਬਚਦੀਆਂ ਹਨ।

ਕੈਰੀਅਰ NAT ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲੇ ਸੰਕੇਤ

ਰਾਊਟਰ ਦੇ ਸਥਿਤੀ ਪੰਨੇ 'ਤੇ WAN ਪਤੇ ਦੀ ਤੁਲਨਾ ਬਾਹਰੀ ਖੋਜ ਵੱਲੋਂ ਦੱਸੇ ਪਤੇ ਨਾਲ ਕਰੋ। 100.64.0.0/10 ਦੇ ਅੰਦਰ WAN ਪਤਾ ਆਮ ਸੰਕੇਤ ਹੈ, ਅਤੇ ਨਿੱਜੀ ਰੇਂਜਾਂ 10/8, 172.16/12 ਅਤੇ 192.168/16 ਦਾ ਵੀ ਇਹੀ ਅਰਥ ਹੈ। ਜੇ traceroute ਉਹੀ ਜਨਤਕ ਹੌਪ ਵਾਰ-ਵਾਰ ਦਿਖਾਵੇ, ਜਾਂ ਸ਼ੁਰੂਆਤੀ ਹੌਪ ਨਿੱਜੀ ਪਤੇ ਨਾਲ ਜਵਾਬ ਦੇਵੇ, ਤਾਂ ਰਾਊਟਰ ਅਤੇ ਇੰਟਰਨੈੱਟ ਵਿਚਕਾਰ ਇੱਕ ਹੋਰ ਅਨੁਵਾਦਕ ਬੈਠਾ ਹੈ। ਕੁਝ ISP ਨਿਰਧਾਰਤ ਪਤਾ ਸਿਰਫ਼ ਗਾਹਕ ਪੋਰਟਲ ਵਿੱਚ ਦਿਖਾਉਂਦੇ ਹਨ, ਇਸ ਲਈ ਉਹ ਮੁੱਲ traceroute ਨਾਲ ਨਿਰਯਾਤ ਕਰੋ।

ਪ੍ਰੋਟੋਕੋਲ ਜਾਂ ਪੋਰਟ ਬਦਲਣ ਨਾਲ ਮਦਦ ਨਹੀਂ ਮਿਲਦੀ, ਕਿਉਂਕਿ ਸਮੱਸਿਆ ਬੰਦ ਪੋਰਟ ਨਹੀਂ, ਆਉਣ ਵਾਲੀ ਪਹੁੰਚ ਹੈ।

ਫਾਰਵਰਡਿੰਗ ਅਤੇ ਡਾਇਨਾਮਿਕ DNS ਇਸ ਨੂੰ ਕਿਉਂ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦੇ

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

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

ਸਪਸ਼ਟ ਰੂਟਾਂ ਨਾਲ VPS ਰਾਹੀਂ ਰੀਲੇ

ਸਾਹਮਣੇ ਜਨਤਕ ਪਤਾ ਰੱਖੋ ਟ੍ਰੈਫਿਕ ਚੁੱਕ ਸਕਣ ਵਾਲਾ ਸਭ ਤੋਂ ਛੋਟਾ VPS ਕਿਰਾਏ 'ਤੇ ਲੈ ਕੇ, ਫਿਰ ਘਰ ਦੇ ਰਾਊਟਰ ਨੂੰ ਉੱਧਰ ਬਾਹਰ ਜਾ ਕੇ ਕਾਲ ਕਰਨ ਦਿਓ। ਘਰ ਦੇ ਨੈੱਟਵਰਕ ਤੋਂ ਬਾਹਰ ਜਾਣ ਵਾਲੀ UDP ਕੈਰੀਅਰ NAT ਪਾਰ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਟਨਲ ਅੰਦਰੋਂ ਬਣਦੀ ਹੈ ਅਤੇ VPS ਪਹੁੰਚਯੋਗ ਅੰਤ ਬਿੰਦੂ ਬਣਦਾ ਹੈ। ਘਰ ਦਾ ਪਾਸਾ ਸਥਿਰ ਟਨਲ ਪਤੇ ਵਾਲਾ ਗਾਹਕ ਬਣਦਾ ਹੈ, ਸਰਵਰ ਨਹੀਂ।

VPS 'ਤੇ ਗਾਹਕ-ਵਿਸ਼ੇਸ਼ ਡਾਇਰੈਕਟਰੀ ਐਂਟਰੀ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਜੋ ਸਰਵਰ ਨੂੰ ਪਤਾ ਹੋਵੇ ਕਿ ਘਰ ਦਾ ਸਬਨੈੱਟ ਕਿਸ ਪੀਅਰ ਦਾ ਹੈ, ਅਤੇ ਮੇਲ ਖਾਂਦਾ ਕਰਨਲ ਰੂਟ ਵੀ ਸ਼ਾਮਲ ਕਰੋ।

# /etc/openvpn/server/ccd/home-site.conf
ifconfig-push 10.8.0.10 255.255.255.0
iroute 192.168.50.0 255.255.255.0

# server.conf
client-config-dir /etc/openvpn/server/ccd
route 192.168.50.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"

iroute ਲਾਈਨ OpenVPN ਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਘਰ ਦੇ ਸਬਨੈੱਟ ਦਾ ਟ੍ਰੈਫਿਕ ਕਿਹੜਾ ਗਾਹਕ ਲੈਂਦਾ ਹੈ; route ਲਾਈਨ ਉਸ ਸਬਨੈੱਟ ਨੂੰ VPS ਦੀ ਕਰਨਲ ਸਾਰਣੀ ਵਿੱਚ ਪਾਉਂਦੀ ਹੈ ਤਾਂ ਜੋ ਪੈਕਟ ਟਨਲ ਵਿੱਚ ਦਾਖਲ ਹੋ ਸਕਣ। ਪ੍ਰਕਾਸ਼ਿਤ ਸੇਵਾ ਲਈ, ਜਨਤਕ ਪੋਰਟ ਨੂੰ 10.8.0.10 'ਤੇ ਫਾਰਵਰਡ ਕਰਨ ਵਾਲਾ ਗੰਤਵ NAT ਨਿਯਮ ਸ਼ਾਮਲ ਕਰੋ ਅਤੇ net.ipv4.ip_forward ਸਮਰੱਥ ਕਰੋ।

ਬਾਹਰੋਂ ਰਸਤਾ ਟੈਸਟ ਕਰੋ

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

ss -lunp | grep 1194
tcpdump -ni any udp port 1194
nft list ruleset | grep -A4 dnat

# from a phone on mobile data, not the home Wi-Fi
nc -vz -u 203.0.113.10 1194

ਜੇ ਕੈਪਚਰ ਫ਼ੋਨ ਤੋਂ ਪੈਕਟ ਦਿਖਾਵੇ ਪਰ ਜਵਾਬ ਨਾ ਹੋਵੇ, ਤਾਂ ਅਗਲਾ ਪੜਾਅ ਸਰਵਰ ਸੰਰਚਨਾ ਜਾਂ ਫਾਇਰਵਾਲ ਹੈ। ਜੇ ਕੈਪਚਰ ਕੁਝ ਨਾ ਦਿਖਾਵੇ, ਤਾਂ ਗਾਹਕ ਅਜੇ ਹੱਲ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਗਲਤ ਪਤੇ 'ਤੇ ਭੇਜ ਰਿਹਾ ਹੈ।

ਪਹਿਲਾਂ ਕੀਮਤ ਜਾਂਚਣ ਯੋਗ ਬਦਲ

ISP ਤੋਂ ਸਮਰਪਿਤ IPv4 ਪਤਾ ਸਭ ਤੋਂ ਛੋਟਾ ਹੱਲ ਹੈ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਛੋਟੀ ਮਾਸਿਕ ਫ਼ੀਸ ਹੁੰਦੀ ਹੈ। VPN, ਗਾਹਕ ਨੈੱਟਵਰਕ ਅਤੇ DNS ਰਿਕਾਰਡ ਸਾਰਿਆਂ ਦੇ ਸਮਰਥਨ ਨਾਲ ਨੇਟਿਵ IPv6 ਦੋਵੇਂ ਸਿਰਿਆਂ ਦਾ ਅਨੁਵਾਦ ਹਟਾ ਦਿੰਦਾ ਹੈ। ਘਰ ਦੇ ਨੈੱਟਵਰਕ ਅੰਦਰ ਸਬਨੈੱਟ ਰਾਊਟਰ ਵਾਲਾ ਮੈਸ਼ ਓਵਰਲੇ VPS ਤੋਂ ਬਿਨਾਂ ਉਹੀ ਰੀਲੇ ਦਿੰਦਾ ਹੈ, ਪਰ ਤਾਲਮੇਲ ਸੇਵਾ 'ਤੇ ਨਿਰਭਰਤਾ ਦੀ ਕੀਮਤ 'ਤੇ।

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