VPN ಮೂಲಕ Google API: ಸಬ್ನೆಟ್ ಮಾತ್ರವಲ್ಲ, VIP ಗೆ ರೂಟ್ ಮಾಡಿ
VPC ಸಬ್ನೆಟ್ಗೆ ಇರುವ ರೂಟ್ API ಯ VIP ವಿಳಾಸಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದಿಲ್ಲ. ಸರಿಯಾದ ಹೆಸರುಗಳನ್ನು ಪರಿಹರಿಸಿ, VIP ಪ್ರಿಫಿಕ್ಸ್ ಘೋಷಿಸಿ, VPC ಯಲ್ಲಿ ಹಿಂತಿರುಗುವ ದಾರಿ ಇರಿಸಿ, ನಂತರ HTTPS ಪರೀಕ್ಷಿಸಿ.
SSH ಮೂಲಕ ಆನ್-ಪ್ರಿಮೈಸ್ ಸರ್ವರ್ ಪ್ರವೇಶಿಸಿ, ಟನೆಲ್ ಮೇಲಕ್ಕೆತ್ತಿ ಮತ್ತು ಖಾಸಗಿ VM ಉತ್ತರಿಸುತ್ತದೆ; ನಂತರ Google API ಗೆ ಮೊದಲ ಕರೆ ರೂಟ್ ಇಲ್ಲದೆ ವಿಫಲವಾಗುತ್ತದೆ. VM ಯ ಸಬ್ನೆಟ್ ಮತ್ತು API ಯ VIP ವಿಳಾಸಗಳು ಬೇರೆ ಬೇರೆ ಗಮ್ಯಸ್ಥಾನಗಳು, ಆದ್ದರಿಂದ ಒಂದಕ್ಕಿರುವ ರೂಟ್ ಇನ್ನೊಂದನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದಿಲ್ಲ. ಖಾಸಗಿ API ಕರೆ ಕೆಲಸ ಮಾಡುವ ಮೊದಲು ಮೂರು ಷರತ್ತುಗಳು ಪೂರೈಸಬೇಕು. API ಹೆಸರು VIP ಗೆ ಪರಿಹರಿಸಬೇಕು, VIP ಪ್ರಿಫಿಕ್ಸ್ ಟನೆಲ್ ಮೂಲಕ ಘೋಷಿಸಬೇಕು, ಮತ್ತು VPC ಉತ್ತರವನ್ನು ಹೇಗೆ ಹಿಂತಿರುಗಿಸಬೇಕೆಂದು ತಿಳಿದಿರಬೇಕು. ಪಿಂಗ್ ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಸಬ್ನೆಟ್ನಲ್ಲಿರುವ ಯಂತ್ರಕ್ಕೆ ಕೆಲಸ ಮಾಡುವ SSH ಸೆಷನ್ ಕೂಡ ಹೇಳುವುದಿಲ್ಲ.
API ಯ VIP ವಿಳಾಸಗಳು ಪ್ರತ್ಯೇಕ ಗಮ್ಯಸ್ಥಾನಗಳು
Google ಆನ್-ಪ್ರಿಮೈಸ್ ನೆಟ್ವರ್ಕ್ನಿಂದ API ಪ್ರವೇಶಕ್ಕಾಗಿ ಮೀಸಲಾದ VIP ವಿಳಾಸಗಳನ್ನು ಪ್ರಕಟಿಸುತ್ತದೆ, ಮತ್ತು API ಹೆಸರುಗಳಿಗೆ ನಿಮ್ಮ DNS ಹಿಂತಿರುಗಿಸಬೇಕಾದದ್ದು ಅದೇ ವಿಳಾಸಗಳನ್ನು. ಎರಡೂ ಸಣ್ಣ ಪ್ರಿಫಿಕ್ಸ್ಗಳು ಮತ್ತು ಯಾವುದೂ RFC 1918 ಸ್ಥಳವಲ್ಲ:
| Record | Resolves to | What it does not give you |
|---|---|---|
| private.googleapis.com | 199.36.153.8/30, the general front door for Google APIs | not a bypass around a service perimeter |
| restricted.googleapis.com | 199.36.153.4/30, reachable only for services a perimeter allows | not the whole API surface, so some names stay out of reach |
ಸಾರ್ವಜನಿಕವಾಗಿ ಕಾಣುವ ವಿಳಾಸಗಳು ರೂಟ್ ಟನೆಲ್ ಬಿಡಬೇಕೆಂದು ಅರ್ಥವಲ್ಲ ಸಾಮಾನ್ಯ ಇಂಟರ್ನೆಟ್ಗೆ. ಪ್ರಿಫಿಕ್ಸ್ಗಳು ಇರುವುದು ಆನ್-ಪ್ರಿಮೈಸ್ ಕ್ಲೈಂಟ್ ಯಾವುದೋ ನಿರಂಕುಶ ನಿರ್ಗಮನ ಬಿಂದುವಿನ ಬದಲು ಬೆಂಬಲಿತ ದಾರಿಯಲ್ಲಿ Google ನ ಮುಂಭಾಗಗಳನ್ನು ತಲುಪಲು. ಅವನ್ನು ಟನೆಲ್ಗೆ ಸೇರಿದ ಗಮ್ಯಸ್ಥಾನಗಳೆಂದು ಪರಿಗಣಿಸಿ, ಪರಿಶೀಲಿಸಬೇಕಾದ ಹೋಸ್ಟ್ಗಳೆಂದಲ್ಲ. ಇಂಟರ್ನೆಟ್ ನಿರ್ಗಮನಕ್ಕಾಗಿ ಬರೆದ ಫೈರ್ವಾಲ್ ನಿಯಮ ಸಾಮಾನ್ಯವಾಗಿ ಅವನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ, ಮತ್ತು ಕರೆ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲೇ ವಿಫಲವಾಗುವುದಕ್ಕೆ ಇದು ಸಾಮಾನ್ಯ ಕಾರಣ.
ಯಾವ ಎಂಡ್ಪಾಯಿಂಟ್ ತಲುಪುತ್ತೀರಿ ಎಂಬುದನ್ನು DNS ನಿರ್ಧರಿಸುತ್ತದೆ
ಆಯ್ಕೆ ಮಾಡಿದ ಎಂಡ್ಪಾಯಿಂಟ್ಗೆ Google ದಾಖಲಿಸುವ ರೆಕಾರ್ಡ್ಗಳಿಗೆ ಸ್ಥಳೀಯ ರಿಜಾಲ್ವರ್ ತಿರುಗಿಸಿ, ಇದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ಗೆ ಬೇಕಾದ ಹೆಸರುಗಳು ಆ VIP ಯಿಂದ ಉತ್ತರಿಸುತ್ತವೆ. ಕೇವಲ googleapis.com ಮ್ಯಾಪಿಂಗ್ ಮಾಡುವುದು ಯಾವುದೇ ಇನ್ವೆಂಟರಿ ಅಲ್ಲ: ಪ್ಯಾಕೇಜ್ ರಿಜಿಸ್ಟ್ರಿಗಳು, ಕಂಟೇನರ್ ರಿಜಿಸ್ಟ್ರಿಗಳು ಮತ್ತು ಮೈಗ್ರೇಶನ್ ಕನೆಕ್ಟರ್ಗಳಿಗೆ ಅವುಗಳದೇ ದಾಖಲಿತ ಹೆಸರುಗಳಿವೆ. ನಿರ್ಬಂಧಿತ VIP ಕೂಡ ಪ್ರತಿ ಸೇವೆಯನ್ನೂ ಒಯ್ಯುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಪರಿಹರಿಸಲಾದ ಹೆಸರು ಇನ್ನೂ ಬೆಂಬಲಿತವಾಗದಿರಬಹುದು. ರಿಜಾಲ್ವರ್ ಮುಟ್ಟುವ ಮೊದಲು ಅಪ್ಲಿಕೇಶನ್ ನಿಜವಾಗಿ ಸಂಪರ್ಕಿಸುವ ಡೊಮೇನ್ಗಳನ್ನು ಬರೆದಿಡಿ.
ಸೇವಾ ಹೆಸರಿನ ಬದಲಿಗೆ VPC VM ವಿಳಾಸವನ್ನು ಊಹಿಸುವುದು ಪರಿಹಾರವಲ್ಲ, ಮತ್ತು ಅದು ಸಾಮಾನ್ಯವಾಗಿ DNS ಕೊರತೆಯನ್ನು ಇನ್ನೊಬ್ಬ ಕ್ಲೈಂಟ್ ವಿಫಲವಾಗುವವರೆಗೆ ಮುಚ್ಚಿಡುತ್ತದೆ.
VIP ಪ್ರಿಫಿಕ್ಸ್ ಘೋಷಿಸಿ, ಉಳಿದದ್ದನ್ನು ಇರಿಸಿ
BGP ಆಧಾರಿತ ಸಂಪರ್ಕದಲ್ಲಿ, Cloud Router ಆಯ್ಕೆ ಮಾಡಿದ VIP ಪ್ರಿಫಿಕ್ಸ್ ಘೋಷಿಸಬೇಕು, ಇದರಿಂದ ಸ್ಥಳೀಯ ರೌಟರ್ ಉದ್ದೇಶಿತ ಸೆಷನ್ ಮೂಲಕ ಆ ಶ್ರೇಣಿಯನ್ನು ಕಲಿಯುತ್ತದೆ. ಕೇವಲ VPC ಸಬ್ನೆಟ್ಗಳನ್ನು ಘೋಷಿಸುವುದು ಆ ಶ್ರೇಣಿಯನ್ನು ಸೇರಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಸ್ಥಳೀಯ ರೌಟರ್ ಆ ವಿಳಾಸಗಳಿಗೆ ತನ್ನ ಡಿಫಾಲ್ಟ್ ದಾರಿಯನ್ನೇ ಬಳಸುತ್ತಲೇ ಇರುತ್ತದೆ. ರೂಟಿಂಗ್ ಕೋಷ್ಟಕದಲ್ಲಿರುವ ಪ್ರಿಫಿಕ್ಸ್ ಮಾತ್ರ ಘೋಷಣೆ ಸೆಷನ್ ದಾಟಿತು ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿ.
ಹೊಸದನ್ನು ಸೇರಿಸುವಾಗ ಇರುವ ಘೋಷಣೆಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ, ಏಕೆಂದರೆ ರೌಟರ್ ಮಟ್ಟ ಮತ್ತು ಪೀರ್ ಮಟ್ಟದ ಆಯ್ಕೆಗಳಿಗೆ ಬೇರೆ ಬೇರೆ ವ್ಯಾಪ್ತಿ ಇರುತ್ತದೆ, ಮತ್ತು ಗುಂಪನ್ನು ಬದಲಿಸುವುದು ಈಗಾಗಲೇ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದ ನೆಟ್ವರ್ಕ್ಗಳನ್ನು ಹಿಂಪಡೆಯಬಹುದು. ನಂತರ ಪೂರ್ತಿ ರೌಟರ್ನಲ್ಲಿ ಅಲ್ಲ, ಪ್ರತಿ ಸೆಷನ್ ನಲ್ಲಿ ಪರಿಣಾಮಕಾರಿ ಘೋಷಣೆ ಪರಿಶೀಲಿಸಿ. ಕಾಣೆಯಾದ ಪ್ರಿಫಿಕ್ಸ್ ಮತ್ತು ಹಿಂಪಡೆದ ಪ್ರಿಫಿಕ್ಸ್ ಸ್ಥಳೀಯ ಕಡೆಯಿಂದ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ, ಆದ್ದರಿಂದ ಸೆಷನ್ ನೋಟವೇ ಬಿಟ್ಟುಬಿಡುವಿಕೆಯನ್ನು ರಿಗ್ರೆಶನ್ನಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ.
VPC ಕಡೆಗೆ ತನ್ನದೇ ರೂಟ್ ಮತ್ತು ಹಿಂತಿರುಗುವ ದಾರಿ ಬೇಕು
VPC ಒಳಗೆ, VIP ದಾರಿ ಮುಂದಿನ ಹಾಪ್ ಆಗಿ ಡಿಫಾಲ್ಟ್ ಇಂಟರ್ನೆಟ್ ಗೇಟ್ವೇ ಬಳಸಬೇಕು, ಮತ್ತು ಹೆಸರಿನ ಹೊರತಾಗಿಯೂ ಆ ಸಂಚಾರ Google ನ ನೆಟ್ವರ್ಕ್ನಲ್ಲೇ ಉಳಿಯುತ್ತದೆ. VPC ಗೆ VPN ಮೂಲಕ ಸ್ಥಳೀಯ ಮೂಲಕ್ಕೆ ಹಿಂತಿರುಗುವ ರೂಟ್ ಕೂಡ ಬೇಕು, ಅದು ಘೋಷಿತ ಪ್ರಿಫಿಕ್ಸ್ನಿಂದ ಪ್ರತ್ಯೇಕ ವಸ್ತು. ಟನೆಲ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ಒಂದೇ ಪ್ರದೇಶದಲ್ಲಿ ಇಲ್ಲದಿದ್ದಾಗ ದಾಖಲಿತ ಪ್ರಾದೇಶಿಕ ರೂಟಿಂಗ್ ಅಗತ್ಯಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಿ.
ಹಿಂತಿರುಗುವ ದಾರಿಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಕೆಲಸ ಮಾಡುವ ವಿನಂತಿ ದಿಕ್ಕು ಮುರಿದ ಉತ್ತರ ದಿಕ್ಕನ್ನು ಮುಚ್ಚಿಡಬಹುದು. ಎರಡು ದಿಕ್ಕು, ಎರಡು ರೂಟ್, ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ಲಕ್ಷಣದೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ.
ವಿನಂತಿ ಪರೀಕ್ಷಿಸಿ, ನಂತರ ನಿರಾಕರಣೆ ಓದಿ
ಈ VIP ಗಳಿಂದ ICMP ಎಕೋ ಯಾವುದೇ ಉತ್ತರ ಪಡೆಯುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ವಿಫಲವಾದ ಪಿಂಗ್ ಏನನ್ನೂ ಸಾಬೀತು ಮಾಡುವುದಿಲ್ಲ ಮತ್ತು ಯಶಸ್ವಿಯಾದದ್ದು ಬಹಳ ಕಡಿಮೆ. ನಿಜವಾದ ಕ್ಲೈಂಟ್ನಿಂದ ಹೆಸರಿನ ಉತ್ತರ ಮತ್ತು ಆಯ್ಕೆ ಮಾಡಿದ ರೂಟ್ ಪರಿಶೀಲಿಸಿ, ನಂತರ ನಿಮಗೆ ಮುಖ್ಯವಾದ ಸೇವೆಗೆ ಅಧಿಕೃತ HTTPS ವಿನಂತಿ ಮಾಡಿ. ವಿನಂತಿ ಸೇವೆ ತಲುಪಿ ನಿರಾಕರಿಸಲ್ಪಟ್ಟರೆ, ರುಜುವಾತುಗಳು, IAM ಮತ್ತು ಅನ್ವಯವಾಗುವ ಸೇವಾ ಪರಿಧಿ ನೀತಿ ನೋಡಿ.
ಖಾಸಗಿ ರೂಟಿಂಗ್ API ಅಧಿಕಾರ ನೀಡುವುದಿಲ್ಲ ಮತ್ತು ಗುರುತಿಗೆ ಏನು ಮಾಡಲು ಅನುಮತಿ ಎಂಬುದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಸಾಗಣೆ ಯಶಸ್ಸು ಮತ್ತು ಅಧಿಕೃತ ಉತ್ತರ ಪ್ರತ್ಯೇಕ ಫಲಿತಾಂಶಗಳು, ಮತ್ತು ನಿಮಗೆ ಎರಡೂ ಬೇಕು. IPv6 ದಾರಿಯನ್ನೂ ಸ್ಪಷ್ಟವಾಗಿ ಇರಿಸಿ, ಏಕೆಂದರೆ IPv4 ಪ್ರಿಫಿಕ್ಸ್ಗಳನ್ನು ಸಂರಚಿಸುವುದು IPv6 ಬಯಸುವ ಕ್ಲೈಂಟ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.
Google ನ ಆನ್-ಪ್ರಿಮೈಸ್ Private Google Access ಮಾರ್ಗದರ್ಶಿ DNS ರೆಕಾರ್ಡ್ಗಳು ಮತ್ತು ರೂಟಿಂಗ್ ಅಗತ್ಯಗಳನ್ನು ಒಟ್ಟಿಗೆ ಒಳಗೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಮ್ಮ ರಿಜಾಲ್ವರ್ ಮತ್ತು ಘೋಷಣೆ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಫೋರಮ್ ಪೋಸ್ಟ್ನೊಂದಿಗಲ್ಲ, ಅದರೊಂದಿಗೆ ಹೋಲಿಸಿ. ನಂತರ ಅದೇ ವಿನಂತಿಯನ್ನು ಮತ್ತೆ ಚಲಾಯಿಸಿ ಮತ್ತು ಉತ್ತರ ಹಾಗೂ ರೂಟ್ ಅನ್ನು ಅದೇ ಟಿಕೆಟ್ನಲ್ಲಿ ದಾಖಲಿಸಿ.