NAT ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਡਾ VPN ਸਰਵਰ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਸਰੋਤ ਪਤਾ ਦੇਖਦਾ ਹੈ

ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਕਿ VPN ਸਰਵਰ ਪੈਕਟ ਤੋਂ ਤੁਹਾਡੇ ਲੈਪਟਾਪ ਦਾ ਪਤਾ ਪੜ੍ਹ ਕੇ ਲੌਗ ਵਿੱਚ ਲਿਖਦਾ ਹੈ। ਇਹ ਜੋ ਪੜ੍ਹਦਾ ਹੈ ਉਹੀ ਹੁੰਦਾ ਹੈ ਜੋ ਆਖਰੀ NAT ਹੌਪ ਨੇ ਬਾਹਰੀ ਹੈਡਰ ਵਿੱਚ ਪਾਇਆ, ਅਤੇ ਹਾਟਸਪਾਟ ਵਜੋਂ ਵਰਤੇ ਜਾਂਦੇ ਫ਼ੋਨ 'ਤੇ ਇਹ ਅਕਸਰ ਉਹ ਪਤਾ ਹੁੰਦਾ ਹੈ ਜੋ ਸੈਂਕੜੇ ਹੋਰ ਗਾਹਕਾਂ ਨਾਲ ਸਾਂਝਾ ਹੁੰਦਾ ਹੈ। ਤੁਹਾਡੀ ਮਸ਼ੀਨ ਦਾ ਆਪਣਾ 192.168.x.x ਉਸ ਹੈਡਰ ਵਿੱਚ ਕਦੇ ਵੀ ਇੰਟਰਨੈੱਟ ਪਾਰ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਟਨਲ ਦਾ ਪਤਾ ਸਰਵਰ ਤਦ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਕਨੈਕਸ਼ਨ ਪਹਿਲਾਂ ਹੀ ਬਣ ਚੁੱਕਾ ਹੁੰਦਾ ਹੈ। ਇਸ ਲਈ ਜਦੋਂ ਸਰਵਰ ਦਾ ਲੌਗ ਅਤੇ ਲੈਪਟਾਪ 'ਤੇ ip addr ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ, ਤਾਂ ਕੋਈ ਵੀ ਗਲਤ ਨਹੀਂ; ਉਹ ਇੱਕੋ ਸੈਸ਼ਨ ਦੀਆਂ ਵੱਖਰੀਆਂ ਪਰਤਾਂ ਦੱਸਦੇ ਹਨ।

ਤਿੰਨ ਪਤੇ, ਅਤੇ ਲੌਗ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ

ਉਲਝਣ ਤਿੰਨ ਪਤਿਆਂ ਨੂੰ ਇੱਕ ਵਿੱਚ ਸਮੇਟਣ ਨਾਲ ਆਉਂਦੀ ਹੈ। ਹਰ ਇੱਕ ਦਾ ਮਾਲਕ ਵੱਖਰਾ ਹੈ, ਉਹ ਵੱਖਰੇ ਹੈਡਰ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਵੱਖਰੇ ਰਾਹੀਂ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ।

ਕਨੈਕਟ ਕਰਦੇ ਸਮੇਂ ਸਿਰਫ਼ ਵਿਚਕਾਰਲੀ ਕਤਾਰ ਅਣਜਾਣ ਹੁੰਦੀ ਹੈ। ਸਰਵਰ ਇਸ ਨੂੰ ਡੈਮਨ ਅਨੁਸਾਰ ਆਪਣੀ ਪੀਅਰ ਸਾਰਣੀ, ਸਥਿਤੀ ਫ਼ਾਈਲ ਜਾਂ ਫ਼ਲੋ ਲੌਗ ਵਿੱਚ ਲਿਖਦਾ ਹੈ: WireGuard ਇਸ ਨੂੰ ਐਂਡਪੁਆਇੰਟ ਕਹਿੰਦਾ ਹੈ, OpenVPN ਸਥਿਤੀ ਫ਼ਾਈਲ ਇਸ ਨੂੰ Real Address ਲਿਖਦੀ ਹੈ, ਅਤੇ strongSwan ਇਸ ਨੂੰ IKE_SA ਦਾ ਦੂਰਲਾ ਹੋਸਟ ਦੱਸਦਾ ਹੈ। ਉਹ ਮੁੱਲ ਹਰ ਵਾਰ ਤਾਜ਼ਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕਿਸੇ ਹੋਰ ਸਰੋਤ ਤੋਂ ਪੈਕਟ ਆਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਕੋਈ ਕੁਝ ਵੀ ਮੁੜ-ਸ਼ੁਰੂ ਕੀਤੇ ਬਿਨਾਂ ਇਹ ਬਦਲ ਜਾਂਦਾ ਹੈ।

