VPN ಮೂಲಕ ನಿರ್ವಹಿತ ಡೇಟಾಬೇಸ್ ತಲುಪುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಯಾರೂ ರನ್ಬುಕ್ನಲ್ಲಿ ಬರೆಯದ ಕಾರಣದಿಂದ ವಿಫಲವಾಗುತ್ತದೆ: ಸುರಂಗವು ನಿಮ್ಮ ನೆಟ್ವರ್ಕ್ನ ಅಂಚಿನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ, ಆದರೆ ಸೇವೆ ಎಂದೂ ಅದರ ನಿಮ್ಮ ಬದಿಯಲ್ಲಿ ಇರಲಿಲ್ಲ. ಮಾರ್ಗ ಕೋಷ್ಟಕ ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ, ಸುರಂಗವು ಸಕ್ರಿಯವಾಗಿದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಸಂಪರ್ಕವು ಹೇಗಿದ್ದರೂ ಸಮಯ ಮೀರುತ್ತದೆ. ಕೆಳಗಿನ ನಾಲ್ಕು ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಮಾಡಿ ಮತ್ತು ಯಶಸ್ಸಿನ ಷರತ್ತು ಪೂರೈಸದ ಮೊದಲ ಪರಿಶೀಲನೆಯಲ್ಲಿ ನಿಲ್ಲಿಸಿ, ಏಕೆಂದರೆ ಅದರ ನಂತರದ ಪ್ರತಿ ಪರಿಶೀಲನೆಯು ಹಿಂದಿನವು ಉತ್ತೀರ್ಣವಾದದ್ದನ್ನು ಊಹಿಸುತ್ತದೆ.

ಪರಿಶೀಲನೆ ಒಂದು: ಅಂತಿಮ ಬಿಂದು ವಾಸ್ತವವಾಗಿ ಎಲ್ಲಿದೆ?

VPN ಗೇಟ್ವೇ ನೀವು ನಿಯಂತ್ರಿಸುವ ವಿಳಾಸದ ಎರಡು ನೆಟ್ವರ್ಕ್ಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ. ನಿರ್ವಹಿತ ಸೇವೆಯು ಪೂರೈಕೆದಾರರ ಸ್ವಂತ ಮುಂಭಾಗದ ಬಾಗಿಲಿನ ಹಿಂದೆ ನಡೆಯುತ್ತದೆ, ಮತ್ತು ಆ ಬಾಗಿಲು ಉತ್ಪನ್ನದ ಆಧಾರದ ಮೇಲೆ ಮೂರರಲ್ಲಿ ಒಂದು ಆಕಾರವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಯಾವ ಆಕಾರದೊಂದಿಗೆ ವ್ಯವಹರಿಸುತ್ತಿದ್ದೀರಿ ಎಂದು ತಿಳಿಯದಿದ್ದರೆ, ಯಾವುದೇ ಮಾರ್ಗ ಕೆಲಸ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ವೈಫಲ್ಯವು ಮಾರ್ಗದ ವೈಫಲ್ಯವೇ ಆಗಿರದಿರಬಹುದು.

ShapeWhat it meansPass condition
Software on your VMOrdinary subnet addressingRoute and security group permit the client
Attached to your VPCPrivate, but only inside that VPCEndpoint associated, source allowed, route present
Provider-hosted, public endpointOptional private link, not private by defaultA private endpoint exists and DNS points at it

ಹೆಚ್ಚಿನ ವ್ಯರ್ಥ ಮಧ್ಯಾಹ್ನಗಳು ಈ ವರ್ಗೀಕರಣವನ್ನು ಬಿಟ್ಟು ನೇರವಾಗಿ ಮಾರ್ಗ ಕೋಷ್ಟಕಕ್ಕೆ ಹೋಗುವುದರಿಂದ ಉಂಟಾಗುತ್ತವೆ. ಸಾರ್ವಜನಿಕ ಅಂತಿಮ ಬಿಂದುವನ್ನು ಹೊಂದಿರುವ ಪೂರೈಕೆದಾರ-ಹೋಸ್ಟ್ ಮಾಡಿದ ಸೇವೆ, ರೇಖಾಚಿತ್ರ ಏನೇ ಹೇಳಿದರೂ ನಿಮ್ಮ ಸುರಂಗದ ಹಿಂದೆ ಇಲ್ಲ, ಮತ್ತು VPC ಗೆ ಸಂಪರ್ಕಿಸಿದ ಸೇವೆ ಸಾರ್ವಜನಿಕ DNS ಉತ್ತರದಲ್ಲಿ ಎಂದೂ ಕಾಣಿಸುವುದಿಲ್ಲ.

