OpenVPN auth-user-pass: ਫ਼ਾਈਲ, stdin ਜਾਂ ਪ੍ਰੋਂਪਟ? ਕਿਵੇਂ ਚੁਣੀਏ

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

ਇਸ ਨੂੰ ਤੈਅ ਕਰਨ ਵਾਲੀਆਂ ਤਿੰਨ ਸ਼ਰਤਾਂ

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

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

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

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

ਹਰ ਇਨਪੁਟ ਰਾਹ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹੈ

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

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

ਫ਼ਾਈਲ ਠੀਕ ਦੋ ਲਾਈਨਾਂ ਦੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ

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

install -m 600 /dev/null /etc/openvpn/client.creds
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client.creds
od -c /etc/openvpn/client.creds | head -3

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

ਸਰਵਰ ਨੂੰ ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਫ਼ਾਈਲ ਪਰਖੋ। openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 ਚਲਾਉਣ 'ਤੇ ਛਪਦਾ ਹੈ ਕਿ ਫ਼ਾਈਲ ਖੁੱਲ੍ਹੀ ਕਿ ਨਹੀਂ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਪ੍ਰਮਾਣ ਸਵੀਕਾਰ ਹੋਏ ਕਿ ਨਹੀਂ, ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਅੱਗੇ ਕਿਹੜੀ ਪਰਤ ਬਦਲਣੀ ਹੈ।

ਸਟ੍ਰੀਮ, stdin ਅਤੇ ਉਨ੍ਹਾਂ ਤੋਂ ਪੈਦਾ ਹੋਣ ਵਾਲੀਆਂ ਗ਼ਲਤੀਆਂ

ਪਾਸਵਰਡ ਨੂੰ ਪਾਈਪ ਵਿੱਚ ਪਾਉਣਾ ਬਹੁਤਿਆਂ ਦੀ ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ ਹੈ ਅਤੇ ਸਭ ਤੋਂ ਵੱਧ ਹੈਰਾਨੀਆਂ ਵਾਲਾ ਰਾਹ ਹੈ। ਪ੍ਰਕਿਰਿਆ ਬਦਲ ਇਸ ਲਈ ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਕਲਾਇੰਟ ਨੂੰ ਸਿਰਫ਼ ਪੜ੍ਹਨਯੋਗ ਡਿਸਕ੍ਰਿਪਟਰ ਚਾਹੀਦਾ ਹੈ: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS")। /dev/stdin ਪਾਸ ਕਰਨਾ ਤਦ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦੋਂ ਕਲਾਇੰਟ ਪੁੱਛਣ ਵੇਲੇ stdin ਹਾਲੇ ਖੁੱਲ੍ਹਾ ਅਤੇ ਪੜ੍ਹਨਯੋਗ ਹੋਵੇ, ਜੋ ਪਹਿਲਾਂ ਹੀ ਖਪਤ ਕਰ ਚੁੱਕੀ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਸੱਚ ਨਹੀਂ ਹੈ।

ERROR: could not read Auth username from stdin ਦੇ ਦੋ ਵੱਖਰੇ ਕਾਰਨ ਹਨ। ਕੁਝ 2.3.x ਕਲਾਇੰਟਾਂ ਉੱਤੇ ਸੁਨੇਹਾ stdin ਸੰਭਾਲ ਦੀ ਖਾਮੀ ਤੋਂ ਆਇਆ ਜਿਸ ਨੂੰ ਬਾਅਦ ਦੀਆਂ 2.3 ਰਿਲੀਜ਼ਾਂ ਨੇ ਠੀਕ ਕੀਤਾ, ਇਸ ਲਈ ਇੰਨਾ ਪੁਰਾਣਾ ਕਲਾਇੰਟ ਸਿਰਫ਼ ਅਪਗ੍ਰੇਡ ਨਾਲ ਸੁਧਰਦਾ ਹੈ। ਮੌਜੂਦਾ ਕਲਾਇੰਟ ਉੱਤੇ ਉਹੀ ਸ਼ਬਦ ਇਹ ਕਹਿੰਦੇ ਹਨ ਕਿ ਕਲਾਇੰਟ ਨੇ ਕੰਸੋਲ ਇਨਪੁਟ ਮੰਗਿਆ ਅਤੇ stdin ਟਰਮੀਨਲ ਨਹੀਂ ਸੀ - ਬਿਲਕੁਲ systemd ਯੂਨਿਟ, cron ਕੰਮ ਜਾਂ -t ਤੋਂ ਬਿਨਾਂ ਸ਼ੁਰੂ ਕੀਤੇ ਕੰਟੇਨਰ ਵਾਲੀ ਹਾਲਤ।

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

ਪ੍ਰਬੰਧਨ ਇੰਟਰਫ਼ੇਸ ਜਦੋਂ ਪ੍ਰੋਂਪਟ ਕਿਸੇ ਹੋਰ ਪ੍ਰਕਿਰਿਆ ਕੋਲ ਹੋਵੇ

ਜੋ ਨਿਯੰਤਰਕ ਪਹਿਲਾਂ ਹੀ ਟਨਲ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦਾ ਹੈ, ਉਹ ਇਸ ਦੇ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਵੀ ਦੇ ਸਕਦਾ ਹੈ। ਕਲਾਇੰਟ ਨੂੰ --management 127.0.0.1 7505 ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ, ਸਥਿਤੀ ਲਾਈਨਾਂ ਪੜ੍ਹੋ, ਅਤੇ >PASSWORD:Need 'Auth' username/password ਵੱਲ ਧਿਆਨ ਦਿਓ। ਨਿਯੰਤਰਕ ਵੱਖਰੀਆਂ ਕਮਾਂਡ ਲਾਈਨਾਂ ਉੱਤੇ username "Auth" alice ਅਤੇ ਫਿਰ password "Auth" ... ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। 'Auth' ਟੋਕਨ ਬੇਨਤੀ ਤੋਂ ਪਛਾਣਕਰਤਾ ਦੁਹਰਾਉਂਦਾ ਹੈ ਅਤੇ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਹੀਂ ਤਾਂ ਜਵਾਬ ਅਣਡਿੱਠਾ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਉਡੀਕਦਾ ਹੈ।

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

