ਦਿੱਤੇ ਗਏ ਵਰਚੁਅਲ IP 'ਤੇ IKEv2 ਕਲਾਇੰਟ ਤੱਕ ਪਹੁੰਚਣਾ

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

ਟਨਲ ਸਰੋਤ ਪਤਾ ਠੀਕ ਨਹੀਂ ਕਰਦੀ

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

ਕਲਾਇੰਟ ਵੱਲ ਰਾਊਟਿੰਗ ਜ਼ਰੂਰੀ ਹੈ ਅਤੇ ਕਾਫ਼ੀ ਨਹੀਂ। ਨੀਤੀ ਨੂੰ ਉਹ ਸਰੋਤ ਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਵਰਤਿਆ।

ਸਥਾਪਿਤ ਨੀਤੀ ਪੜ੍ਹੋ, ਕਾਨਫਿਗ ਫਾਈਲ ਨਹੀਂ

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

ipsec statusall
ip xfrm policy

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

ਕਲਾਇੰਟ ਨੂੰ ਉੱਥੇ ਹੀ ਸੁਣਨਾ ਚਾਹੀਦਾ ਹੈ ਜਿੱਥੇ ਪੈਕੇਟ ਪਹੁੰਚਦਾ ਹੈ

ਸੇਵਾ ਸਿਰਫ਼ ਲੂਪਬੈਕ ਨਾਲ ਬੱਝੀ ਹੋਵੇ ਤਾਂ ਸੰਪੂਰਨ ਨੀਤੀ ਵੀ ਬੰਦ ਪੋਰਟ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ। ਸਰੋਤੇ ਨੂੰ ਦਿੱਤੇ ਪਤੇ 'ਤੇ ਜਾਂ ਸਥਾਨਕ ਵਾਈਲਡਕਾਰਡ ਪਤੇ 'ਤੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ss -ltnp 'sport = :9090'
iptables -S INPUT

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

ਨਵੀਂ ਦਿਸ਼ਾ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਜਾਂਚੋ

ਕਲਾਇੰਟ ਤੋਂ ਸਰਵਰ ਤੱਕ ਸਫਲ ਬੇਨਤੀ ਇਸ ਰਾਹ ਨੂੰ ਕਦੇ ਨਹੀਂ ਵਰਤਦੀ। ਗੇਟਵੇ ਤੋਂ ਬੇਨਤੀ ਬਣਾਓ ਅਤੇ ਦੋਵੇਂ ਸਿਰੇ ਵੇਖੋ।

ip route get 10.90.0.42 from 192.168.50.1
tcpdump -ni any host 10.90.0.42 and tcp port 9090

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

ਕੁੰਜੀ ਬਦਲਣ ਜਾਂ ਦੁਬਾਰਾ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਟੈਸਟ ਦੁਹਰਾਓ, ਕਿਉਂਕਿ VIP ਬਦਲ ਸਕਦਾ ਹੈ। ਜੋ ਰਾਹ ਸਿਰਫ਼ ਅਗਲੇ ਸੈਸ਼ਨ ਤੱਕ ਕੰਮ ਕਰੇ ਉਹ ਕੰਮ ਕਰਨ ਵਾਲਾ ਰਾਹ ਨਹੀਂ ਹੈ।