OpenConnect ਲੌਗਇਨ ਗਲਤ ਪੰਨੇ 'ਤੇ ਪਹੁੰਚਦਾ ਹੈ? ਪਹਿਲਾਂ ਪਾਥ ਜਾਂਚੋ

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

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

ਫਾਰਮ ਦੇਖਣ ਤੋਂ ਪਹਿਲਾਂ ਕਲਾਇੰਟ ਕੀ ਭੇਜਦਾ ਹੈ

https://vpn.example.net/partners ਵਰਗੇ ਪਤੇ ਨਾਲ ਕਲਾਇੰਟ ਦਾ ਪਹਿਲਾ ਕੰਮ ਨੰਗੇ ਹੋਸਟ ਵੱਲ ਨਹੀਂ, ਸਗੋਂ ਉਸ ਪਾਥ ਵੱਲ HTTPS ਬੇਨਤੀ ਹੈ। ਵਾਪਸ ਆਉਣ ਵਾਲੀ ਚੀਜ਼ ਆਮ ਤੌਰ 'ਤੇ ਸਾਈਨ-ਇਨ ਐਂਡਪੁਆਇੰਟ ਵੱਲ ਰੀਡਾਇਰੈਕਟ, ਜਾਂ ਫਾਰਮ ਆਪ ਹੁੰਦੀ ਹੈ। ਸਿਰਫ਼ vpn.example.net ਮਿਲਿਆ ਕਲਾਇੰਟ ਜੋ ਵੀ ਡਿਫਾਲਟ ਲੈਂਡਿੰਗ ਪੰਨਾ ਹੋਵੇ ਉੱਥੋਂ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਹ ਦੂਜਾ ਪੋਰਟਲ, ਦੂਜੀ ਗਰੁੱਪ ਸੂਚੀ, ਜਾਂ ਬਿਲਕੁਲ ਵੱਖਰੇ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਉਮੀਦ ਕਰਨ ਵਾਲਾ ਪੰਨਾ ਹੋ ਸਕਦਾ ਹੈ। ਫ਼ਰਕ ਕਿਸੇ ਵੀ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਟਾਈਪ ਹੋਣ ਤੋਂ ਬਹੁਤ ਪਹਿਲਾਂ ਜਵਾਬ ਹੈਡਰਾਂ ਵਿੱਚ ਦਿਸਦਾ ਹੈ।

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

ਅਦਲ-ਬਦਲ ਯੋਗ ਲੱਗਣ ਵਾਲੇ ਅਤੇ ਨਾ ਹੋਣ ਵਾਲੇ ਦੋ ਇਨਪੁਟ

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

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

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

ਪਾਥ ਛੋਟਾ ਕਰਨ ਨਾਲ ਨਤੀਜਾ ਕਿਉਂ ਬਦਲਦਾ ਹੈ

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

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

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

ਹੋਰ ਕੁਝ ਵੀ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਐਂਟਰੀ ਪੁਆਇੰਟ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

ਤੁਹਾਨੂੰ ਦਿੱਤੇ ਪਾਥ ਦੇ ਹੈਡਰ ਪੜ੍ਹੋ। curl -sS -o /dev/null -D - https://vpn.example.net/partners ਵਰਗੀ ਬੇਨਤੀ ਰੀਡਾਇਰੈਕਟ ਦੀ ਪਾਲਣਾ ਕੀਤੇ ਬਿਨਾਂ ਸਥਿਤੀ ਲਾਈਨ ਅਤੇ ਕੋਈ ਵੀ Location ਹੈਡਰ ਛਾਪਦੀ ਹੈ। ਨਾਮਿਤ ਸਾਈਨ-ਇਨ ਐਂਡਪੁਆਇੰਟ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲਾ 302 ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਕਿ ਪਾਥ ਮੌਜੂਦ ਹੈ ਅਤੇ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਉਹ ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ; 404 ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਆਪਰੇਟਰ ਦਾ ਪਤਾ ਪੁਰਾਣਾ ਹੈ।

ਫਿਰ ਉਹੀ ਐਂਟਰੀ ਪੁਆਇੰਟ ਮਨਜ਼ੂਰ ਕਲਾਇੰਟ ਵਿੱਚ ਦੁਬਾਰਾ ਬਣਾਓ, ਉਦਾਹਰਨ ਲਈ openconnect --usergroup=partners vpn.example.net, ਅਤੇ ਦੇਖੋ ਕਿਹੜਾ ਫਾਰਮ ਦਿਸਦਾ ਹੈ। ਜੇ ਫਾਰਮ ਸਹੀ ਹੈ ਅਤੇ ਟਨਲ ਫਿਰ ਵੀ ਫੇਲ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਪਾਥ ਕਦੇ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ ਅਤੇ ਅਗਲਾ ਪੜਾਅ ਨੀਤੀ ਜਾਂ ਰੂਟਿੰਗ ਹੈ।

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