OpenVPN tls-crypt-v2: ਕਲਾਇੰਟ ਕੁੰਜੀ ਅਤੇ ਲਪੇਟਿਆ blob ਕੀ ਕਰਦੇ ਹਨ
tls-crypt-v2 ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਕਲਾਇੰਟ ਦੀ ਨਿਯੰਤਰਣ ਕੁੰਜੀ ਅਤੇ ਸਿਰਫ਼ ਸਰਵਰ ਖੋਲ੍ਹ ਸਕਣ ਵਾਲੀ ਲਪੇਟੀ ਨਕਲ ਹੁੰਦੀ ਹੈ। ਹਰ ਵਸਤੂ ਅਤੇ ਹਟਾਉਣ ਦਾ ਹਰ ਕਦਮ ਵੱਖਰਾ ਰੱਖੋ।
tls-crypt-v2 ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਟਿਕਟ ਵਿੱਚ ਚਿਪਕਾਉਣਾ, ਫ਼ਾਈਲ ਵਿੱਚ ਕੀ ਹੈ ਇਹ ਗਿਣਨ ਤੱਕ ਬੇਨੁਕਸਾਨ ਜਾਪਦਾ ਹੈ। ਕਲਾਇੰਟ ਦੀ ਨਿਯੰਤਰਣ-ਚੈਨਲ ਕੁੰਜੀ ਉਸੇ ਕੁੰਜੀ ਦੀ ਐਨਕ੍ਰਿਪਟਿਡ ਨਕਲ ਦੇ ਕੋਲ ਬੈਠਦੀ ਹੈ, ਅਤੇ ਤੀਜੀ ਵਸਤੂ, ਲਪੇਟਣ ਵਾਲੀ ਕੁੰਜੀ, ਸਵੀਕਾਰ ਕਰਨ ਵਾਲੇ ਸਰਵਰ ਨੂੰ ਕਦੇ ਨਹੀਂ ਛੱਡਦੀ। ਇਹ ਤਿੰਨੇ ਹਿਰਾਸਤ, ਸਾਂਝ ਅਤੇ ਹਟਾਉਣ ਬਾਰੇ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ। ਇਹਨਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖਣਾ ਬਹੁਤੀਆਂ ਨੀਤੀ ਬਹਿਸਾਂ ਨੂੰ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਨਿਪਟਾ ਦਿੰਦਾ ਹੈ।
ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਅਸਲ ਵਿੱਚ ਕੀ ਹੈ
tls-crypt-v2 ਦਾ ਕਲਾਇੰਟ ਅੱਧ ਇੱਕ ਕੁੰਜੀ ਅਤੇ ਉਸਦੀ ਲਪੇਟੀ ਨਕਲ ਹੈ। ਕਲਾਇੰਟ ਨਿਯੰਤਰਣ-ਚੈਨਲ ਦੀ ਸੁਰੱਖਿਆ ਲਈ ਸਾਦੀ ਕੁੰਜੀ ਵਰਤਦਾ ਹੈ ਅਤੇ ਸੈਟਅੱਪ ਦੌਰਾਨ ਲਪੇਟੀ ਨਕਲ ਸਰਵਰ ਨੂੰ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਜੋ ਸਰਵਰ ਹਰ ਕਲਾਇੰਟ ਲਈ ਸਪਸ਼ਟ ਨਕਲ ਸੰਭਾਲੇ ਬਿਨਾਂ ਉਹੀ ਕੁੰਜੀ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰੇ। ਲਪੇਟਣ ਵਾਲੀ ਕੁੰਜੀ ਉਹ ਮੁੜ ਪ੍ਰਾਪਤੀ ਸੰਭਵ ਬਣਾਉਂਦੀ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲੇ ਪਾਸੇ ਦੀ ਹੁੰਦੀ ਹੈ। ਹੇਠਾਂ ਸਭ ਕੁਝ ਇਸ ਗੱਲ ਤੋਂ ਆਉਂਦਾ ਹੈ ਕਿ ਉਹ ਤਿੰਨੇ ਵਸਤੂਆਂ ਕਿੱਥੇ ਰਹਿੰਦੀਆਂ ਹਨ।
| Object | Where it lives | What can open it | What a leak costs |
|---|---|---|---|
| Server wrapping key | accepting servers only | the unwrap step inside the server | every wrapped copy issued to that group becomes readable |
| Wrapped client key | inside the client profile | the server wrapping key | it names a client and exposes its metadata, but not the key inside |
| Client control key | inside the client profile, usable as-is | the client that owns it | someone can open handshakes as that client until the server refuses the key |
ਸਾਰਣੀ ਨੂੰ ਨਾਮ ਨਾਲ ਨਹੀਂ, ਹਿਰਾਸਤ ਨਾਲ ਪੜ੍ਹੋ ਅਤੇ ਨਤੀਜੇ ਆਪਣੇ ਆਪ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦੇ ਹਨ। ਲਪੇਟਣ ਵਾਲੀ ਕੁੰਜੀ ਗੁਆਉਣਾ ਮਹਿੰਗੀ ਘਟਨਾ ਹੈ, ਕਿਉਂਕਿ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਕੁਝ ਵੀ ਉਸਨੂੰ ਮੁੜ ਨਹੀਂ ਬਣਾ ਸਕਦਾ ਅਤੇ ਇਮਾਨਦਾਰ ਮੁੜ ਪ੍ਰਾਪਤੀ ਸਮੂਹ ਨੂੰ ਦੁਬਾਰਾ ਜਾਰੀ ਕਰਨਾ ਹੈ। ਲੀਕ ਹੋਇਆ ਪ੍ਰੋਫਾਈਲ ਸਸਤਾ ਪਰ ਬਹੁਤ ਆਮ ਹੈ, ਕਿਉਂਕਿ ਲੋਕ ਟਿਕਟਾਂ ਵਿੱਚ ਪ੍ਰੋਫਾਈਲ ਚਿਪਕਾਉਂਦੇ ਹਨ ਇਹ ਮੰਨ ਕੇ ਕਿ ਲਪੇਟੀ ਨਕਲ ਫ਼ਾਈਲ ਨੂੰ ਸਾਂਝਾ ਕਰਨ ਲਈ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੀ ਹੈ। ਦੋਵੇਂ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਵੱਖਰੇ ਜਵਾਬ ਚਾਹੀਦੇ ਹਨ, ਇਸ ਲਈ ਵਸਤੂਆਂ ਵੱਖਰੀਆਂ ਰੱਖੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
ਲਪੇਟੀ ਨਕਲ ਪੂਰੀ ਕਹਾਣੀ ਕਿਉਂ ਨਹੀਂ ਹੈ
ਪ੍ਰੋਫਾਈਲ ਵਰਤੋਂਯੋਗ ਕਲਾਇੰਟ ਸਮੱਗਰੀ ਨੂੰ ਆਪਣੇ ਲਪੇਟੇ ਸਾਥੀ ਸਮੇਤ ਲੈ ਕੇ ਚੱਲਦਾ ਹੈ, ਇਸ ਲਈ ਸਰਵਰ ਲਈ ਨਕਲ ਦੀ ਸੁਰੱਖਿਆ ਫ਼ਾਈਲ ਦੀ ਸੁਰੱਖਿਆ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ। Blob ਭੇਜਣ ਲਈ ਸੁਰੱਖਿਅਤ ਅਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਲਈ ਅਸੁਰੱਖਿਅਤ ਹੈ। ਇਸਦੇ ਅੰਦਰਲਾ ਮੈਟਾਡੇਟਾ blob ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਹਰ ਵਿਅਕਤੀ ਨੂੰ ਦਿਸਦਾ ਹੈ, ਉਸ ਨੂੰ ਵੀ ਜੋ ਬਾਅਦ ਵਿੱਚ ਉਹ ਟਿਕਟ ਪੜ੍ਹੇਗਾ ਜਿਸ ਵਿੱਚ ਇਹ ਚਿਪਕਾਇਆ ਗਿਆ ਸੀ।
ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਕਨਫਿਗਰੇਸ਼ਨ ਨਮੂਨਾ ਨਹੀਂ, ਸ਼ਨਾਖਤ ਮੰਨੋ। ਲੀਕ ਹੋਈ ਫ਼ਾਈਲ ਆਪਣੇ ਧਾਰਕ ਨੂੰ ਕੰਮ ਕਰਦੀ ਕਲਾਇੰਟ ਪਛਾਣ ਦਿੰਦੀ ਹੈ ਜਦ ਤੱਕ ਸਰਵਰ ਉਹ ਪਛਾਣ ਸਵੀਕਾਰ ਕਰਨਾ ਬੰਦ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਲਪੇਟਣਾ ਉਸ ਖਿੜਕੀ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਰਦਾ। ਹਰ ਕਲਾਇੰਟ ਲਈ ਇੱਕ ਪ੍ਰੋਫਾਈਲ ਜਾਰੀ ਕਰੋ ਤਾਂ ਜੋ ਵਾਪਸ ਲੈਣਾ ਇੱਕ-ਫ਼ਾਈਲ ਦਾ ਫ਼ੈਸਲਾ ਰਹੇ, ਅਤੇ ਲਪੇਟਣ ਵਾਲੀ ਕੁੰਜੀ ਦਾ ਬੈਕਅੱਪ ਉਸ ਸਰਵਰ ਕਨਫਿਗਰੇਸ਼ਨ ਤੋਂ ਵੱਖਰਾ ਰੱਖੋ ਜਿਸਨੂੰ ਇਹ ਸਮਰੱਥ ਬਣਾਉਂਦੀ ਹੈ। ਦੋਵੇਂ ਆਦਤਾਂ ਛੇੜੇ ਹੋਏ ਪ੍ਰੋਫਾਈਲ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਦੀਆਂ, ਪਰ ਦੋਵੇਂ ਤੈਅ ਕਰਦੀਆਂ ਹਨ ਕਿ ਅਗਲਾ ਕਿੰਨੀ ਜਲਦੀ ਕਾਬੂ ਵਿੱਚ ਆਵੇਗਾ।
ਹੈਂਡਸ਼ੇਕ ਵਿੱਚ ਤਸਦੀਕ ਹੁੱਕ ਕਿੱਥੇ ਬੈਠਦਾ ਹੈ
ਤਸਦੀਕ ਹੁੱਕ TLS ਸਟੈਕ ਖੁੱਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਚੱਲਦਾ ਹੈ, ਅਤੇ ਇਸਦਾ ਕੰਮ ਲਪੇਟੇ blob ਵਿੱਚ ਲਿਜਾਇਆ ਮੈਟਾਡੇਟਾ ਦੀ ਜਾਂਚ ਕਰਨਾ ਹੈ। ਇਸਨੂੰ ਉਹ ਮੈਟਾਡੇਟਾ ਅਤੇ ਛੋਟਾ, ਦਸਤਾਵੇਜ਼ੀ ਵਾਤਾਵਰਣ ਮਿਲਦਾ ਹੈ, ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਹੁੱਕ ਨਾਲੋਂ ਇਸ ਕੋਲ ਕੰਮ ਕਰਨ ਲਈ ਘੱਟ ਸਮੱਗਰੀ ਹੁੰਦੀ ਹੈ। ਇਹ ਮੰਨਣਾ ਕਿ ਇਹ ਵਰਤੋਂਕਾਰ ਨਾਮ, ਸੈਸ਼ਨ ਸਥਿਤੀ ਜਾਂ ਪਲੱਗਇਨ ਚਲ ਦੇਖ ਸਕਦਾ ਹੈ, ਇਸ ਹੁੱਕ ਨੂੰ ਮਾੜੇ ਢੰਗ ਨਾਲ ਲਿਖਣ ਦਾ ਆਮ ਤਰੀਕਾ ਹੈ। ਕਿਸੇ ਹੋਰ ਹੁੱਕ ਤੋਂ ਉਮੀਦਾਂ ਉਧਾਰ ਲੈਣ ਦੀ ਥਾਂ ਹੁੱਕ ਦਾ ਆਪਣਾ ਦਸਤਾਵੇਜ਼ੀ ਭਾਗ ਪੜ੍ਹੋ।
ਇਸਦੀ ਨਿਕਾਸ ਸਥਿਤੀ ਫ਼ੈਸਲਾ ਹੈ: ਗੈਰ-ਸਿਫ਼ਰ ਨਤੀਜਾ ਕਲਾਇੰਟ ਨੂੰ ਰੱਦ ਕਰਦਾ ਹੈ ਅਤੇ ਸਿਫ਼ਰ ਨਤੀਜਾ ਹੈਂਡਸ਼ੇਕ ਜਾਰੀ ਰੱਖਣ ਦਿੰਦਾ ਹੈ। ਇਸ ਲਈ ਨੀਤੀ ਨੂੰ ਦੱਸਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਮੈਟਾਡੇਟਾ ਗੁੰਮ, ਪਾਰਸ ਨਾ ਹੋਣ ਯੋਗ ਜਾਂ ਅਚਾਨਕ ਹੋਣ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ। ਪਹਿਲਾਂ ਰੱਦ ਕਰਨ ਦਾ ਰਾਹ ਲਿਖੋ, ਫਿਰ ਤੈਅ ਕਰੋ ਕਿ ਕਿਹੜੇ ਮੁੱਲ ਸਵੀਕਾਰਯੋਗ ਹਨ।
tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.shਉਹ ਦੋ ਲਾਈਨਾਂ ਸਰਵਰ 'ਤੇ ਨੀਤੀ ਦੀ ਸਤ੍ਹਾ ਹਨ: ਇੱਕ ਲਪੇਟਣ ਵਾਲੀ ਕੁੰਜੀ ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੈ, ਦੂਜੀ ਹਰ ਕਲਾਇੰਟ ਦਾ ਫ਼ੈਸਲਾ ਕਰਨ ਵਾਲੇ ਪ੍ਰੋਗਰਾਮ ਦਾ। ਦਿਲਚਸਪ ਸਭ ਕੁਝ ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਹੈ, ਜੋ ਸੰਸਕਰਣ ਨਿਯੰਤਰਣ ਅਤੇ ਕਿਸੇ ਵੀ ਹੋਰ ਪਹੁੰਚ ਨਿਯਮ ਵਾਂਗ ਸਮੀਖਿਆ ਦਾ ਹੱਕਦਾਰ ਹੈ।
ਖਾਤਾ, ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਨਿਯੰਤਰਣ ਕੁੰਜੀ ਵੱਖਰੇ ਹਟਦੇ ਹਨ
ਨਿਯੰਤਰਣ-ਚੈਨਲ ਦੀ ਜਲਦੀ ਸਵੀਕ੍ਰਿਤੀ ਪ੍ਰਮਾਣਿਕਤਾ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਇਹ TLS ਪਛਾਣ ਜਾਂਚ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਕਿਸੇ ਵੀ ਖਾਤਾ ਅਧਿਕਾਰ ਤੋਂ ਪਹਿਲਾਂ ਹੁੰਦੀ ਹੈ। ਖਾਤਾ ਬੰਦ ਕਰਨਾ, ਸਰਟੀਫਿਕੇਟ ਰੱਦ ਕਰਨਾ ਅਤੇ ਕਲਾਇੰਟ ਨਿਯੰਤਰਣ ਕੁੰਜੀ ਨੂੰ ਰੱਦ ਕਰਨਾ ਤਿੰਨ ਵਿਧੀਆਂ ਵਾਲੀਆਂ ਤਿੰਨ ਕਿਰਿਆਵਾਂ ਹਨ। ਜੋ ਤੈਨਾਤੀ ਇਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਕਰਦੀ ਹੈ, ਉਸ ਵਿੱਚ ਨੀਤੀ ਦੀ ਥਾਂ ਖੱਡ ਹੈ। ਤਿੰਨੇ ਜਾਣ-ਬੁੱਝ ਕੇ ਮਿਲਾਓ, ਅਤੇ ਦਰਜ ਕਰੋ ਕਿ ਕਿਹੜਾ ਕਦਮ ਕਿਹੜਾ ਅਧਿਕਾਰ ਵਰਤਦਾ ਹੈ।
ਸਮਾਂ ਦੂਜਾ ਫ਼ਰਕ ਹੈ। ਬਦਲੀ ਸਵੀਕ੍ਰਿਤੀ ਸੂਚੀ ਨਵੇਂ ਹੈਂਡਸ਼ੇਕ 'ਤੇ ਲਾਗੂ ਹੁੰਦੀ ਹੈ, ਜਦਕਿ ਪਹਿਲਾਂ ਸਥਾਪਿਤ ਸੈਸ਼ਨ ਕੁਝ ਉਹਨਾਂ ਨੂੰ ਖ਼ਤਮ ਕਰਨ ਤੱਕ ਚੱਲਦੇ ਰਹਿੰਦੇ ਹਨ। ਨਵੀਂ ਸੂਚੀ ਦੀਆਂ ਐਂਟਰੀਆਂ ਨੂੰ ਪੁਰਾਣੇ ਸੈਸ਼ਨ ਖ਼ਤਮ ਹੋਣ ਦਾ ਸਬੂਤ ਮੰਨ ਕੇ ਗਿਣਨਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਹਟਾਇਆ ਕਲਾਇੰਟ ਘੰਟਿਆਂ ਤੱਕ ਜੁੜਿਆ ਰਹਿੰਦਾ ਹੈ।
ਨਾ-ਮਿਲਾਏ ਅਧਿਕਾਰ ਅਭਿਆਸ ਵਿੱਚ ਸੌਖਿਆਂ ਮਿਲਣ ਵਾਲੇ ਦੋ ਛੇਕ ਛੱਡਦੇ ਹਨ। ਖਾਤਾ ਬੰਦ ਹੋ ਸਕਦਾ ਹੈ ਜਦਕਿ ਉਸਦੀ ਨਿਯੰਤਰਣ ਕੁੰਜੀ ਅਜੇ ਵੀ ਹੈਂਡਸ਼ੇਕ ਖੋਲ੍ਹਦੀ ਹੈ, ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਰੱਦ ਹੋ ਸਕਦਾ ਹੈ ਜਦਕਿ ਮੈਟਾਡੇਟਾ ਨੀਤੀ ਉਸੇ ਕਲਾਇੰਟ ਨੂੰ ਅਜੇ ਵੀ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ। ਦੋਵੇਂ ਵੱਖਰੀਆਂ ਥਾਵਾਂ ਦੀ ਇੱਕੋ ਗਲਤੀ ਹਨ, ਕਿਉਂਕਿ ਆਪਰੇਟਰ ਨੇ ਇੱਕ ਸੂਚੀ ਨੂੰ ਪੂਰਾ ਅਧਿਕਾਰ ਮੰਨਿਆ। ਹਟਾਉਣ ਵੇਲੇ ਤਿੰਨੇ ਸੂਚੀਆਂ ਕੋਲ-ਕੋਲ ਰੱਖੋ ਅਤੇ ਗਲਤੀ ਦਿਸਣ ਲੱਗਦੀ ਹੈ।
ਪ੍ਰੋਫਾਈਲ ਜਾਰੀ ਕਰਨਾ ਅਤੇ ਵਾਪਸ ਲੈਣਾ
ਜਾਰੀ ਕਰਨਾ ਸੌਖਾ ਅੱਧ ਹੈ: ਸਵੀਕਾਰ ਕਰਨ ਵਾਲੇ ਪਾਸੇ ਕਲਾਇੰਟ ਕੁੰਜੀ ਬਣਾਓ, ਪ੍ਰੋਫਾਈਲ ਠੀਕ ਇੱਕ ਮਾਲਕ ਨੂੰ ਦਿਓ, ਲਪੇਟਣ ਵਾਲੀ ਸਮੱਗਰੀ ਸੀਮਿਤ ਰੱਖੋ, ਅਤੇ ਹਰ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲੇ ਸਰਵਰ 'ਤੇ ਉਹੀ ਤਸਦੀਕ ਪ੍ਰੋਗਰਾਮ ਚਲਾਓ। ਸਸਤਾ ਦਾਖਲਾ ਪੂਰੇ ਸਮੂਹ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ, ਸਭ ਤੋਂ ਨਵੇਂ ਹੋਸਟ ਦੀ ਨਹੀਂ। ਪੁਰਾਣੀ ਜਾਂ ਢਿੱਲੀ ਸਕ੍ਰਿਪਟ ਵਾਲਾ ਦੂਜਾ ਸਰਵਰ ਚੁੱਪਚਾਪ ਤੈਨਾਤੀ ਦਾ ਸਭ ਤੋਂ ਕਮਜ਼ੋਰ ਰਾਹ ਬਣ ਜਾਂਦਾ ਹੈ।
ਵਾਪਸ ਲੈਣ ਲਈ ਤਿੰਨੇ ਕਦਮ ਜਾਣ-ਬੁੱਝ ਕੇ ਕ੍ਰਮ ਵਿੱਚ ਚਾਹੀਦੇ ਹਨ। ਨਵੇਂ ਹੈਂਡਸ਼ੇਕ ਅਸਫਲ ਹੋਣ ਲਈ ਤਸਦੀਕ ਹੁੱਕ ਵਿੱਚ ਕਲਾਇੰਟ ਨੂੰ ਰੱਦ ਕਰੋ, ਜੇ PKI ਵਰਤੀ ਜਾਂਦੀ ਹੈ ਤਾਂ ਉਸਦਾ ਸਰਟੀਫਿਕੇਟ ਰੱਦ ਕਰੋ, ਅਤੇ ਖਾਤਾ ਬੰਦ ਕਰੋ ਤਾਂ ਜੋ ਬਾਅਦ ਦੇ ਅਧਿਕਾਰ ਕੋਲ ਅਧਿਕਾਰ ਦੇਣ ਲਈ ਕੁਝ ਨਾ ਬਚੇ। ਫਿਰ ਪੁਰਾਣੀ ਸਵੀਕ੍ਰਿਤੀ ਨੇ ਮਨਜ਼ੂਰ ਕੀਤੇ ਸੈਸ਼ਨ ਖ਼ਤਮ ਕਰੋ, ਕਿਉਂਕਿ ਉਹ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਨਹੀਂ ਵੇਖਣਗੇ। ਜਿਸ ਕਲਾਇੰਟ ਨੂੰ ਤੁਸੀਂ ਤੋੜ ਸਕਦੇ ਹੋ ਉਸ 'ਤੇ ਇਹ ਕ੍ਰਮ ਦੁਹਰਾਓ।
ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਮੈਟਾਡੇਟਾ ਉਸ ਨੀਤੀ ਲਈ ਇਨਪੁਟ ਹੈ, ਇਸ ਦਾ ਸਬੂਤ ਨਹੀਂ ਕਿ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹੈ। OpenVPN 2.6 ਦਾ ਡਿਜ਼ਾਈਨ ਦਸਤਾਵੇਜ਼ ਵਸਤੂਆਂ ਅਤੇ ਉਹਨਾਂ ਵੱਲੋਂ ਖਿੱਚੀ ਸੀਮਾ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਜਦਕਿ ਉਹਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਆਪਰੇਟਰ ਕੋਲ ਹੀ ਰਹਿੰਦਾ ਹੈ।