ਸਭ ਤੋਂ ਹੇਠਲੀ ਕਤਾਰ ਉਹ ਹੈ ਜਿਸ ਨੂੰ ਲੋਕ ਗਲਤੀ ਨਾਲ ਪਛਾਣ ਦਾ ਦਾਅਵਾ ਪੜ੍ਹਦੇ ਹਨ। ਇਹ ਸਰਵਰ ਸੰਰਚਨਾ ਵਿੱਚ ਇੱਕ ਥਾਂ ਦਰਸਾਉਂਦੀ ਹੈ, ਵਿਅਕਤੀ ਨਹੀਂ, ਕਿਉਂਕਿ ਸਰਵਰ ਨੇ ਇਸ ਨੂੰ ਆਪਣੇ ਪੂਲ ਵਿੱਚੋਂ ਚੁਣਿਆ ਹੈ। ਦੋ ਵਰਤੋਂਕਾਰ ਵੱਖਰੇ ਦਿਨਾਂ 'ਤੇ ਇੱਕੋ ਟਨਲ ਪਤਾ ਲੈ ਸਕਦੇ ਹਨ, ਅਤੇ ਇੱਕ ਵਿਅਕਤੀ ਦੋ ਡਿਵਾਈਸਾਂ ਤੋਂ ਦੋ ਰੱਖ ਸਕਦਾ ਹੈ।

ਟਨਲ ਚਾਲੂ ਰਹਿੰਦੇ ਹੋਏ ਲੌਗ ਕੀਤਾ ਟਿਊਪਲ ਕਿਉਂ ਬਦਲਦਾ ਹੈ

ਪਤਾ ਅਨੁਵਾਦ ਟਾਈਮਰ ਵਾਲੀ ਸਾਰਣੀ ਹੈ, ਸਥਾਈ ਬੰਧਨ ਨਹੀਂ। ਘਰ ਦਾ ਰਾਊਟਰ ਆਖਰੀ ਪੈਕਟ ਤੋਂ ਬਾਅਦ ਕੁਝ ਸਮਾਂ ਆਪਣਾ UDP ਮੈਪਿੰਗ ਰੱਖਦਾ ਹੈ, ਆਪਰੇਟਰ ਦਾ ਗੇਟਵੇ ਆਪਣੇ ਸ਼ਡਿਊਲ ਅਨੁਸਾਰ ਪੋਰਟ ਮੁੜ ਵਰਤਦਾ ਹੈ, ਅਤੇ Wi-Fi ਤੋਂ LTE 'ਤੇ ਜਾਣ ਵਾਲਾ ਫ਼ੋਨ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੇ ਸਰੋਤ ਨਾਲ ਵਾਪਸ ਆਉਂਦਾ ਹੈ। ਇੱਥੇ Linux conntrack ਦੇ ਡਿਫ਼ਾਲਟ ਮੁੱਲ ਲਾਹੇਵੰਦ ਮਾਪਦੰਡ ਹਨ: nf_conntrack_udp_timeout 30 ਸਕਿੰਟ ਹੈ ਅਤੇ ਸਟ੍ਰੀਮਿੰਗ ਰੂਪ 120, ਇਸ ਲਈ ਸ਼ਾਂਤ ਟਨਲ ਵਰਤੋਂਕਾਰ ਨੂੰ ਪਤਾ ਲੱਗਣ ਤੋਂ ਬਹੁਤ ਪਹਿਲਾਂ ਆਪਣਾ ਮੈਪਿੰਗ ਗੁਆ ਸਕਦਾ ਹੈ।