ਪ੍ਰਮਾਣ ਸਮੱਸਿਆ ਵਰਗੀਆਂ ਦਿਸਣ ਵਾਲੀਆਂ ਫੇਲ੍ਹਤਾਵਾਂ

ਕਦੇ ਪੂਰਾ ਨਾ ਹੋਣ ਵਾਲਾ TLS ਹੱਥ-ਮਿਲਾਪ, ਜਾਂ VERIFY ERROR: depth=0, error=certificate signature failure, ਭਰੋਸੇ ਦੀ ਸਮੱਸਿਆ ਹੈ ਅਤੇ ਕਿਸੇ ਵੀ ਵਰਤੋਂਕਾਰ ਨਾਮ ਦੇ ਪੜ੍ਹੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਹੁੰਦਾ ਹੈ। UDP ਸਰੋਤੇ ਵੱਲ ਨਿਸ਼ਾਨਾ proto tcp ਕਲਾਇੰਟ ਵੀ ਉਸੇ ਥਾਂ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ: ਪੈਕਟ ਕਦੇ ਪ੍ਰਮਾਣੀਕਰਨ ਪੜਾਅ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦੇ, ਇਸ ਲਈ ਹਰ ਪਾਸਵਰਡ ਸਬੰਧ ਕਾਰਨ ਗ਼ਲਤ ਦਿਸਦਾ ਹੈ। ਪ੍ਰਮਾਣ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਸਰਟੀਫ਼ਿਕੇਟ ਜਾਂਚ ਚਾਲੂ ਰੱਖੋ; ਜਾਣਿਆ-ਪਛਾਣਿਆ ਪ੍ਰੋਂਪਟ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਪਾਸਵਰਡ ਕੌਣ ਲੈਂਦਾ ਹੈ। ਪ੍ਰਮਾਣ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਸਰਟੀਫ਼ਿਕੇਟ ਚੇਨ, ਆਮ ਨਾਮ ਅਤੇ ਟਰਾਂਸਪੋਰਟ ਜਾਂਚੋ।

ਪ੍ਰੋਫ਼ਾਈਲ ਜੋੜਨ ਵਾਲੀ ਸਕ੍ਰਿਪਟ ਵਿੱਚ shell ਗ਼ਲਤੀਆਂ ਦੂਜਾ ਝੂਠਾ ਸੁਰਾਗ ਹਨ। [ ! -f "$file" ] ਦੇ ਅੰਦਰ ਗੁੰਮ ਖਾਲੀ ਥਾਂ command not found ਪੈਦਾ ਕਰਦੀ ਹੈ, ਸਕ੍ਰਿਪਟ ਜਲਦੀ ਰੁਕ ਜਾਂਦੀ ਹੈ, ਪ੍ਰੋਫ਼ਾਈਲ ਕਦੇ ਦੁਬਾਰਾ ਨਹੀਂ ਬਣਦਾ, ਅਤੇ ਕਲਾਇੰਟ ਪਿਛਲੇ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਉਹ ਗ਼ਲਤੀ shell ਦੀ ਹੈ, ਪ੍ਰਮਾਣੀਕਰਨ ਦੀ ਨਹੀਂ, ਅਤੇ ਪਾਸਵਰਡ ਕਿੰਨੀ ਵਾਰ ਵੀ ਦੁਬਾਰਾ ਟਾਈਪ ਕਰੋ, ਉਹ ਨਹੀਂ ਮਿਟੇਗੀ।

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

• ਆਖਰੀ ਪ੍ਰਮਾਣ ਲਾਈਨ ਨਹੀਂ, ਪਹਿਲੀ ਪ੍ਰੋਟੋਕੋਲ ਗ਼ਲਤੀ ਪੜ੍ਹੋ: TLS, ਫਿਰ ਪ੍ਰਮਾਣੀਕਰਨ, ਫਿਰ push।
• ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਫ਼ਾਈਲ ਦੋ ਲਾਈਨਾਂ ਦੀ ਹੈ, ਕੈਰੇਜ ਵਾਪਸੀਆਂ ਨਹੀਂ ਹਨ, ਅਤੇ ਪੂਰਨ ਰਾਹ ਨਾਲ ਹਵਾਲਾ ਦਿੱਤਾ ਗਿਆ ਹੈ।
• ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਪ੍ਰੋਫ਼ਾਈਲ ਅਤੇ ਕਮਾਂਡ ਲਾਈਨ ਨਿਰਦੇਸ਼ ਬਾਰੇ ਅਸਹਿਮਤ ਨਹੀਂ ਹਨ।
• "ਪ੍ਰਮਾਣ ਸਵੀਕਾਰ ਹੋਏ" ਨੂੰ "ਟ੍ਰੈਫ਼ਿਕ ਵਹਿ ਰਿਹਾ ਹੈ" ਤੋਂ ਵੱਖਰਾ ਕਰੋ - ਰੂਟਿੰਗ ਅਤੇ DNS ਬਾਅਦ ਦੀ ਪਰਤ ਹਨ।

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