Cloud SQL Auth Proxy vs ಡೇಟಾಬೇಸ್‌ಗೆ ನೇರ VPN ರೂಟ್
Auth Proxy ಮತ್ತು ನೇರ VPN ರೂಟ್ ಒಂದೇ ಸಮಸ್ಯೆಯ ಬೇರೆ ಬೇರೆ ಅರ್ಧಗಳನ್ನು ಪರಿಹರಿಸುತ್ತವೆ. ಮೊದಲು ಕನೆಕ್ಟರ್ ಅಧಿಕಾರ, ಪೋರ್ಟ್‌ಗಳು ಮತ್ತು ಡೇಟಾಬೇಸ್ ಲಾಗಿನ್ ಹೋಲಿಸಿ.
VPN ನಲ್ಲಿರುವ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಿಂದ ಖಾಸಗಿ Cloud SQL ಇನ್‌ಸ್ಟಾನ್ಸ್‌ಗೆ ತಲುಪಲು ಎರಡು ಸಮಂಜಸ ದಾರಿಗಳಿವೆ. ಒಂದು ನಿಮ್ಮ ಬಳಿ ಈಗಾಗಲೇ ಇರುವ ರೂಟ್ ಮೂಲಕ ಇನ್‌ಸ್ಟಾನ್ಸ್‌ನ ಖಾಸಗಿ ವಿಳಾಸಕ್ಕೆ ನೇರ ಸಂಪರ್ಕ. ಇನ್ನೊಂದು Cloud SQL Auth Proxy, ಅದು loopback ನಲ್ಲಿ ಕೇಳುತ್ತದೆ ಮತ್ತು Cloud SQL ಗೆ ಸಂಪರ್ಕವನ್ನು ತಾನೇ ತೆರೆಯುತ್ತದೆ. ಇವು ಸ್ಪರ್ಧಾತ್ಮಕ ಉತ್ಪನ್ನಗಳಿಗಿಂತ ಹೆಚ್ಚಾಗಿ, ರುಜುವಾತು ಯಾರ ಬಳಿ ಇದೆ ಮತ್ತು ರೂಟ್ ಯಾರ ಬಳಿ ಇದೆ ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಎರಡು ವಿಭಿನ್ನ ಉತ್ತರಗಳು. ತಪ್ಪು ಆಯ್ಕೆ ಸಾಮಾನ್ಯವಾಗಿ ನೆಟ್‌ವರ್ಕ್ ದೋಷದಂತೆ ಓದುವ ಅಧಿಕಾರ ದೋಷವಾಗಿ ಕಾಣಿಸುತ್ತದೆ.
ನಾನು ತಂಡದ ಮುಂದೆ ಇಡುವ ಹೋಲಿಕೆ ಇದು, ನಂತರ ಅದನ್ನು ನಿಜವಾಗಿ ನಿರ್ಣಯಿಸುವ ಪರಿಶೀಲನೆಗಳು.
ಒಂದೇ ಇನ್‌ಸ್ಟಾನ್ಸ್‌ಗೆ ಎರಡು ಮಾರ್ಗಗಳು
ನೇರ ಮಾರ್ಗವು ನಿಮ್ಮ ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಪ್ರಾಜೆಕ್ಟ್‌ನ VPC ಗೆ private-services-access ರೂಟ್ ಬಳಸುತ್ತದೆ. ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಇನ್‌ಸ್ಟಾನ್ಸ್‌ನ ಖಾಸಗಿ ವಿಳಾಸದೊಂದಿಗೆ PostgreSQL ಮಾತನಾಡುತ್ತದೆ, ಮತ್ತು ಸಂಪರ್ಕವು ರೂಟಿಂಗ್, firewall ನಿಯಮಗಳು ಮತ್ತು ಡೇಟಾಬೇಸ್ ರುಜುವಾತುಗಳ ಮೇಲೆ ಬದುಕುತ್ತದೆ ಅಥವಾ ಸಾಯುತ್ತದೆ.
ಪ್ರಾಕ್ಸಿ ಮಾರ್ಗವು ಅದೇ ರೂಟ್ ಬಳಸುತ್ತದೆ ಆದರೆ ಸ್ಥಳೀಯ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸೇರಿಸುತ್ತದೆ. ಪ್ರಾಕ್ಸಿ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ default credentials ನೊಂದಿಗೆ Google API ಗೆ ದೃಢೀಕರಿಸುತ್ತದೆ, ಕನೆಕ್ಟರ್ ಮೂಲಕ ಇನ್‌ಸ್ಟಾನ್ಸ್‌ಗೆ ಸಂಪರ್ಕ ತೆರೆಯುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಕ್ಲೈಂಟ್ PostgreSQL ಎಂದು ಪರಿಗಣಿಸುವ loopback ಪೋರ್ಟ್ ಒದಗಿಸುತ್ತದೆ. ಎರಡು ಜಿಗಿತಗಳು ಮೂರಾಗುತ್ತವೆ, ಮತ್ತು ಮಧ್ಯದ್ದು IAM ಅಧಿಕಾರವನ್ನು ಹೊರುತ್ತದೆ. VPN ರೂಟ್ ಇನ್ನೂ ನಿಮ್ಮ ನಿರ್ವಹಣೆಯದ್ದೇ, ಮತ್ತು ಪ್ರಾಕ್ಸಿ ಅದನ್ನು ಆ ಪರಿಶೀಲನೆಯ ಬದಲಿಯೆಂದು ಎಂದಿಗೂ ಪರಿಗಣಿಸುವುದಿಲ್ಲ.
ಪ್ರತಿ ಮಾರ್ಗವು ನಿಜವಾಗಿ ಏನನ್ನು ಅಧಿಕಾರ ನೀಡುತ್ತದೆ
ಅತ್ಯಂತ ಮುಖ್ಯ ವ್ಯತ್ಯಾಸವೆಂದರೆ ಪ್ರತಿ ಆಯ್ಕೆಯು ನಿಮ್ಮ ಪರವಾಗಿ ಏನನ್ನು ಅಧಿಕಾರ ನೀಡಬಹುದು:
| Question | Direct private IP | Auth Proxy |
|---|---|---|
| Who proves identity to the network | Your client, through the VPN and a database login | The proxy, through IAM to Google's API |
| IAM role needed for the connector | None | Cloud SQL Client or equivalent |
| Database user authentication | Always required | Still required unless IAM database authentication is enabled |
| Shape of the local leg | Client to instance | Client to loopback, proxy to instance |
ಪ್ರಾಕ್ಸಿಯ IAM ಪರಿಶೀಲನೆ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಲಾಗಿನ್ ಬೇರೆ ಬೇರೆ ದ್ವಾರಗಳು, ಮತ್ತು ಒಂದರ ಮೂಲಕ ಹೋದರೆ ಇನ್ನೊಂದು ತೆರೆಯುವುದಿಲ್ಲ. ಪ್ರಾಕ್ಸಿ ಆನ್ ಮಾಡಿ ಅಪ್ಲಿಕೇಶನ್ ಖಾತೆ ಇನ್ನು ಬೇಕಿಲ್ಲ ಎಂದು ಭಾವಿಸುವ ತಂಡವು ನೆಟ್‌ವರ್ಕಿಂಗ್‌ಗೆ ಸಂಬಂಧವಿಲ್ಲದ ಪಾಸ್‌ವರ್ಡ್ ವೈಫಲ್ಯಗಳಲ್ಲಿ ಮಧ್ಯಾಹ್ನ ಕಳೆಯುತ್ತದೆ.
ಪೋರ್ಟ್‌ಗಳು ಮತ್ತು ಮಾರ್ಗಗಳು, ಅಕ್ಕಪಕ್ಕ
ಪ್ರಾಕ್ಸಿಗೆ API ಗಾಗಿ ಹೊರಹೋಗುವ TCP 443 ಮತ್ತು ಇನ್‌ಸ್ಟಾನ್ಸ್ ಸಂಪರ್ಕಕ್ಕಾಗಿ TCP 3307 ಬೇಕು, ಎರಡೂ Google ನ Auth Proxy ಅವಲೋಕನದಲ್ಲಿ ವಿವರಿಸಲಾಗಿದೆ. ನಿಮ್ಮ VPN ರೂಟ್ ಎರಡನೆಯದನ್ನು ಆವರಿಸುತ್ತದೆ; ಮೊದಲನೆಯದು ಸಾಮಾನ್ಯವಾಗಿ ಸಾಮಾನ್ಯ ಮಾರ್ಗದಿಂದ ಹೊರಡುತ್ತದೆ.
ನೇರ ಸಂಪರ್ಕಕ್ಕೆ ಇನ್‌ಸ್ಟಾನ್ಸ್‌ನ PostgreSQL ಪೋರ್ಟ್ ಖಾಸಗಿ ರೂಟ್ ಮೂಲಕ ತಲುಪಬಲ್ಲದಾಗಿರಬೇಕು, ಅದು ಸಂಪೂರ್ಣ ಬೇರೆ firewall ಮಾತುಕತೆ. ನಿಮ್ಮ ನೆಟ್‌ವರ್ಕ್ ತಂಡವು ಕ್ಲೈಂಟ್ ಸಬ್‌ನೆಟ್‌ಗಳಿಂದ ಕೇವಲ 443 ಹೊರಹೋಗಲು ಅನುಮತಿಸಿದರೆ, ಪ್ರಾಕ್ಸಿ ಯಾವುದೇ ನಿಯಮ ಬದಲಾವಣೆ ಇಲ್ಲದೆ ಹೊಂದುತ್ತದೆ ಮತ್ತು ನೇರ ಮಾರ್ಗ ಹೊಂದುವುದಿಲ್ಲ. ಈ ಒಂದೇ ಸತ್ಯವು ಯಾವುದೇ ವಾಸ್ತುಶಿಲ್ಪದ ಆದ್ಯತೆಗಿಂತ ಹೆಚ್ಚಾಗಿ ಆಯ್ಕೆಯನ್ನು ನಿರ್ಣಯಿಸುತ್ತದೆ.
ಎರಡೂ ಮಾರ್ಗಗಳು ಇನ್‌ಸ್ಟಾನ್ಸ್‌ಗೆ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಇರಬೇಕೆಂದು ಒತ್ತಾಯಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಯಾವುದೂ ಒಂದನ್ನು ಸೇರಿಸುವುದನ್ನು ಸಮರ್ಥಿಸುವುದಿಲ್ಲ.
ಪ್ರಾಕ್ಸಿ ಸಹಾಯ ಮಾಡದ ಸ್ಥಳ
ಪ್ರಾಕ್ಸಿ ಕಾಣೆಯಾದ ರೂಟ್ ಸರಿಪಡಿಸುವುದಿಲ್ಲ. private-services-access ರೂಟ್ ಇಲ್ಲದಿದ್ದರೆ, ಅಥವಾ VPN ಅದನ್ನು ಸಾಗಿಸದಿದ್ದರೆ, ಕನೆಕ್ಟರ್ ವಿಫಲವಾಗುತ್ತದೆ, ಆದರೆ ಸ್ಥಳೀಯ ಶ್ರೋತೃ ಇನ್ನೂ ಅಲ್ಲೇ ಕುಳಿತು ಕೇಳುತ್ತಿರುತ್ತದೆ, ಮತ್ತು ಗೊಂದಲದ ಭಾಗ ಅದೇ.
ಅದು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಪ್ರಾಕ್ಸಿಯ ನಡುವಿನ ಭಾಗವನ್ನೂ ರಕ್ಷಿಸುವುದಿಲ್ಲ. ಒಂದೇ ಲ್ಯಾಪ್‌ಟಾಪ್‌ನಲ್ಲಿ ಆ ಭಾಗ loopback ಮತ್ತು ಸರಿ. ಸಹೋದ್ಯೋಗಿ ತಲುಪಬೇಕೆಂದು ಶ್ರೋತೃವನ್ನು wildcard ವಿಳಾಸಕ್ಕೆ ಬಿಗಿದರೆ, ನೀವು ದೃಢೀಕರಣವಿಲ್ಲದ ಡೇಟಾಬೇಸ್ ಗೇಟ್‌ವೇ ಕಟ್ಟಿ ಅದನ್ನು ಅನುಕೂಲ ಎಂದು ಕರೆದಿದ್ದೀರಿ. ಅದನ್ನು loopback ನಲ್ಲೇ ಇರಿಸಿ ಮತ್ತು ಸಹೋದ್ಯೋಗಿ ತಮ್ಮದೇ ರುಜುವಾತು ಪಡೆಯಲಿ.
ಮತ್ತು ಅದು Private Service Connect ಮತ್ತು private services access ಅನ್ನು ಪರಸ್ಪರ ಬದಲಾಯಿಸಬಹುದಾದಂತೆ ಮಾಡುವುದಿಲ್ಲ. PSC ಇನ್‌ಸ್ಟಾನ್ಸ್‌ಗೆ ತನ್ನದೇ DNS ವ್ಯವಸ್ಥೆ ಮತ್ತು --private-ip ರೂಪದ ಬದಲು --psc ಕರೆ ಬೇಕು.
ಆಯ್ಕೆ ಮಾಡಿ, ನಂತರ ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಪರಿಶೀಲಿಸಿ
ಮಾರ್ಗದಲ್ಲಿ IAM, ಅಲ್ಪಾಯುಷ್ಯ ರುಜುವಾತುಗಳು ಮತ್ತು ಒಳಬರುವ firewall ನಲ್ಲಿ ಯಾವುದೇ ಬದಲಾವಣೆ ಬೇಡವಾದರೆ ಪ್ರಾಕ್ಸಿ ಆಯ್ಕೆಮಾಡಿ.
ಬೆಂಬಲಿತ ಕ್ಲೈಂಟ್ ಈಗಾಗಲೇ ಬಲವಾದ ಡೇಟಾಬೇಸ್ ರುಜುವಾತುಗಳನ್ನು ಹೊಂದಿದ್ದು ನೆಟ್‌ವರ್ಕ್ ತಂಡ ಪೋರ್ಟ್ ತೆರೆಯಲು ಸಿದ್ಧವಿದ್ದರೆ ನೇರ ಮಾರ್ಗ ಆಯ್ಕೆಮಾಡಿ. ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ, ಯಶಸ್ವಿ ಸಂಪರ್ಕದ ಬದಲು ನಿಜವಾದ ಪ್ರಶ್ನೆಯಿಂದ ಪರಿಶೀಲಿಸಿ: ಸಂಪರ್ಕಿಸಿ, ತಿಳಿದಿರುವ ಕೋಷ್ಟಕದ ಮೇಲೆ ಒಂದು ಓದನ್ನು ನಡೆಸಿ ಮತ್ತು ಸರ್ವರ್ ನಿಮ್ಮ ಸೆಷನ್ ಬಗ್ಗೆ ಏನನ್ನು ನೋಡುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ.
VPN ಮತ್ತೆ ಸಂಪರ್ಕಗೊಂಡ ನಂತರ, ಅವಧಿ ಮುಗಿದ ರುಜುವಾತು, ಕಾಣೆಯಾದ ಖಾಸಗಿ ರೂಟ್ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಲಾಗಿನ್ ನಿರಾಕರಣೆಯನ್ನು ಮೂರು ಬೇರೆ ಬೇರೆ ವೈಫಲ್ಯಗಳೆಂದು ಪರಿಗಣಿಸಿ. ಅವುಗಳಲ್ಲಿ ಒಂದೇ ನೆಟ್‌ವರ್ಕ್ ಸಮಸ್ಯೆ, ಮತ್ತು ಒಂದೇ ಮಾತ್ರ ಎಂದಿಗೂ firewall ನಿಯಮ ಬದಲಿಸಲು ಕಾರಣವಾಗಬೇಕು.