ਕਨੈਕਸ਼ਨ ਅਸਵੀਕਾਰ ਹੋਣਾ ਸਰਟੀਫਿਕੇਟ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ: VPN ਰਨਬੁੱਕ

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

ਦੋ ਜਾਂਚਾਂ ਇੱਕ ਮਿੰਟ ਤੋਂ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਕੇਸਾਂ ਨੂੰ ਵੱਖ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਭਰੋਸਾ ਸੈਟਿੰਗਾਂ ਨੂੰ ਨਹੀਂ ਛੂਹਦੀ।

ਗਲਤੀ ਨੂੰ ਉਸੇ ਪਰਤ ਉੱਤੇ ਪੜ੍ਹੋ ਜਿਸਨੇ ਇਹ ਪੈਦਾ ਕੀਤੀ

connect ਤੋਂ ECONNREFUSED ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਟਰਾਂਸਪੋਰਟ ਯਤਨ ਅਸਵੀਕਾਰ ਹੋਇਆ: ਕਿਸੇ ਨੇ reset ਨਾਲ ਜਵਾਬ ਦਿੱਤਾ, ਜਾਂ ਸਟੈਕ ਨੇ ਅਪਹੁੰਚ ਪੋਰਟ ਦੀ ਰਿਪੋਰਟ ਕੀਤੀ। ਸਰਟੀਫਿਕੇਟ ਦੀ ਸਮੱਸਿਆ ਇਹ ਗਲਤੀ ਪੈਦਾ ਨਹੀਂ ਕਰ ਸਕਦੀ, ਕਿਉਂਕਿ ਟਰਾਂਸਪੋਰਟ ਕਨੈਕਸ਼ਨ ਤੋਂ ਬਿਨਾਂ TLS ਹੈਂਡਸ਼ੇਕ ਕਦੇ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦਾ। ਜੇ ਅਸਵੀਕਾਰ ਦਿਸੇ, ਤਾਂ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਪੇਸ਼ ਕਰਨ ਦੇ ਪੜਾਅ ਤੱਕ ਵੀ ਨਹੀਂ ਪਹੁੰਚਿਆ। ਇਹ ਇੱਕ ਤੱਥ ਰੱਦ ਕਰਨ ਨੂੰ ਕਾਰਨ ਵਜੋਂ ਬਾਹਰ ਕਰਦਾ ਹੈ।

ਉਲਟਾ ਵੀ ਸੱਚ ਹੈ। ਰੱਦ ਕੀਤਾ ਸਰਟੀਫਿਕੇਟ ਪੂਰਾ TCP ਕਨੈਕਸ਼ਨ ਅਤੇ ਅਸਫਲ ਹੈਂਡਸ਼ੇਕ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਜੋ ਸਰਵਰ ਉੱਤੇ ਪੁਸ਼ਟੀ ਗਲਤੀ ਵਜੋਂ ਦਰਜ ਹੁੰਦਾ ਹੈ।

TCP ਅਸਵੀਕਾਰ: ਕੋਈ ਸੁਣ ਨਹੀਂ ਰਿਹਾ

TCP ਲਈ, ਜਾਂਚੋ ਕਿ ਇੱਛਤ ਇੰਸਟੈਂਸ ਚੱਲ ਰਿਹਾ ਹੈ ਅਤੇ ਪ੍ਰੋਫਾਈਲ ਦੇ ਪਤੇ ਅਤੇ ਪੋਰਟ ਨਾਲ ਬੱਝਾ ਹੋਇਆ ਹੈ। ss -lntp ਸੁਣਨ ਵਾਲੇ ਦਿਖਾਉਂਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦਾ ਨਾ ਹੋਣਾ ਆਮ ਵਿਆਖਿਆ ਹੈ। ਸੁੱਟਣ ਦੀ ਬਜਾਏ ਅਸਵੀਕਾਰ ਕਰਨ ਵਾਲਾ ਫਾਇਰਵਾਲ ਕਲਾਇੰਟ ਪਾਸੇ ਉਹੀ ਸੁਨੇਹਾ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਤੁਸੀਂ ਦੋਵੇਂ ਜਾਂਚਦੇ ਹੋ।

ਪਤਾ ਪਰਿਵਾਰ ਵੀ ਜਾਂਚੋ। 127.0.0.1 ਜਾਂ ਸਿਰਫ਼ IPv6 ਨਾਲ ਬੱਝੀ ਸੇਵਾ ਦੂਜੇ ਉੱਤੇ ਰਿਜ਼ੋਲਵ ਹੁੰਦੇ ਕਲਾਇੰਟ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰੇਗੀ।

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

UDP ਕੋਲ ਅਸਵੀਕਾਰ ਕਰਨ ਲਈ ਹੈਂਡਸ਼ੇਕ ਨਹੀਂ

UDP ਉੱਤੇ OpenVPN TCP ਅਰਥ ਵਿੱਚ ਕਨੈਕਸ਼ਨ ਸਥਾਪਤ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ connect ਸਮੇਂ ਅਸਵੀਕਾਰ ਕਰਨ ਲਈ ਕੁਝ ਨਹੀਂ। Linux ਵਿੱਚ, UDP ਸਾਕਟ ਵੱਲੋਂ ਦਿਖਾਈ ਗਈ ਗਲਤੀ ਪਹਿਲਾਂ ਦੇ ਡੇਟਾਗ੍ਰਾਮ ਵੱਲੋਂ ਪੈਦਾ ਕੀਤੇ ICMP port-unreachable ਤੋਂ ਆ ਸਕਦੀ ਹੈ। udp(7) ਮੈਨ ਪੇਜ ਉਸ ਅਸਮਕਾਲੀ ਵਿਵਹਾਰ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ।

ਇਸ ਲਈ UDP ਕਲਾਇੰਟ ਅਸਵੀਕਾਰ ਛਾਪ ਸਕਦਾ ਹੈ ਜਦੋਂ ਸਰਵਰ ਪ੍ਰਕਿਰਿਆ ਚੱਲ ਰਹੀ ਹੈ ਪਰ ਉਮੀਦ ਕੀਤੇ ਪਤੇ ਨਾਲ ਬੱਝੀ ਨਹੀਂ।

CRL ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਜਾਂਚਿਆ ਜਾਂਦਾ ਹੈ

CRL ਦੀ ਸਲਾਹ TLS ਹੈਂਡਸ਼ੇਕ ਦੌਰਾਨ, ਸਾਹਮਣੇ ਧਿਰ ਵੱਲੋਂ ਆਪਣਾ ਸਰਟੀਫਿਕੇਟ ਪੇਸ਼ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਅਤੇ ਸਿਰਫ਼ ਤਦ ਜਦੋਂ ਸਰਵਰ ਸੰਰਚਨਾ ਇਸ ਦੀ ਆਗਿਆ ਦੇਵੇ, ਲਈ ਜਾਂਦੀ ਹੈ। OpenVPN ਦਾ crl-verify ਵਿਕਲਪ ਫਾਈਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਅਸਫਲਤਾ ਸਰਵਰ ਲੌਗ ਵਿੱਚ ਸਰਟੀਫਿਕੇਟ ਦਾ ਨਾਮ ਲੈਣ ਵਾਲੀ ਪੁਸ਼ਟੀ ਗਲਤੀ ਵਜੋਂ ਦਿਸਦੀ ਹੈ।

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

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

ਅਗਲੀ ਵਾਰ ਲਈ ਛੋਟੀ ਰਨਬੁੱਕ

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

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