ಪರಿಶೀಲನೆ ಎರಡು: ElastiCache ನಂತಹ VPC ಗೆ ಸಂಪರ್ಕಿಸಿದ ಸೇವೆ

ಆ ರೀತಿಯ ಕ್ಯಾಶೆಗಳನ್ನು ನಿಮ್ಮದೇ VPC ಒಳಗೆ ವಿಳಾಸ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಅವುಗಳಿಗೆ ಇಂಟರ್ನೆಟ್ನತ್ತ ಮುಖ ಮಾಡಿದ ಶ್ರೋತೃವೇ ಇಲ್ಲ. ಅದೇ VPC ನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುವ ಕ್ಲೈಂಟ್ VPN ಅವುಗಳನ್ನು ತಲುಪಬಹುದು, ಆದರೆ ಮೂರು ಷರತ್ತುಗಳು ಒಟ್ಟಿಗೆ ಸೇರಿದಾಗ ಮಾತ್ರ. ಕ್ಯಾಶ್ನ ಅಂತಿಮ ಬಿಂದುವು ನಿಮ್ಮ ಸುರಂಗವು ನೋಡಬಲ್ಲ ಸಬ್ನೆಟ್ಗಳಿಗೆ ಸಂಬಂಧಿಸಿರಬೇಕು, ಅದರ ಭದ್ರತಾ ಗುಂಪು ನಿಮ್ಮ ಕ್ಲೈಂಟ್ಗಳು ಬರುವ ವಿಳಾಸಕ್ಕೆ ಅನುಮತಿ ನೀಡಬೇಕು, ಮತ್ತು ಕ್ಲೈಂಟ್ ಬದಿಗೆ ಕ್ಯಾಶ್ ಸಬ್ನೆಟ್ಗಳನ್ನು ಒಳಗೊಳ್ಳುವ ಮಾರ್ಗ ಬೇಕು.

ಸಾಮಾನ್ಯ ತಪ್ಪು ಎಂದರೆ ಹತ್ತಿರದಲ್ಲಿರುವ ಸಂಪರ್ಕವೂ ಎಣಿಕೆಗೆ ಬರುತ್ತದೆ ಎಂದು ಭಾವಿಸುವುದು. VPN ಅನ್ನು ಬೇರೆ VPC ಗೆ ಸೇರಿಸುವುದು, ಅಥವಾ peering ಮೇಲೆ ಮಾತ್ರ ಅವಲಂಬಿಸುವುದು, ಕ್ಯಾಶ್ನ ಭದ್ರತಾ ಗುಂಪನ್ನು ಅಥವಾ ಅದರ ಸಬ್ನೆಟ್ ಮಾರ್ಗ ಕೋಷ್ಟಕವನ್ನು ನಿಮ್ಮ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ವಿಸ್ತರಿಸುವುದಿಲ್ಲ. ಇರುವ ಸುರಂಗವು ಬೇರೆಡೆ ಕೊನೆಗೊಂಡಾಗ, ಆ VPC ಒಳಗೆ ಇರಿಸಿದ ಜಂಪ್ ಹೋಸ್ಟ್ ಅಥವಾ VPN ಸರ್ವರ್ ಸಾಮಾನ್ಯ ಪರ್ಯಾಯವಾಗಿದೆ. ಆ ಪರ್ಯಾಯವು ವಿನ್ಯಾಸವಲ್ಲ, ಬಳಸುದಾರಿ, ಮತ್ತು ರನ್ಬುಕ್ನಲ್ಲಿ ಅದನ್ನು ಹಾಗೆಯೇ ಗುರುತಿಸಬೇಕು.

ಪರಿಶೀಲನೆ ಮೂರು: ಸಾರ್ವಜನಿಕ ಹೆಸರಿನ PaaS ಅಂತಿಮ ಬಿಂದು

Azure Database for PostgreSQL ಸಾರ್ವಜನಿಕ ಸರ್ವರ್ ಹೆಸರನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತದೆ. ಅದು hosts ಫೈಲ್ನಲ್ಲಿ ಪಿನ್ ಮಾಡಿ ಗೇಟ್ವೇ ಮೂಲಕ ಮಾರ್ಗ ಮಾಡಬಹುದಾದ ಖಾಸಗಿ ವಿಳಾಸವನ್ನು ನೀಡುವುದಿಲ್ಲ. ವರ್ಚುವಲ್ ನೆಟ್ವರ್ಕ್ ಸೇವಾ ಅಂತಿಮ ಬಿಂದುಗಳು ಯಾವ ಸಬ್ನೆಟ್ಗಳು ಸಂಪನ್ಮೂಲವನ್ನು ತಲುಪಬಹುದು ಎಂಬುದನ್ನು ಸೀಮಿತಗೊಳಿಸುತ್ತವೆ; ಅವು VPN ಮೂಲಕ ಬರುವ ಸ್ಥಳೀಯ ಕ್ಲೈಂಟ್ಗೆ ಅಧಿಕಾರ ನೀಡುವುದಿಲ್ಲ.