ਟਨਲ ਬਚਦਾ ਹੈ ਕਿਉਂਕਿ ਪ੍ਰੋਟੋਕੋਲ ਪਤੇ ਦੀ ਨਹੀਂ, ਪੀਅਰ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਜਾਂਚਦਾ ਹੈ। ਹੈਂਡਸ਼ੇਕ ਤੋਂ ਬਾਅਦ WireGuard ਬੇਹਾਲਤ ਹੈ, ਇਸ ਲਈ ਕੋਈ ਵੀ ਪ੍ਰਮਾਣਿਤ ਪੈਕਟ ਸੰਭਾਲਿਆ ਐਂਡਪੁਆਇੰਟ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ ਅਤੇ ਅਗਲੇ ਪੈਕਟ 'ਤੇ ਮੁੜ-ਬੰਧਨ ਠੀਕ ਹੋ ਜਾਂਦਾ ਹੈ; persistent-keepalive = 25 ਇਸੇ ਲਈ ਹੈ, ਨਿਸ਼ਕਿਰਿਆ ਰਹਿੰਦਿਆਂ ਮੈਪਿੰਗ ਨੂੰ ਗਰਮ ਰੱਖਣ ਲਈ। OpenVPN ਦਾ --float ਇਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਪ੍ਰਮਾਣਿਤ ਕਲਾਇੰਟ ਨੂੰ ਨਵੇਂ ਪਤੇ ਅਤੇ ਪੋਰਟ ਤੋਂ ਜਾਰੀ ਰੱਖਣ ਦਿੰਦਾ ਹੈ। 2.4 ਅਤੇ 2.5 ਬਿਲਡਾਂ ਵਿੱਚ ਜਿੱਥੇ float ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ ਬੰਦ ਹੈ, ਮੁੜ-ਬੰਧਨ ਸੈਸ਼ਨ ਨੂੰ ਰੀਸੈਟ ਕਰਦਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਦੁਬਾਰਾ ਜੁੜਦਾ ਹੈ।

IPsec ਉੱਥੇ ਵੱਧ ਚੱਲਦੇ ਹਿੱਸਿਆਂ ਨਾਲ ਪਹੁੰਚਦਾ ਹੈ। IKEv2 NAT ਖੋਜ ਪੇਲੋਡਾਂ ਵਿੱਚ ਸਰੋਤ ਅਤੇ ਮੰਜ਼ਿਲ ਦੇ ਹੈਸ਼ਾਂ ਦੀ ਤੁਲਨਾ ਕਰਕੇ ਅਨੁਵਾਦ ਪਛਾਣਦਾ ਹੈ, UDP 4500 ਐਨਕੈਪਸੂਲੇਸ਼ਨ 'ਤੇ ਜਾਂਦਾ ਹੈ, ਅਤੇ keepalive ਨੂੰ ਨਵੇਂ ਟਿਊਪਲ ਤੱਕ ਲੈ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ keepalive ਰੋਕੇ ਜਾਂਦੇ ਹਨ ਤਾਂ SA ਕਾਗਜ਼ 'ਤੇ ਚਾਲੂ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਦਿਸ਼ਾ ਦਾ ਟ੍ਰੈਫ਼ਿਕ ਚੁੱਪਚਾਪ ਰੁਕ ਜਾਂਦਾ ਹੈ।

ਸਰਵਰ ਕੀ ਆਰੋਪਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੀ ਨਹੀਂ

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

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

ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਦੋਵੇਂ ਸਿਰੇ ਤੁਲੋ

ਕੀ ਹੋਇਆ ਇਹ ਤੈਅ ਕਰਨ ਲਈ ਉਹੀ ਕਨੈਕਸ਼ਨ ਦੋਵੇਂ ਸਿਰਿਆਂ 'ਤੇ ਇੱਕੋ ਪਲ ਕੈਪਚਰ ਕਰੋ ਅਤੇ ਪਤੇ ਦੀ ਨਹੀਂ, ਟਿਊਪਲ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਕਲਾਇੰਟ 'ਤੇ, ਕਿਸੇ ਵੀ ਅਨੁਵਾਦ ਤੋਂ ਪਹਿਲਾਂ:

ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpoints

ਫਿਰ ਰਾਊਟਰ ਜਾਂ CGNAT ਗੇਟਵੇ 'ਤੇ ਅਨੁਵਾਦ ਐਂਟਰੀ ਅਤੇ ਅੰਤ ਵਿੱਚ ਸਰਵਰ 'ਤੇ ਕੀ ਪਹੁੰਚਦਾ ਹੈ ਪੜ੍ਹੋ:

conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820

