OpenVPN client-connect ਹੁੱਕ: ਤੁਹਾਡਾ ਪਤਾ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ

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

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

ਹੁੱਕ ਫਾਈਲ ਲਿਖਦਾ ਹੈ, ਵਾਪਸੀ ਮੁੱਲ ਨਹੀਂ

ਐਲਾਨ ਦੋ ਲਾਈਨਾਂ ਦਾ ਹੈ: ਕਾਲ ਦੀ ਇਜਾਜ਼ਤ ਲਈ script-security 2, ਫਿਰ client-connect /etc/openvpn/server/assign-address.sh। ਜਦੋਂ ਕੋਈ ਕਲਾਇੰਟ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦਾ ਹੈ, ਸਰਵਰ ਉਹ ਸਕ੍ਰਿਪਟ ਬਣਾਏ ਗਏ ਫਾਈਲ ਪਾਥ ਨੂੰ ਆਖਰੀ ਆਰਗਿਊਮੈਂਟ ਵਜੋਂ ਜੋੜ ਕੇ ਚਲਾਉਂਦਾ ਹੈ, ਜੋ $1 ਸਿਰਫ਼ ਤਦ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਐਲਾਨ ਆਪਣੇ ਕੋਈ ਵਾਧੂ ਆਰਗਿਊਮੈਂਟ ਨਹੀਂ ਭੇਜਦਾ। ਉਸ ਕਲਾਇੰਟ ਉੱਤੇ ਲਾਗੂ ਹੋਣ ਵਾਲਾ ਹਰ ਚੀਜ਼ ਉਸ ਫਾਈਲ ਵਿੱਚ ਆਮ ਨਿਰਦੇਸ਼ਾਂ ਵਜੋਂ, ਹਰ ਲਾਈਨ ਵਿੱਚ ਇੱਕ, ਬਿਲਕੁਲ ਉਸੇ ਤਰ੍ਹਾਂ ਜਾਂਦੀ ਹੈ ਜਿਵੇਂ ਉਹ ਕਿਸੇ ਸੰਰਚਨਾ ਵਿੱਚ ਦਿਖਦੇ ਹਨ। ਆਪਣੇ ਪੈਰਾਮੀਟਰ ਜੋੜਨ ਵਾਲਾ ਰੈਪਰ ਸਥਿਤੀ ਨੂੰ ਖਿਸਕਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕਲਾਸਿਕ ਲੱਛਣ ਉਹ ਸਕ੍ਰਿਪਟ ਹੈ ਜੋ --verbose ਵਰਗਾ ਦਿਖਣ ਵਾਲੇ ਪਾਥ ਉੱਤੇ ਲਿਖਦੀ ਹੈ।

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

ਦੋ ਨਿਰਦੇਸ਼ ਧਿਆਨ ਦੇਣਯੋਗ ਹਨ ਕਿਉਂਕਿ ਉਹ ਬਾਕੀ ਸਭ ਨਾਲ ਪਰਸਪਰ ਕਿਰਿਆ ਕਰਦੇ ਹਨ। ifconfig-push ਪਤਾ ਤੈਅ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਭੇਜਿਆ route ਕਲਾਇੰਟ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਟਨਲ ਰਾਹੀਂ ਕੀ ਪਹੁੰਚਯੋਗ ਹੈ; ਪਹਿਲਾ ਵਾਪਸ ਦਿਓ ਅਤੇ ਦੂਜਾ ਭੁੱਲ ਜਾਓ ਤਾਂ ਤੁਹਾਨੂੰ ਪਤਾ ਹੈ ਪਰ ਜਾਣ ਦੀ ਥਾਂ ਨਹੀਂ ਵਾਲਾ ਕਲਾਇੰਟ ਮਿਲਦਾ ਹੈ। ਫਾਈਲ ਅੰਦਰ ਕ੍ਰਮ ਮਾਇਨੇ ਨਹੀਂ ਰੱਖਦਾ, ਪਰ ਪੂਰਨਤਾ ਰੱਖਦੀ ਹੈ। ਜੋ ਹੁੱਕ ਅਜਿਹੇ ਪ੍ਰੀਫਿਕਸ ਲਈ ਰੂਟ ਭੇਜਦਾ ਹੈ ਜਿੱਥੇ ਕੋਈ ਪੀਅਰ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ, ਉਹ ਦੂਜੇ ਸਿਰੇ ਤੋਂ ਦੇਖੀ ਗਈ ਉਹੀ ਗਲਤੀ ਹੈ।

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

ਪਤਾ ਮੈਪਿੰਗ ਇੱਕ ਨੀਤੀ ਹੈ, ਗਣਿਤ ਨਹੀਂ

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

ਜੋ ਨਾਮ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ ਉਹ ਪਤਾ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਤੈਅ ਕਰੋ ਕਿ ਇਸ ਤੈਨਾਤੀ ਵਿੱਚ common_name ਅਸਲ ਵਿੱਚ ਕੀ ਦਰਸਾਉਂਦਾ ਹੈ। username-as-common-name ਸਮਰੱਥ ਹੋਣ 'ਤੇ ਪਛਾਣ ਲੌਗਇਨ ਹੈ, ਸਰਟੀਫਿਕੇਟ ਦਾ ਵਿਸ਼ਾ ਨਹੀਂ। ਉਹ ਮੁੱਲ ਕਦੇ ਸ਼ੈੱਲ ਮੁਲਾਂਕਣ ਵਿੱਚ ਨਾ ਭੇਜੋ, ਅਤੇ ਕਲਾਇੰਟ ਨੂੰ ਕਦੇ ਫਾਈਲ ਪਾਥ ਉੱਤੇ ਪ੍ਰਭਾਵ ਨਾ ਪਾਉਣ ਦਿਓ।

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

