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 ವಿತರಣೆ ಅಗತ್ಯವನ್ನು ಒಳಗೊಂಡಿದೆ, ಮತ್ತು ಉತ್ಪಾದನಾ ಸಂಪರ್ಕ ಸ್ಟ್ರಿಂಗ್ ಬದಲಿಸುವ ಮೊದಲು ಪರಿಶೀಲಿಸಬೇಕಾದ ಉಲ್ಲೇಖ ಇದು.