ਤਿੰਨ ਨਮੂਨੇ ਬਹੁਤੀਆਂ ਅਸੰਗਤੀਆਂ ਦੱਸਦੇ ਹਨ। ਸਰਵਰ 'ਤੇ ਸਰੋਤ ਪੋਰਟ ਸਥਾਨਕ ਪੋਰਟ ਤੋਂ ਵੱਖਰਾ ਹੈ ਜਦੋਂ ਕਿ ਮੰਜ਼ਿਲ ਮਿਲਦੀ ਹੈ: ਆਮ ਪੋਰਟ ਅਨੁਵਾਦ। ਸਰਵਰ 'ਤੇ ਸਰੋਤ ਪਤਾ ਤੁਹਾਡੇ ਤੋਂ ਨਾ ਹੋਣ ਵਾਲੇ ISP ਬਲਾਕ ਦਾ ਹੈ: ਘੱਟੋ-ਘੱਟ ਇੱਕ ਵਾਧੂ NAT ਪਰਤ। ਨਿਸ਼ਕਿਰਿਆਤਾ ਤੋਂ ਬਾਅਦ ਪੈਕਟ ਰੁਕਦੇ ਹਨ ਅਤੇ ਨਵੇਂ ਪੋਰਟ ਨਾਲ ਚੱਲਦੇ ਹਨ: ਮੈਪਿੰਗ ਦੀ ਮਿਆਦ ਖ਼ਤਮ, ਰਾਊਟਿੰਗ ਖ਼ਰਾਬੀ ਨਹੀਂ। ਜੇ ਟਾਈਮਸਟੈਂਪ ਇੱਕ-ਦੋ ਸਕਿੰਟਾਂ ਤੋਂ ਵੱਧ ਦੂਰ ਹਨ ਤਾਂ ਤੁਸੀਂ ਦੋ ਵੱਖਰੇ ਯਤਨਾਂ ਦੀ ਤੁਲਨਾ ਕਰ ਰਹੇ ਹੋ।

ਫ਼ਰਕ ਕਿੱਥੇ ਚੀਜ਼ਾਂ ਤੋੜਦਾ ਹੈ

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

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

ਇਹ ਚਾਰ ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ ਅਤੇ ਪਹਿਲੀ ਫੇਲ੍ਹ 'ਤੇ ਰੁਕੋ:

• ਦੋਵੇਂ ਸਿਰਿਆਂ 'ਤੇ ਇੱਕੋ ਸਮੇਂ ਕੈਪਚਰ ਕਰੋ; ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸਰੋਤ ਪੋਰਟ, ਮੰਜ਼ਿਲ ਪੋਰਟ ਅਤੇ ਟਾਈਮਸਟੈਂਪ ਮਿਲਦੇ ਹਨ।
• ਤੁਸੀਂ ਜਿਸ ਪਤੇ ਦੀ ਆਸ ਕੀਤੀ ਸੀ ਉਹ ਨਹੀਂ, ਸਰਵਰ ਕੋਲ ਹੁਣ ਜੋ ਪਤਾ ਹੈ ਉਹ ਪੀਅਰ ਸੂਚੀ ਵਿੱਚ ਪੜ੍ਹੋ।
• ਐਂਟਰੀ ਅਤੇ ਉਸਦੀ ਬਾਕੀ ਉਮਰ conntrack ਜਾਂ NAT ਸਾਰਣੀ ਵਿੱਚ ਵੇਖੋ।
• ਕਲਾਇੰਟ 'ਤੇ ਟਨਲ ਇੰਟਰਫ਼ੇਸ ਦਾ ਪਤਾ LAN ਪਤਾ ਨਹੀਂ, ਸਰਵਰ ਵੱਲੋਂ ਦਿੱਤੇ ਨਾਲ ਮਿਲਦਾ ਹੈ ਇਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।

ਜੇ ਦੋਵੇਂ ਕੈਪਚਰ ਟਿਊਪਲ 'ਤੇ ਸਹਿਮਤ ਹਨ ਅਤੇ ਟਨਲ ਫਿਰ ਵੀ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਅਨੁਵਾਦ ਤੁਹਾਡੀ ਸਮੱਸਿਆ ਨਹੀਂ; ਹੈਂਡਸ਼ੇਕ ਅਤੇ ਟਨਲ ਦੇ ਅੰਦਰਲੀ ਰਾਊਟਿੰਗ ਸਾਰਣੀ ਵੱਲ ਵਧੋ।