VPN ਟਨਲ ਕਦੇ ਵੀ ਕਨੈਕਟ ਨਹੀਂ ਹੁੰਦੀ: ਪੈਕਟ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਰੁਕਦੇ ਹਨ

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

ਸਾਬਤ ਕਰੋ ਕਿ ਟ੍ਰੈਫਿਕ ਕਿੱਥੇ ਰੁਕਦਾ ਹੈ

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

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

ਪ੍ਰੋਟੋਕੋਲ 47 ਤੋਂ ਬਿਨਾਂ PPTP ਮਰ ਜਾਂਦੀ ਹੈ

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

ਪਾਸਥਰੂ ਇਨਬਾਊਂਡ ਫਾਰਵਰਡ ਦੀ ਉਲਟ ਦਿਸ਼ਾ ਵਿੱਚ ਚੱਲਦਾ ਹੈ, ਅਤੇ ਫਰਮਵੇਅਰ ਅਕਸਰ ਦੋਵਾਂ ਲਈ ਇੱਕੋ ਲੇਬਲ ਵਰਤਦਾ ਹੈ, ਜੋ ਸਭ ਨੂੰ ਉਲਝਾਉਣ ਲਈ ਕਾਫ਼ੀ ਹੈ। Linux ਕਲਾਇੰਟ 'ਤੇ ਸਥਾਨਕ ਫਾਇਰਵਾਲ ਰਾਊਟਰ ਦੇ ਸ਼ਾਮਲ ਹੋਣ ਤੋਂ ਬਹੁਤ ਪਹਿਲਾਂ GRE ਸੁੱਟ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਪ੍ਰੋਟੋਕੋਲ 47 ਨੂੰ ਆਪਣਾ ਨਿਯਮ ਚਾਹੀਦਾ ਹੈ ਅਤੇ conntrack ਸਹਾਇਕ ਲੋਡ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਬੰਟੂ ਦਾ ufw ਇਹ ਨਿਯਮ before ਫਾਈਲ ਵਿੱਚ ਰੱਖਦਾ ਹੈ, ਕਿਉਂਕਿ ਆਮ allow ਨਿਯਮ ਪ੍ਰੋਟੋਕੋਲ ਨੰਬਰ ਨਹੀਂ ਦੱਸ ਸਕਦੇ। ਬਾਅਦ ਵਿੱਚ ਮਸ਼ੀਨ ਨੂੰ ਰੀਬੂਟ ਕਰਨ ਦੀ ਬਜਾਏ ਫਾਇਰਵਾਲ ਦੁਬਾਰਾ ਲੋਡ ਕਰੋ।

# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep gre

ਦੋ NAT ਪਿੱਛੇ L2TP ਅਤੇ IPsec

L2TP IPsec ਦੇ ਅੰਦਰ ਕੁੰਜੀ ਅਦਲਾ-ਬਦਲੀ ਲਈ UDP 500, NAT ਪਛਾਣੇ ਜਾਣ 'ਤੇ UDP 4500, ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ 50 ਵਜੋਂ ESP ਚਾਹੀਦਾ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਫਿਲਟਰ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਇੱਕ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲਾ ਨਿਯਮ ਬਾਕੀ ਦੋ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। ਲੜੀ ਵਿੱਚ ਦੋ ਰਾਊਟਰ ਹਰ ਪੈਕਟ ਦਾ ਦੋ ਵਾਰ ਅਨੁਵਾਦ ਕਰਦੇ ਹਨ, ਅਤੇ ਸਿਰੇ ਹੁਣ ਇਸ ਗੱਲ 'ਤੇ ਸਹਿਮਤ ਨਹੀਂ ਕਿ ਕੀ ਤੈਅ ਹੋਇਆ ਸੀ।

ਬਾਹਰਲੇ ਮਾਡਮ ਨੂੰ ਬ੍ਰਿਜ ਕਰੋ, ਜਾਂ ਅੰਦਰਲੇ ਰਾਊਟਰ 'ਤੇ NAT ਬੰਦ ਕਰੋ, ਤਾਂ ਜੋ ਜਨਤਕ ਪਤਾ ਟਨਲ ਖਤਮ ਕਰਨ ਵਾਲੇ ਯੰਤਰ ਤੱਕ ਪਹੁੰਚੇ। ਜਿੱਥੇ ਦੋਵੇਂ ਸੰਭਵ ਨਾ ਹੋਣ, ਟਨਲ ਡਬਲ NAT ਸੀਮਾ ਦੇ ਅੰਦਰੋਂ ਸ਼ੁਰੂ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਉੱਥੇ ਖਤਮ ਨਹੀਂ।

