OpenConnect ਲੌਗਇਨ ਕੂਕੀ ਨੂੰ ਟਨਲ ਵਿੱਚ ਕਿਵੇਂ ਬਦਲਦਾ ਹੈ?

OpenConnect ਦੋ ਵੱਖਰੇ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਨੂੰ ਇੱਕ ਛੋਟੀ ਉਮਰ ਦੇ ਮੁੱਲ ਨਾਲ ਜੋੜਦਾ ਹੈ: ਵੈੱਬ ਲੌਗਇਨ ਅਤੇ VPN ਟਨਲ। ਪਹਿਲਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਆਮ HTTPS ਹੈ: ਪ੍ਰਮਾਣ, ਇੱਕ SAML ਚੱਕਰ ਜਾਂ ਟੋਕਨ ਗੇਟਵੇ ਕੋਲ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਜਵਾਬ ਪ੍ਰਮਾਣਿਕਤਾ ਕੂਕੀ ਲਿਆਉਂਦਾ ਹੈ। ਦੂਜਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਉਹੀ ਕੂਕੀ ਉਸੇ ਗੇਟਵੇ ਸਾਹਮਣੇ ਵੈੱਬ ਪੜਾਅ ਪਹਿਲਾਂ ਹੀ ਹੋ ਚੁੱਕਣ ਦੇ ਸਬੂਤ ਵਜੋਂ ਪੇਸ਼ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਦੋਂ ਹੀ ਟਨਲ ਉੱਪਰ ਆਉਂਦਾ ਹੈ।

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

ਕਲਾਇੰਟ ਅਤੇ ਗੇਟਵੇ ਕ੍ਰਮ ਨਾਲ ਕੀ ਬਦਲਦੇ ਹਨ

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

ਦੂਜਾ ਪੜਾਅ ਉਹ ਕੂਕੀ ਜੋੜ ਕੇ ਗੇਟਵੇ ਦੇ VPN ਅੰਤ ਬਿੰਦੂ ਵੱਲ CONNECT ਬੇਨਤੀ ਹੈ। ਗੇਟਵੇ ਇਸਨੂੰ ਜਾਂਚਦਾ ਹੈ, ਪਤਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ TLS ਉੱਤੇ CSTP ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਸ਼ੈਸ਼ਨ ਹੋਣ ’ਤੇ DTLS ਇੱਕ ਲਾਜ਼ਮੀ ਨਹੀਂ ਤੇਜ਼ ਡੇਟਾ ਰਾਹ ਹੁੰਦਾ ਹੈ। ਇਸੇ ਪਲ ਹੀ ਟਨਲ ਦੇ ਪੈਰਾਮੀਟਰ, ਰੂਟ, DNS ਸੈਟਿੰਗਾਂ ਅਤੇ ਸ਼ੈਸ਼ਨ ਦੀਆਂ ਟ੍ਰੈਫ਼ਿਕ ਚਾਬੀਆਂ ਸਥਾਪਿਤ ਹੁੰਦੀਆਂ ਹਨ। ਕੂਕੀ ਨੇ ਕਲਾਇੰਟ ਨੂੰ ਦਰਵਾਜ਼ੇ ਵਿੱਚੋਂ ਲੰਘਾਇਆ; ਇਸਨੇ ਕੁਝ ਵੀ ਐਨਕ੍ਰਿਪਟ ਨਹੀਂ ਕੀਤਾ।

ਇਹੀ ਕ੍ਰਮ ਦੱਸਦਾ ਹੈ ਕਿ openconnect --authenticate ਕਿਉਂ ਹੈ। ਇਸਨੂੰ ਚਲਾਓ, ਇਹ ਵੈੱਬ ਪੜਾਅ ਕਰਦਾ ਹੈ, COOKIE, HOST, CONNECT_URL ਅਤੇ FINGERPRINT ਵਰਗੇ ਸ਼ੈੱਲ ਚਲਾਂ ਦਾ ਛੋਟਾ ਬਲਾਕ ਛਾਪਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਕੋਈ ਟਨਲ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਬਾਹਰ ਨਿਕਲ ਜਾਂਦਾ ਹੈ। ਉਸ ਤੋਂ ਬਾਅਦ ਰੈਪਰ ਸਕ੍ਰਿਪਟ ਉਨ੍ਹਾਂ ਮੁੱਲਾਂ ਨਾਲ ਅਸਲ ਕਨੈਕਸ਼ਨ ਸ਼ੁਰੂ ਕਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਹੈਡਲੈੱਸ ਜਾਂ ਦੋ-ਕੰਟੇਨਰ ਤੈਨਾਤੀ ਨੂੰ ਇਹੀ ਵੰਡ ਚਾਹੀਦੀ ਹੈ।

ਕੂਕੀ ਸ਼ੈਸ਼ਨ ਦੀ ਵਾਹਕ ਹੈ, ਚਾਬੀ ਨਹੀਂ

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

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

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

ਨਕਲ ਛੱਡੇ ਬਿਨਾਂ ਕੂਕੀ ਅੱਗੇ ਭੇਜਣਾ

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

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

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

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

ਦੂਜੇ ਪੜਾਅ ਵਿੱਚ ਤਸਦੀਕ ਅਤੇ ਮਿਆਦ ਪੁੱਗਣਾ

ਦੂਜੇ ਪੜਾਅ ਨੂੰ ਵੀ ਸਰਵਰ ਤਸਦੀਕ ਕਰਨਾ ਹੈ। --authenticate ਜੋ FINGERPRINT ਛਾਪਦਾ ਹੈ ਉਹ pin-sha256: ਰੂਪ ਵਿੱਚ ਸਰਟੀਫਿਕੇਟ ਪਿੰਨ ਹੈ, ਅਤੇ ਇਸਨੂੰ --servercert ਨਾਲ ਟਨਲ ਕਾਲ ਨੂੰ ਦੇਣ ਨਾਲ ਜਾਂਚ ਉਸੇ ਗੇਟਵੇ ’ਤੇ ਲੰਗਰਿਤ ਰਹਿੰਦੀ ਹੈ ਜਿਸਦੇ ਸਾਹਮਣੇ ਤੁਸੀਂ ਪ੍ਰਮਾਣਿਕਤਾ ਕੀਤੀ। ਸਕ੍ਰਿਪਟ ਸਰਲ ਕਰਨ ਲਈ ਸਰਟੀਫਿਕੇਟ ਜਾਂਚ ਬੰਦ ਕਰਨਾ ਇਸ ਗੱਲ ਦਾ ਇੱਕੋ-ਇੱਕ ਸਬੂਤ ਹਟਾ ਦਿੰਦਾ ਹੈ ਕਿ ਕੂਕੀ ਇੱਛਤ ਹੋਸਟ ਨੂੰ ਦਿੱਤੀ ਜਾ ਰਹੀ ਹੈ।

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

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