ಖಾಸಗಿ ಪ್ರವೇಶ ಪಡೆಯುವುದು ಎಂದರೆ ಖಾಸಗಿ ಅಂತಿಮ ಬಿಂದು ಅಥವಾ ಖಾಸಗಿ ಲಿಂಕ್ ವಿನ್ಯಾಸವನ್ನು ಪರಿಚಯಿಸಿ, ನಂತರ ಖಾಸಗಿ DNS ವಲಯವನ್ನು ಸೇರಿಸುವುದು, ಇದರಿಂದ ಸಾರ್ವಜನಿಕ ಹೆಸರು ಇಂಟರ್ನೆಟ್ ಬದಲು ಆ ಅಂತಿಮ ಬಿಂದುವಿನೊಂದಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ. ಸೇವಾ ಅಂತಿಮ ಬಿಂದು ನಿಯಮದೊಂದಿಗೆ ಸೇರಿಸಿದ VPN ಬೇರೆ ವಾಸ್ತುಶಿಲ್ಪವಾಗಿದ್ದು ರೇಖಾಚಿತ್ರದಲ್ಲಿ ಮಾತ್ರ ಹೋಲುತ್ತದೆ. App Service ಅದೇ ತರ್ಕವನ್ನು ವಿರುದ್ಧ ದಿಕ್ಕಿನಿಂದ ಅನುಸರಿಸುತ್ತದೆ: VNet ಸಂಯೋಜನೆ ಅಪ್ಲಿಕೇಶನ್ಗೆ VNet ಗೆ ಹೊರಹೋಗುವ ಕರೆಗಳನ್ನು ಮಾಡಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ, ಮತ್ತು ಅದು ನಿಮ್ಮ ಸುರಂಗದಿಂದ ಒಳಬರುವ ಖಾಸಗಿ ಮಾರ್ಗವನ್ನು ಸೃಷ್ಟಿಸುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ಒಳಬರುವ ಖಾಸಗಿ ಪ್ರವೇಶಕ್ಕೆ ಖಾಸಗಿ ಅಂತಿಮ ಬಿಂದು, App Service ಪರಿಸರ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಮುಂದೆ ಇರಿಸಿದ ಗೇಟ್ವೇ ಬೇಕು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನು ಬಳಸಬಹುದು ಎಂಬುದು ಯೋಜನೆಯ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ.

ಪರಿಶೀಲನೆ ನಾಲ್ಕು: ತಮ್ಮದೇ ಮುಂಭಾಗದ ಬಾಗಿಲನ್ನು ಹೊಂದಿರುವ ಉತ್ಪನ್ನಗಳು

Firebase Hosting ಅನ್ನು Cloud VPN ಗೆ ಸೇರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ಹೋಸ್ಟಿಂಗ್ ಪದರವು ಜಾಗತಿಕ ಮುಂಭಾಗವೇ ಹೊರತು ಯೋಜನೆಯ VPC ಒಳಗಿನ ಯಾವುದೋ ಅಲ್ಲ. ದಾಖಲಿತ ಪರ್ಯಾಯ ಎಂದರೆ ನಿಯಂತ್ರಿತ ಪ್ರವೇಶ ಬಿಂದುವನ್ನು ನೀವೇ ನಿರ್ಮಿಸುವುದು, ಪ್ರಾಕ್ಸಿ ಇನ್ಸ್ಟಾನ್ಸ್ ಅಥವಾ ಬಕೆಟ್ನಿಂದ ಬೆಂಬಲಿತ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ನೊಂದಿಗೆ. ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಸೈಟ್ ಶುದ್ಧ ಹೋಸ್ಟಿಂಗ್ ಉತ್ಪನ್ನವಾಗಿರುವುದನ್ನು ನಿಲ್ಲಿಸಿ ಈಗ ನೀವು ನಿರ್ವಹಿಸುವ ಮೂಲಸೌಕರ್ಯವಾಗುತ್ತದೆ. ಸುರಂಗವು ಅದನ್ನು ಆವರಿಸುತ್ತದೆ ಎಂದು ಯಾರಾದರೂ ಭರವಸೆ ನೀಡುವ ಮೊದಲು ಈ ವಿನಿಮಯವನ್ನು ಹೆಸರಿಸುವುದು ಯೋಗ್ಯ.