ਕੈਰੀਅਰ ਨੈੱਟਵਰਕ ਅਤੇ ਪਤਾ ਸਾਂਝ

WAN ਪਤਾ 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 ਜਾਂ 100.64.0.0/10 ਦੇ ਅੰਦਰ ਹੋਣ ਦਾ ਅਰਥ ਹੈ ਕਿ ਰਾਊਟਰ ਕੋਲ ਕੋਈ ਜਨਤਕ ਪਤਾ ਨਹੀਂ ਹੈ ਅਤੇ ਇੰਟਰਨੈੱਟ ਤੋਂ ਕੋਈ ਇਨਬਾਊਂਡ ਫਾਰਵਰਡ ਉਸ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ। ਕੈਰੀਅਰ-ਗ੍ਰੇਡ NAT ਉਹ ਪ੍ਰੋਟੋਕੋਲ ਵੀ ਫਿਲਟਰ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਉਹ ਆਸ ਨਹੀਂ ਰੱਖਦਾ, ਅਤੇ ਮੋਬਾਈਲ ਲਿੰਕਾਂ 'ਤੇ GRE ਅਕਸਰ ਸ਼ਿਕਾਰ ਹੁੰਦਾ ਹੈ। ਰਾਊਟਰ 'ਤੇ ਹੀ WAN ਪਤੇ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਉਸ ਪਤੇ ਨਾਲ ਨਹੀਂ ਜੋ ਕੋਈ ਲੁੱਕਅੱਪ ਸਾਈਟ ਉਸਦੇ ਪਿੱਛੇ ਵਾਲੇ ਕਲਾਇੰਟ ਲਈ ਦੱਸਦੀ ਹੈ।

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

ਪੋਰਟ ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਰੋਤਿਆਂ ਦੀ ਸੂਚੀ ਪੜ੍ਹੋ

ਚਿੰਤਾ ਭਰਿਆ ਪੋਰਟ ਸਕੈਨ ਅਕਸਰ ਸਿਰਫ਼ ਉਹ ਫੀਚਰ ਸੈੱਟ ਹੁੰਦਾ ਹੈ ਜੋ ਚਾਲੂ ਹਾਲਤ ਵਿੱਚ ਆਉਂਦਾ ਹੈ। ਸਰੋਤਿਆਂ ਦੀ ਸੂਚੀ ਬਣਾਓ, ਹਰ ਸਾਕਟ ਨੂੰ ਫੀਚਰ ਨਾਲ ਜੋੜੋ, ਫਿਰ ਪੋਰਟ ਬਲਾਕ ਕਰਨ ਦੀ ਬਜਾਏ ਫੀਚਰ ਬੰਦ ਕਰੋ, ਤਾਂ ਜੋ ਦੋਵੇਂ ਦ੍ਰਿਸ਼ ਵੱਖ ਨਾ ਹੋਣ।

ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500

SoftEther ਦੇ ਡਿਫਾਲਟ ਚੰਗਾ ਉਦਾਹਰਨ ਹਨ: TCP 443, 992 ਅਤੇ 5555, ਨਾਲ ਹੀ L2TP/IPsec ਅਤੇ DNS-ਟਨਲ ਫੀਚਰ ਆਪਣੇ ਸਾਕਟ ਜੋੜਦੇ ਹਨ। ਉਹ ਫੀਚਰ ਬੰਦ ਕਰਨ ਨਾਲ ਸਰੋਤੇ ਲੁਕਣ ਦੀ ਬਜਾਏ ਹਟ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਬਾਹਰਲੇ ਹੋਸਟ ਤੋਂ ਜਾਂਚ ਦੱਸਦੀ ਹੈ ਕਿ ਕੈਰੀਅਰ ਪੋਰਟ ਨੂੰ ਆਉਣ ਦਿੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਸਰੋਤਾ ਉੱਪਰ ਵੱਲ ਬੰਦ ਹੋ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਰਾਊਟਰ ਦੇ ਆਪਣੇ WAN ਪਤੇ ਦੀ ਤੁਲਨਾ ਬਾਹਰੀ ਸੇਵਾ ਦੇ ਦੱਸੇ ਨਾਲ ਕਰੋ।