OpenVPN push-peer-info: ਪਹੁੰਚ ਦਿੱਤੇ ਬਿਨਾਂ ਕਲਾਇੰਟ ਨੂੰ ਲੇਬਲ ਕਰੋ

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

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

ਵੇਰੀਏਬਲ ਸੈੱਟ ਕਰੋ ਅਤੇ ਰਾਹ ਚਾਲੂ ਕਰੋ

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

setenv UV_DEPLOY field-support
push-peer-info

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

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

ਸਰਵਰ ਹੁੱਕ ਤੋਂ ਫ਼ੀਲਡ ਪੜ੍ਹੋ

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

#!/bin/sh
# /etc/openvpn/server/hooks/label.sh
printf '%s %s\n' "$common_name" "${UV_DEPLOY:-unset}" \
  >> /var/log/openvpn/deploy-labels.log

ਲੌਗ ਪਾਰਸ ਕਰਨ ਦੀ ਥਾਂ ਵਾਤਾਵਰਨ ਰਾਹੀਂ ਵੇਰੀਏਬਲ ਪੜ੍ਹੋ, ਅਤੇ ਇਸਨੂੰ ਹਮੇਸ਼ਾ ਡਿਫ਼ਾਲਟ ਮੁੱਲ ਦਿਓ। ${UV_DEPLOY:-unset} ਉਨ੍ਹਾਂ ਕਲਾਇੰਟਾਂ ਲਈ ਵੀ ਸਕ੍ਰਿਪਟ ਚਾਲੂ ਰੱਖਦੀ ਹੈ ਜੋ ਫ਼ੀਲਡ ਕਦੇ ਨਹੀਂ ਭੇਜਦੇ, ਜੋ ਪੜਾਅਵਾਰ ਤੈਨਾਤੀ ਦੌਰਾਨ ਆਮ ਸਥਿਤੀ ਹੈ। ਨਾਮ ਲੱਭਣ ਲਈ ਪੂਰਾ ਵਾਤਾਵਰਨ ਲੌਗ ਵਿੱਚ ਨਾ ਡੋਲ੍ਹੋ; ਇਸ ਵਿੱਚ ਲੇਬਲ ਨਾਲੋਂ ਬਹੁਤ ਕੁਝ ਹੈ, ਜਿਸ ਵਿੱਚ ਉਹ ਮੁੱਲ ਵੀ ਸ਼ਾਮਲ ਹਨ ਜੋ ਤੁਸੀਂ ਸੰਭਾਲਣ ਦਾ ਇਰਾਦਾ ਨਹੀਂ ਸੀ ਰੱਖਿਆ।

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

ਅਸਲ ਵਿੱਚ ਕੀ ਆਇਆ ਇਹ ਜਾਂਚੋ

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

tail -n 5 /var/log/openvpn/deploy-labels.log
# field-support deployed-client-07
# unset         legacy-laptop-02

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

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

ਲੇਬਲ ਨੂੰ ਦਾਅਵਾ ਮੰਨੋ, ਪਛਾਣ ਨਹੀਂ

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

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

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

case "${UV_DEPLOY:-}" in
  field-support|field-qa|lab) : ;;
  *) UV_DEPLOY=unknown ;;
esac

ਇਸਨੂੰ ਸਾਫ਼-ਸੁਥਰੇ ਢੰਗ ਨਾਲ ਵਾਪਸ ਲਵੋ

ਵਿਸ਼ੇਸ਼ਤਾ ਹਟਾਉਣਾ ਦੋ ਮਿਟਾਉਣੇ ਅਤੇ ਇੱਕ ਜਾਂਚ ਹੈ। ਕਲਾਇੰਟ ਪ੍ਰੋਫ਼ਾਈਲ ਤੋਂ setenv ਅਤੇ push-peer-info ਲਾਈਨਾਂ ਹਟਾਓ, ਫਿਰ ਸਰਵਰ 'ਤੇ ਹੁੱਕ ਅਤੇ ਉਸਦਾ ਲੌਗ ਟਾਰਗੈਟ ਹਟਾਓ ਜਾਂ ਅਯੋਗ ਕਰੋ।

grep -rn 'UV_DEPLOY\|push-peer-info' /etc/openvpn/
tail -n 3 /var/log/openvpn/deploy-labels.log

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

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