OpenVPN ਕਲਾਇੰਟ ਗੇਟਵੇ ਦੇ IPsec ਚੋਣਕਾਰ ਕਿਉਂ ਖੁੰਝ ਜਾਂਦੇ ਹਨ

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

ਗੇਟਵੇ ਦਾ ping ਉਹ ਪ੍ਰਵਾਹ ਜਾਂਚਦਾ ਹੈ ਜੋ ਤੁਹਾਡਾ ਕਲਾਇੰਟ ਕਦੇ ਨਹੀਂ ਵਰਤਦਾ

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

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

ਉਹ ਦੂਰਲਾ ਪ੍ਰੀਫਿਕਸ ਪੁਸ਼ ਕਰੋ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸੱਚਮੁੱਚ ਚਾਹੀਦਾ ਹੈ

ਜੁੜੇ ਕਲਾਇੰਟ ਲਈ 10.8.0.0/24 ਅਤੇ ਸੁਰੱਖਿਅਤ ਦੂਰਲੇ ਨੈੱਟਵਰਕ ਲਈ 172.30.239.0/25 ਦੀ ਇਹ ਉਦਾਹਰਨ ਜੋੜੀ ਲਓ। ਕਲਾਇੰਟ ਨੂੰ ਉਸ ਦੂਜੇ ਪ੍ਰੀਫਿਕਸ ਦਾ ਰੂਟ ਚਾਹੀਦਾ ਹੈ, ਗੇਟਵੇ ਦੇ LAN ਦਾ ਨਹੀਂ ਅਤੇ ਕਿਸੇ ਹੋਰ ਟਨਲ ਪਤੇ ਦਾ ਵੀ ਨਹੀਂ। ਪੂਲ ਵਿੱਚ ਪੁਸ਼ ਕੀਤਾ ਰੂਟ ਹੀ ਕਲਾਇੰਟ ਨੂੰ ਉਹ ਟ੍ਰੈਫਿਕ ਗੇਟਵੇ ਨੂੰ ਸੌਂਪਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ। ਇਸ ਤੋਂ ਬਿਨਾਂ ਪੈਕੇਟ ਕਦੇ ਵੀ ਉਸ ਨੀਤੀ-ਫ਼ੈਸਲੇ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ ਜੋ ਤੁਸੀਂ ਡੀਬੱਗ ਕਰ ਰਹੇ ਹੋ।

ਜੋ Community ਸਰਵਰ ਪੁਸ਼ ਕੀਤੇ ਰੂਟ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਉੱਥੇ ਨਿਰਦੇਸ਼ ਅਸਲੀ ਮਾਸਕ ਲੈਂਦਾ ਹੈ: push "route 172.30.239.0 255.255.255.128"। Access Server ਉਹੀ ਮੰਜ਼ਿਲ ਇੰਸਟਾਲ ਕੀਤੇ ਸੰਸਕਰਣ ਦੀਆਂ ਪ੍ਰਾਈਵੇਟ-ਨੈੱਟਵਰਕ ਜਾਂ ਐਕਸੈਸ-ਰੂਲ ਸੈਟਿੰਗਾਂ ਰਾਹੀਂ ਕੌਂਫਿਗਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਰਾਊਟਿਡ ਜਾਂ ਅਨੁਵਾਦਿਤ ਮੋਡ ਜਾਣ-ਬੁੱਝ ਕੇ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ। ਮਾਲਕ ਕੌਂਫਿਗਰੇਸ਼ਨ ਦੀ ਥਾਂ ਬਣੇ ਹੋਏ ਫਾਇਰਵਾਲ ਚੇਨ ਸੋਧਣਾ ਹੀ ਉਹ ਰਾਹ ਹੈ ਜਿਸ ਨਾਲ ਕੰਮ ਕਰਦਾ ਸੈਟਅੱਪ ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਅਸੰਭਵ ਹੋ ਜਾਂਦਾ ਹੈ।

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

ਚੋਣਕਾਰਾਂ ਵਿੱਚ ਕਲਾਇੰਟ ਪੂਲ ਸ਼ਾਮਲ ਕਰੋ

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

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

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

ਜਾਣ-ਬੁੱਝ ਕੇ ਰੂਟਿੰਗ ਜਾਂ ਅਨੁਵਾਦ ਚੁਣੋ

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

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

ਫਾਰਵਰਡਿੰਗ ਅਤੇ ਜਵਾਬ ਉੱਤੇ ਲੂਪ ਬੰਦ ਕਰੋ

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

ਇੱਕ ਅਸਲੀ ਕਲਾਇੰਟ-ਤੋਂ-ਐਪਲੀਕੇਸ਼ਨ ਬੇਨਤੀ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ, ਅਤੇ ਵੇਖੋ ਕਿ ਉਹ OpenVPN ਇੰਟਰਫੇਸ, IPsec ਫ਼ੈਸਲੇ ਅਤੇ ਦੂਰਲੇ ਹੋਸਟ ਵਿੱਚੋਂ ਲੰਘਦੀ ਹੈ। ਜਵਾਬ ਨੂੰ ਵੱਖਰੇ ਨਿਰੀਖਣ ਵਜੋਂ ਵੇਖੋ, ਕਿਉਂਕਿ ਪਹੁੰਚਦੀ ਬੇਨਤੀ ਅਤੇ ਕਦੇ ਨਾ ਮੁੜਨ ਵਾਲਾ ਜਵਾਬ ਕਲਾਇੰਟ ਦੀ ਥਾਂ ਤੋਂ ਇੱਕੋ ਜਿਹੇ ਦਿਸਦੇ ਹਨ। ਇੱਕ ਟ੍ਰੇਸ ਕੀਤੀ ਬੇਨਤੀ ਗੇਟਵੇ ਦੇ ਕਿੰਨੇ ਵੀ ping ਨਾਲੋਂ ਵੱਧ ਕੀਮਤੀ ਹੈ।

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