ਟੋਪੋਲੋਜੀ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ifconfig-push ਦਾ ਕੀ ਅਰਥ ਹੈ

10.77.0.0/24 ਉੱਤੇ topology subnet ਨਾਲ, ifconfig-push 10.77.0.20 255.255.255.0 ਇੱਕ ਪਤਾ ਅਤੇ ਉਸ ਦਾ ਨੈੱਟਮਾਸਕ ਹੈ। topology net30 ਅਧੀਨ ਦੂਜਾ ਆਰਗਿਊਮੈਂਟ ਨੈੱਟਮਾਸਕ ਬਿਲਕੁਲ ਨਹੀਂ ਬਲਕਿ ਪੀਅਰ ਦਾ ਪਤਾ ਹੈ, ਇਸ ਲਈ ਸਬਨੈੱਟ ਸ਼ਕਲ ਨੂੰ net30 ਸਰਵਰ ਉੱਤੇ ਕਾਪੀ ਕਰਨ ਨਾਲ ਤੁਹਾਨੂੰ ਅਜਿਹਾ ਕਲਾਇੰਟ ਮਿਲਦਾ ਹੈ ਜੋ ਜੁੜਦਾ ਹੈ ਪਰ ਟ੍ਰੈਫਿਕ ਪਾਸ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਟੋਪੋਲੋਜੀ ਜਾਣ-ਬੁੱਝ ਕੇ ਬਦਲੋ, ਕਦੇ ਵੀ ਇਸ ਲਈ ਨਹੀਂ ਕਿ ਉਦਾਹਰਨ ਸੁਸੰਗਤ ਦਿਖੇ। ਜੋ ਸਰਵਰ ਪਹਿਲਾਂ ਹੀ net30 ਚਲਾ ਰਿਹਾ ਹੈ ਉਸ ਕੋਲ ਪੁਰਾਣੀ ਐਡਰੈਸਿੰਗ ਉੱਤੇ ਜੀਵਤ ਕਲਾਇੰਟ ਹਨ, ਇਸ ਲਈ ਬਦਲਾਅ ਰੱਖ-ਰਖਾਅ ਵਿੰਡੋ ਵਾਲਾ ਮਾਈਗ੍ਰੇਸ਼ਨ ਹੈ, ਇੱਕ ਲਾਈਨ ਦਾ ਸੰਪਾਦਨ ਨਹੀਂ।

ਸਥਿਰ ਪਤੇ ਗਤੀਸ਼ੀਲ ਪੂਲ ਤੋਂ ਬਾਹਰ ਅਤੇ ਹਰ ਦੂਜੇ ਸਥਿਰ ਅਲਾਟਮੈਂਟ ਤੋਂ ਬਾਹਰ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਆਮ client-config-dir ਫਾਈਲਾਂ ਰਾਹੀਂ ਦਿੱਤੇ ਪਤੇ ਵੀ ਸ਼ਾਮਲ ਹਨ। ਜੇ ਦੋ ਵਿਧੀਆਂ ਵੱਖ-ਵੱਖ ਕਲਾਇੰਟਾਂ ਲਈ ਇੱਕੋ ਪਤਾ ਪੈਦਾ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਅੰਤ ਵਿੱਚ ਅਜਿਹਾ ਜ਼ਰੂਰ ਕਰੇਗੀ।

ਇਸ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰ ਕੇਸ ਪਰਖੋ

ਉਹੀ ਜਾਂਚਾਂ ਮੈਪ ਕੀਤੀ ਪਛਾਣ, ਨਾ ਕੀਤੀ ਪਛਾਣ, ਦੁਬਾਰਾ ਕਨੈਕਸ਼ਨ ਅਤੇ ਨਕਲੀ ਰਜਿਸਟਰੀ ਫੇਲ੍ਹਤੇ ਉੱਤੇ ਚਲਾਓ। openvpn --config client.ovpn --verb 4 ਪੁਸ਼ ਜਵਾਬ ਵਿੱਚ ਅਲਾਟ ਕੀਤਾ ਪਤਾ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਉੱਤੇ grep -A2 PUSH_REPLY /var/log/openvpn/openvpn.log ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਭੇਜਿਆ ਗਿਆ। ਮੈਪ ਨਾ ਕੀਤੀ ਪਛਾਣ ਲਈ ਉਮੀਦ ਕੀਤਾ ਨਤੀਜਾ ਰੱਦ ਕੀਤਾ ਕਨੈਕਸ਼ਨ ਹੈ, ਪੂਲ ਦਾ ਪਤਾ ਨਹੀਂ।

ਫਿਰ ਉਹ ਡਾਇਰੈਕਟਰੀ ਵੇਖੋ ਜਿਸ ਵਿੱਚ ਡੀਮਨ ਉਹ ਅਸਥਾਈ ਫਾਈਲਾਂ ਲਿਖਦਾ ਹੈ। ਸਕ੍ਰਿਪਟ ਘਟਾਏ ਹੋਏ ਸੇਵਾ ਸੰਦਰਭ ਵਿੱਚ ਚੱਲਦੀ ਹੈ, ਇਸ ਲਈ ਜਿਸ ਪਾਥ ਵਿੱਚ root ਲਿਖ ਸਕਦਾ ਹੈ ਪਰ ਡੀਮਨ ਨਹੀਂ, ਉਹ ਹਰ ਕਨੈਕਸ਼ਨ ਨੂੰ ਲੌਗ ਵਿੱਚ ਕਈ ਲਾਈਨਾਂ ਹੇਠਾਂ ਦੱਬੀ ਇਜਾਜ਼ਤ ਗਲਤੀ ਨਾਲ ਰੱਦ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।

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