ਸਥਿਰ OpenVPN ਪਤੇ ਸਰੋਤ IP ਨਹੀਂ, ਪਛਾਣ ਦੀ ਪਾਲਣਾ ਕਰਨ

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

ਸ਼ੁਰੂ ਉਸ ਤੋਂ ਕਰੋ ਜੋ ਸਰਵਰ ਪ੍ਰਮਾਣਿਤ ਕਰ ਸਕਦਾ ਹੈ, ਫਿਰ ਤੈਅ ਕਰੋ ਕਿ ਪਤਾ ਕਿਸ ਲਈ ਹੈ।

ਪਤੇ ਤੋਂ ਪਹਿਲਾਂ ਪਛਾਣ ਦੀ ਕੁੰਜੀ ਚੁਣੋ

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

duplicate-cn ਨਾਲ, ਕਈ ਇਕੱਠੇ ਚੱਲ ਰਹੇ ਸੈਸ਼ਨ ਇੱਕੋ ਆਮ ਨਾਮ ਪੇਸ਼ ਕਰ ਸਕਦੇ ਹਨ, ਇਸ ਲਈ ਇੱਕ ਪਿੰਨ ਕੀਤਾ ਪਤਾ ਉਹਨਾਂ ਨੂੰ ਵੱਖਰੇ ਤੌਰ ’ਤੇ ਨਹੀਂ ਪਛਾਣ ਸਕਦਾ। ਇਹ ਪਛਾਣ ਮਾਡਲ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ, ਅਜਿਹੀ ਚੀਜ਼ ਨਹੀਂ ਜੋ ਬਿਹਤਰ ਪਤਾ ਯੋਜਨਾ ਠੀਕ ਕਰ ਸਕੇ।

ਗਤੀਸ਼ੀਲ ਰੇਂਜ ਤੋਂ ਬਾਹਰ ਪਤੇ ਰਾਖਵੇਂ ਰੱਖੋ

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

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

ਅਲਾਟਮੈਂਟ ਦੀ ਤਰਜੀਹ ਤੈਅ ਕਰਦੀ ਹੈ ਕੌਣ ਜਿੱਤੇਗਾ

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

ਅਲਾਟਮੈਂਟਾਂ ਦੀ ਮਾਲਕੀ ਇੱਕ ਪਰਤ ਨੂੰ ਦਿਓ ਅਤੇ ਬਾਕੀ ਨੂੰ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਯੋਗ ਬਣਾਓ। ਦੋਵੇਂ ਫੈਸਲੇ ਦਾ ਦਾਅਵਾ ਕਰਨ ਵਾਲੀਆਂ ਦੋ ਪਰਤਾਂ ਸਮਾਂ-ਨਿਰਭਰ ਅਲਾਟਮੈਂਟਾਂ ਬਣਾਉਂਦੀਆਂ ਹਨ।

ਗਤੀਸ਼ੀਲ ਅਲਾਟਕਰ ਨੂੰ ਵੀ ਉਹੀ ਮਾਡਲ ਚਾਹੀਦਾ ਹੈ

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

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

ਤੈਅ ਕਰੋ ਕਿ ਪਤਾ ਨੀਤੀ ਹੈ ਜਾਂ ਸਹੂਲਤ

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

ਯੋਜਨਾ ਨੂੰ ਹਰ ਐਂਟਰੀ ਲਈ ਮਾਲਕ ਵਾਲੀ ਸੂਚੀ ਵਜੋਂ ਲਿਖੋ, ਫਿਰ ਜਦੋਂ ਡਿਵਾਈਸ ਸੇਵਾਮੁਕਤ ਹੋਵੇ ਤਾਂ ਇਸਦੀ ਸਮੀਖਿਆ ਕਰੋ। ਨਾ-ਵਰਤਿਆ ਰਾਖਵਾਂਕਣ ਹੀ ਹੈ ਜੋ ਗਲਤੀ ਨਾਲ ਦੁਬਾਰਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।