Private API Gateway VPC ಸೇವೆಗಳ ಬದಿಗೆ ಹತ್ತಿರವಿದೆ: interface ಮಾದರಿಯ VPC ಅಂತಿಮ ಬಿಂದುವು ಉತ್ತರಗಳು ಖಾಸಗಿ ವಿಳಾಸಗಳಾಗಿರುವ ಹೋಸ್ಟ್ಹೆಸರನ್ನು ಪ್ರಕಟಿಸುತ್ತದೆ, ಮತ್ತು ನಿಮ್ಮ ಆವರಣದಿಂದ ಸಂಚಾರವು ಸುರಂಗ ಅಥವಾ ಮೀಸಲಾದ ಪರಸ್ಪರ ಸಂಪರ್ಕದ ಮೂಲಕ ಬರುತ್ತದೆ. ಅಂತಿಮ ಬಿಂದುವು API ಗೆ ಸಂಬಂಧಿಸಿರಬೇಕು, ಮತ್ತು ಪ್ರಮಾಣಪತ್ರ ಹಾಗೂ ಹೋಸ್ಟ್ಹೆಸರು ಕರೆ ಮಾಡುವವರು ಬಳಸುವ ಕಸ್ಟಮ್ ಡೊಮೇನ್ಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು.

Google Cloud VPN ಸುರಂಗಗಳು ಹೆಸರುಗಳಿಗಲ್ಲ, ಸಹವರ್ತಿ IP ವಿಳಾಸಗಳಿಗೆ ಬಂಧಿಸುತ್ತವೆ. DNS ಮುಂದಕ್ಕೆ ರವಾನೆ ಪ್ರತ್ಯೇಕವಾಗಿ ಸಂರಚಿಸಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಸುರಂಗವು ಸಂಪೂರ್ಣ ಆರೋಗ್ಯಕರವಾಗಿದ್ದರೂ ದೂರದ ಖಾಸಗಿ ವಲಯದಲ್ಲಿ ಹುಡುಕಾಟಗಳು ಇನ್ನೂ ವಿಫಲವಾಗಬಹುದು.

ನಂತರ ಗಡಿಯನ್ನು ಪತ್ತೆ ಮಾಡಿ

VPC ಒಳಗಿನ VM ನಿಂದ ಅದೇ ಸಂಪರ್ಕವನ್ನು ನಡೆಸಿ. ಅಲ್ಲಿ ಯಶಸ್ವಿಯಾಗಿ VPN ಕ್ಲೈಂಟ್ನಿಂದ ವಿಫಲವಾದರೆ, ಅಂತರವು ಕ್ಲೈಂಟ್ ಮಾರ್ಗ ಮತ್ತು ಸೇವೆಯ ಅಂತಿಮ ಬಿಂದುವಿನ ನಡುವೆ ಇರುತ್ತದೆ: ಮಾರ್ಗ, ಭದ್ರತಾ ಗುಂಪು, ಅಂತಿಮ ಬಿಂದು ನೀತಿ ಅಥವಾ ಹೆಸರು. ಎರಡೂ ಪ್ರಯತ್ನಗಳು ವಿಫಲವಾದರೆ, ಆ ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಯಾವುದೂ ಸೇವೆಯನ್ನು ತಲುಪಲಾರದು, ಮತ್ತು VPN ಎಂದೂ ಅಡಚಣೆಯಾಗಿರಲಿಲ್ಲ.

getent hosts db.internal.example
nc -vz db.internal.example 5432

ಹೆಸರಿನ ಹುಡುಕಾಟ ಮತ್ತು ಪೋರ್ಟ್ ಪರಿಶೀಲನೆಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಮಾಡಿ, ಏಕೆಂದರೆ ಅವು ಬೇರೆ ಬೇರೆ ಕಾರಣಗಳಿಂದ ವಿಫಲವಾಗುತ್ತವೆ ಮತ್ತು ಆ ಜೋಡಿ ಮಾರ್ಗದ ಯಾವ ಅರ್ಧ ಭಾಗ ಮುರಿದಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ. ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಪರಿಹರಿಸುವ ಹೆಸರು ಖಾಸಗಿ DNS ವಲಯವು ಕಾರ್ಯರೂಪದಲ್ಲಿಲ್ಲ ಎಂದು ನಿಮಗೆ ಹೇಳುತ್ತದೆ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು