ਰੂਟ ਕੀਤਾ VPN ਕਲਾਇੰਟ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ ਪਰ LAN ਹੋਸਟਾਂ ਤੱਕ ਨਹੀਂ

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

ਬੇਨਤੀ ਨਹੀਂ, ਜਵਾਬ ਦਾ ਪਿੱਛਾ ਕਰੋ

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

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

ਰਿਟਰਨ ਰੂਟ ਉੱਥੇ ਰੱਖੋ ਜਿੱਥੇ ਹੋਸਟ ਦੇਖਦੇ ਹਨ

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

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

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

ਸਰੋਤ NAT ਇਸ ਨੂੰ ਠੀਕ ਕਰਦਾ ਕਿਉਂ ਦਿਖਦਾ ਹੈ

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

ਇਹ ਅਦਲਾ-ਬਦਲੀ ਕਈ ਵਾਰ ਸਹੀ ਹੁੰਦੀ ਹੈ, ਉਦਾਹਰਨ ਲਈ ਜਦੋਂ ਵਿਕਰੇਤਾ ਦੇ ਯੰਤਰ ਨੂੰ ਸਥਿਰ ਰੂਟ ਨਹੀਂ ਦਿੱਤਾ ਜਾ ਸਕਦਾ। ਨਿਯਮ ਨੂੰ ਮੌਜੂਦਾ ਪੂਲ ਤੋਂ ਚੌੜਾ ਨਾ ਬਣਾਓ, ਕਿਉਂਕਿ /24 ਲਈ ਲਿਖਿਆ ਨਿਯਮ ਉਸ ਦਿਨ ਮੇਲ ਖਾਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਪੂਲ ਨੂੰ /16 'ਤੇ ਮੁੜ-ਸੰਖਿਆ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਪਹਿਲਾ ਸੰਕੇਤ ਨਵੇਂ ਕਲਾਇੰਟਾਂ ਦਾ ਸਮੂਹ ਹੁੰਦਾ ਹੈ ਜੋ ਜੁੜਦੇ ਹਨ ਅਤੇ ਕਿਤੇ ਨਹੀਂ ਪਹੁੰਚਦੇ।

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

ਕਲਾਊਡ ਰਾਹ ਲਈ ਤਿੰਨ ਸੈਟਿੰਗਾਂ ਚਾਹੀਦੀਆਂ ਹਨ

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

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

ਜਾਂਚਾਂ ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ

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

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

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

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