VPN ਰਾਹੀਂ MySQL: ਸਰਵਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਸਿਰਫ਼ ਐਨਕ੍ਰਿਪਸ਼ਨ ਨਹੀਂ
ਗਲਤ ਹੋਸਟ ਵੱਲ ਐਨਕ੍ਰਿਪਸ਼ਨ ਵੀ ਗਲਤ ਹੈ। ssl-mode ਮੁੱਲਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਫਿਰ ਉਹ ਕਨੈਕਸ਼ਨ ਚਲਾਓ ਜੋ ਤੁਹਾਡੇ ਇਛਿਤ ਸਰਵਰ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਸਾਬਤ ਕਰਦਾ ਹੈ।
ਤੁਸੀਂ 10.20.4.15 ਲਈ ਕਨੈਕਸ਼ਨ ਸੰਭਾਲਦੇ ਹੋ, VPN ਡਿੱਗਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਫਿਰ ਵੀ ਜੁੜਦਾ ਹੈ। ਇਹ ਚੰਗੀ ਖ਼ਬਰ ਨਹੀਂ ਹੈ। ਨਿੱਜੀ ਪਤਾ ਉਸ ਕਿਸੇ ਵੀ ਰਾਊਟਿੰਗ ਸੰਦਰਭ ਦੇ ਅੰਦਰ ਇੱਕ ਥਾਂ ਹੈ ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਹੋ, ਅਤੇ ਕਈ ਨੈੱਟਵਰਕ ਉਹੀ ਸੀਮਾਵਾਂ ਵਰਤਦੇ ਹਨ। ਕਲਾਇੰਟ ਇੱਕ MySQL ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਿਆ, ਬੱਸ ਸ਼ਾਇਦ ਤੁਹਾਡੇ ਤੱਕ ਨਹੀਂ।
ਸੁਧਾਰ ਦੇ ਦੋ ਅੱਧੇ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਨੈੱਟਵਰਕ ਬਾਰੇ ਹੈ। ਕਨੈਕਸ਼ਨ ਨੂੰ ਇਸਦੇ ਇਛਿਤ ਮਾਰਗ ਉੱਤੇ ਰੱਖੋ, ਅਤੇ ਕਲਾਇੰਟ ਨੂੰ ਉਸ ਸਰਵਰ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰੋ ਜਿਸ ਨਾਲ ਉਹ ਗੱਲ ਕਰ ਰਿਹਾ ਹੈ। ਪਹਿਲਾ ਅੱਧਾ ਉਹ ਹੈ ਜਿੱਥੇ VPN ਮਦਦ ਕਰਦਾ ਹੈ; ਦੂਜਾ ਅੱਧਾ ਸੰਰਚਿਤ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।
ਬਿਲਕੁਲ ਕਿਸ ਵੱਲ ਐਨਕ੍ਰਿਪਟ ਕੀਤਾ ਹੈ?
TLS ਗੱਲਬਾਤ ਨੂੰ ਵਿਚਕਾਰਲੇ ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ ਅਤੇ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਐਂਡਪੌਇੰਟ ਆਪਣੇ ਆਪ ਨੂੰ ਕੌਣ ਦੱਸਦਾ ਹੈ, ਜਦੋਂ ਤੱਕ ਕਲਾਇੰਟ ਜਾਂਚ ਨਾ ਕਰੇ। ਭਰੋਸੇਯੋਗ ਅਥਾਰਟੀ ਵਿਰੁੱਧ ਪ੍ਰਮਾਣਿਤ ਹੋਣ ਵਾਲਾ ਸਰਟੀਫਿਕੇਟ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਸਰਟੀਫਿਕੇਟ ਉਸ ਅਥਾਰਟੀ ਤੋਂ ਆਇਆ ਹੈ। ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਸਰਟੀਫਿਕੇਟ ਉਸ ਹੋਸਟਨਾਮ ਲਈ ਜਾਰੀ ਹੋਇਆ ਸੀ ਜਿਸ ਤੱਕ ਤੁਸੀਂ ਪਹੁੰਚਣਾ ਚਾਹੁੰਦੇ ਸੀ, ਅਤੇ ਇਹ ਵੱਖਰੇ ਸਵਾਲ ਹਨ।
ਇਹ ਸਿਧਾਂਤਕ ਖਾਲੀ ਥਾਂ ਨਹੀਂ ਹੈ। ਕੈਪਟਿਵ ਪੋਰਟਲ, ਗਲਤ VRF ਦੀਆਂ ਗਲਤੀਆਂ ਅਤੇ ਇੱਕ ਦੂਜੇ ਉੱਤੇ ਚੜ੍ਹਦੀਆਂ ਪਤਾ ਯੋਜਨਾਵਾਂ ਸਾਰੇ ਤੁਹਾਡੇ ਨਾਲ TLS ਗੱਲਬਾਤ ਕਰਨ ਲਈ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤਿਆਰ ਸਰਵਰ ਬਣਾਉਂਦੇ ਹਨ। ਜੇ ਕਲਾਇੰਟ ਸਿਰਫ਼ ਐਨਕ੍ਰਿਪਸ਼ਨ ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ, ਤਾਂ ਸੈਸ਼ਨ ਨਿੱਜੀ ਹੈ ਪਰ ਗਲਤ ਡੇਟਾਬੇਸ ਵੱਲ ਨਿਸ਼ਾਨਾ ਹੈ।
ਇਸ ਲਈ ਸੰਬੰਧਿਤ ਸਵਾਲ ਇਹ ਨਹੀਂ ਕਿ ਕਨੈਕਸ਼ਨ ਐਨਕ੍ਰਿਪਟ ਹੈ ਜਾਂ ਨਹੀਂ, ਸਗੋਂ ਇਹ ਹੈ ਕਿ ਇਹ ਤੁਹਾਡੀ ਇਛਿਤ ਪਛਾਣ ਵੱਲ ਐਨਕ੍ਰਿਪਟ ਹੈ ਜਾਂ ਨਹੀਂ। MySQL ਦੇ ਕਲਾਇੰਟ ਵਿੱਚ, ਇਹ ਫ਼ਰਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ssl-mode ਸੈਟਿੰਗ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ।
ਅਮਲ ਵਿੱਚ ਪੰਜ ssl-mode ਮੁੱਲ
ਪੰਜ ਮੁੱਲ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਇਸ ਗਾਈਡ ਦੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਸਾਰਣੀ ਦੱਸਦੀ ਹੈ ਕਿ ਹਰ ਇੱਕ ਅਸਲ ਵਿੱਚ ਕੀ ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ, ਨਾ ਕਿ ਇਸਦਾ ਨਾਮ ਕੀ ਸੁਝਾਉਂਦਾ ਹੈ।
| Mode | What it guarantees |
|---|---|
DISABLED | No TLS at all; everything on the wire is readable |
PREFERRED | Tries TLS and falls back to plaintext when the account and server allow it, so it is not a fail-closed requirement |
REQUIRED | Refuses to connect without TLS, and does not validate the certificate |
VERIFY_CA | Validates the server certificate against the configured CA and does not check the hostname |
VERIFY_IDENTITY | Validates the CA and checks that the certificate names the host the client used |
ਇਸ ਲੇਖ ਦੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਸਿਰਫ਼ ਆਖਰੀ ਕਤਾਰ ਦਿੰਦੀ ਹੈ। PREFERRED ਆਪਣੇ ਆਪ ਵਿੱਚ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ, ਕਿਉਂਕਿ ਚੁੱਪਚਾਪ ਸਾਦੇ ਟੈਕਸਟ ਵੱਲ ਡਿੱਗਣ ਵਾਲਾ ਕਲਾਇੰਟ ਇਨਕਾਰ ਕਰਨ ਵਾਲੇ ਨਾਲੋਂ ਬਦਤਰ ਹੈ: ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਐਨਕ੍ਰਿਪਸ਼ਨ ਹੈ ਅਤੇ ਪੈਕਟ ਕੈਪਚਰ ਸਹਿਮਤ ਨਹੀਂ।
ਅੱਜ ਚਲਾਇਆ ਜਾ ਸਕਣ ਵਾਲਾ ਕਨੈਕਸ਼ਨ
ਹੇਠਾਂ ਦਿੱਤਾ ਕਮਾਂਡ ਵਰਤਣ ਦਾ ਰੂਪ ਹੈ, ਦੋ ਪਲੇਸਹੋਲਡਰਾਂ ਨਾਲ: ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਡੇਟਾਬੇਸ ਨਾਮ ਅਤੇ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਚੈਨਲ ਰਾਹੀਂ ਪ੍ਰਾਪਤ CA ਫ਼ਾਈਲ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸਰਵਰ ਵੱਲੋਂ ਪਹਿਲੇ ਸੰਪਰਕ ਵਿੱਚ ਦਿੱਤੀ ਗਈ ਚੀਜ਼ ਤੋਂ ਨਹੀਂ ਲੈਣਾ ਚਾਹੀਦਾ।
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password ਮੁੱਲ ਤੋਂ ਬਿਨਾਂ ਪੁੱਛਦਾ ਹੈ, ਜੋ ਰਾਜ਼ ਨੂੰ ਪ੍ਰੋਸੈਸ ਸੂਚੀ ਅਤੇ ਤੁਹਾਡੇ ਸ਼ੈੱਲ ਇਤਿਹਾਸ ਤੋਂ ਬਾਹਰ ਰੱਖਦਾ ਹੈ। ਇਹ ਇੱਕ ਛੋਟੀ ਆਦਤ ਹੈ ਜਿਸਦਾ ਵੱਡਾ ਲਾਭ ਸਾਂਝੇ ਜੰਪ ਹੋਸਟਾਂ ਉੱਤੇ ਹੁੰਦਾ ਹੈ, ਜਿੱਥੇ ਕਮਾਂਡ ਲਾਈਨ ਹੋਰ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਦਿਸਦੀ ਹੈ।
ਜਦੋਂ ਇਹ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਗਲਤੀ ਦਾ ਟੈਕਸਟ ਮਾਮਲਿਆਂ ਨੂੰ ਅੰਤਰਜ੍ਞਾਨ ਨਾਲੋਂ ਬਿਹਤਰ ਵੱਖ ਕਰਦਾ ਹੈ। CA ਫੇਲ੍ਹ ਹੋਣ ਦਾ ਅਰਥ ਹੈ ਕਿ ਚੇਨ ਪ੍ਰਮਾਣਿਤ ਨਹੀਂ ਹੁੰਦੀ ਅਤੇ ਤੁਹਾਨੂੰ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਸਰਵਰ ਸਰਟੀਫਿਕੇਟ ਉੱਤੇ ਕਿਸ CA ਨੇ ਦਸਤਖ਼ਤ ਕੀਤੇ। ਹੋਸਟਨਾਮ ਫੇਲ੍ਹ ਹੋਣ ਦਾ ਅਰਥ ਹੈ ਕਿ ਚੇਨ ਠੀਕ ਹੈ ਅਤੇ ਨਾਮ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ, ਜਿਸਦਾ ਆਮ ਅਰਥ ਹੈ ਕਿ ਤੁਸੀਂ ਗਲਤ ਸਰਵਰ ਨਾਲ ਨਹੀਂ, ਸਗੋਂ ਸਹੀ ਸਰਵਰ ਨਾਲ ਗਲਤ ਨਾਮ ਉੱਤੇ ਜੁੜੇ ਹੋ।
ਪ੍ਰੋਂਪਟ ਦਿਸਣਾ ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਨਹੀਂ ਕਿ ਪਾਸਵਰਡ ਪਹਿਲਾਂ ਹੀ ਭੇਜਿਆ ਗਿਆ ਹੈ, ਅਤੇ ਫੇਲ੍ਹ ਹੋਇਆ ਕਨੈਕਸ਼ਨ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਕਲਾਇੰਟ ਤੋਂ ਕੁਝ ਵੀ ਬਾਹਰ ਨਹੀਂ ਗਿਆ। ਜੇ ਤੁਸੀਂ ਪਿਛਲੀ ਘਟਨਾ ਦਾ ਪੁਨਰਨਿਰਮਾਣ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਕਲਾਇੰਟ, ਇਸਦਾ ਸੰਰਚਨਾ, ਪ੍ਰਮਾਣੀਕਰਨ ਪਲੱਗਇਨ ਅਤੇ ਫੇਲ੍ਹ ਹੋਇਆ ਪੜਾਅ ਪਛਾਣੋ। ਅੰਤਿਮ ਗਲਤੀ ਸੁਨੇਹੇ ਤੋਂ ਐਕਸਪੋਜ਼ਰ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣਾ ਅੰਦਾਜ਼ਾ ਹੈ।
ਜਦੋਂ ਨਾਮ ਸੁਰੰਗ ਵਿੱਚੋਂ ਆਉਂਦਾ ਹੈ
ਲੋਕਲ ਪੋਰਟ ਫਾਰਵਰਡਿੰਗ ਪਛਾਣ ਜਾਂਚ ਨੂੰ ਉਸ ਤਰੀਕੇ ਨਾਲ ਤੋੜਦੀ ਹੈ ਜੋ ਲੋਕਾਂ ਨੂੰ ਹੈਰਾਨ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਲੋਕਲ ਪੋਰਟ ਨੂੰ ਡੇਟਾਬੇਸ ਵੱਲ ਫਾਰਵਰਡ ਕਰਦੇ ਹੋ ਅਤੇ localhost ਨਾਲ ਜੁੜਦੇ ਹੋ, ਤਾਂ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਨੂੰ localhost ਦੇ ਵਿਰੁੱਧ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਸ ਨਾਮ ਲਈ ਕੋਈ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਨਹੀਂ ਹੋਇਆ ਸੀ। ਕਨੈਕਸ਼ਨ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੁਰੱਖਿਅਤ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਪੁਸ਼ਟੀ ਫਿਰ ਵੀ ਫੇਲ੍ਹ ਹੋਵੇਗੀ, ਜੋ ਇਹ ਹੈ ਕਿ ਜਾਂਚ ਇਛਿਤ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰ ਰਹੀ ਹੈ।
ਦੋ ਇਮਾਨਦਾਰ ਜਵਾਬ ਹਨ। ਫਾਰਵਰਡ ਕੀਤੇ ਐਂਡਪੌਇੰਟ ਨੂੰ ਉਹ ਨਾਮ ਦਿਓ ਜੋ ਲੂਪਬੈਕ ਪਤੇ ਉੱਤੇ ਹੱਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸਰਵਰ ਸਰਟੀਫਿਕੇਟ ਵਿੱਚ ਦਿਸਦਾ ਹੈ, ਜਾਂ ਹੋਸਟਨਾਮ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਵਰਤੋ ਤਾਂ ਜੋ ਕਲਾਇੰਟ ਅਸਲ ਪਛਾਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੇ। ਪਹਿਲਾ ਡਿਵੈਲਪਰਾਂ ਲਈ ਸੁਵਿਧਾਜਨਕ ਹੈ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਕੰਮ ਮੰਗਦਾ ਹੈ; ਦੂਜਾ ਸੋਚਣ ਵਿੱਚ ਸੌਖਾ ਹੈ ਅਤੇ ਅਕਸਰ ਆਟੋਮੇਸ਼ਨ ਲਈ ਸਹੀ ਡਿਫ਼ਾਲਟ ਹੈ। ਫਾਰਵਰਡਿੰਗ ਕੰਮ ਕਰਨ ਲਈ ਪੁਸ਼ਟੀ ਬੰਦ ਕਰਨਾ ਉਸ ਗੁਣ ਨੂੰ ਸੁੱਟ ਦਿੰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਜੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਸੀ।
ਸਵੀਕ੍ਰਿਤੀ ਤਿੰਨ ਸ਼ਰਤਾਂ ਹੈ
ਸਵੀਕ੍ਰਿਤੀ ਟੈਸਟ ਨੂੰ ਤਿੰਨ ਵੱਖਰੇ ਬਿਆਨਾਂ ਵਜੋਂ ਲਿਖੋ: ਕਨੈਕਸ਼ਨ ਨੇ ਇਛਿਤ ਮਾਰਗ ਵਰਤਿਆ, ਐਨਕ੍ਰਿਪਸ਼ਨ ਤਰਜੀਹ ਨਹੀਂ ਸਗੋਂ ਲਾਜ਼ਮੀ ਸੀ, ਅਤੇ ਸਰਵਰ ਦੀ ਪਛਾਣ ਭਰੋਸੇਯੋਗ ਸਮੱਗਰੀ ਵਿਰੁੱਧ ਪ੍ਰਮਾਣਿਤ ਹੋਈ। ਹਰਾ VPN ਆਇਕਨ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸਥਾਪਿਤ ਨਹੀਂ ਕਰਦਾ।
GUI ਕਲਾਇੰਟ ਅਤੇ MariaDB ਲਈ, ਫਲੈਗ ਦੀ ਸ਼ਬਦ-ਜੋੜ ਉਸੇ ਤਰ੍ਹਾਂ ਲਾਗੂ ਹੁੰਦੀ ਮੰਨਣ ਦੀ ਬਜਾਏ ਵਿਕਰੇਤਾ ਦੇ ਆਪਣੇ ਦਸਤਾਵੇਜ਼ ਦੇਖੋ। MySQL ਐਨਕ੍ਰਿਪਟਡ ਕਨੈਕਸ਼ਨ ਦਸਤਾਵੇਜ਼ ਮੋਡਾਂ ਵਿਚਕਾਰਲੇ ਫ਼ਰਕ ਅਤੇ CA ਵੰਡ ਦੀ ਲੋੜ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਤਪਾਦਨ ਕਨੈਕਸ਼ਨ ਸਤਰ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚਣ ਲਈ ਸੰਦਰਭ ਇਹੀ ਹੈ।