GCP ನ VM ಗೆ Cloud VPN: NAT IP ಅಲ್ಲ, ಆಂತರಿಕ IP ಬಳಸಿ
ಗೇಟ್‌ವೇ ಎಂಡ್‌ಪಾಯಿಂಟ್, VM ನ ಆಂತರಿಕ ವಿಳಾಸ ಮತ್ತು ಬಾಹ್ಯ ಒಂದಕ್ಕೊಂದು NAT ವಿಳಾಸ ಮೂರು ಬೇರೆ ಬೇರೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ. ನಿಮ್ಮ ಮಾರ್ಗ ಯಾವುದನ್ನು ಬಳಸುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ.
ಸ್ಥಳೀಯ ನೆಟ್‌ವರ್ಕ್ Cloud VPN ಮೂಲಕ VPC ತಲುಪಿದಾಗ, Compute Engine ಸೇವೆಗೆ ಗಮ್ಯಸ್ಥಾನ ಸಾಮಾನ್ಯವಾಗಿ VM ನ ಆಂತರಿಕ ವಿಳಾಸವಾಗಿರುತ್ತದೆ. ಬಾಹ್ಯ IPv4 ವಿಳಾಸವು ಅದೇ ಖಾಸಗಿ ಮಾರ್ಗದಲ್ಲಿ ಬದಲಿಸಬಹುದಾದ ಎರಡನೇ ವಿಳಾಸವಲ್ಲ. ಈ ಕ್ಷೇತ್ರದಲ್ಲಿ ಹೆಚ್ಚಿನ ಗೊಂದಲ ಮೂರು ಕೆಲಸಗಳನ್ನು ಹೊಂದಿರುವ ಮೂರು ವಿಳಾಸಗಳನ್ನು ಪರಸ್ಪರ ಬದಲಾಯಿಸಬಹುದಾದವು ಎಂದು ಪರಿಗಣಿಸುವುದರಿಂದ ಬರುತ್ತದೆ, ಆದ್ದರಿಂದ ಒಂದು ನಿರ್ದಿಷ್ಟ ಪ್ಯಾಕೆಟ್ ಯಾವುದನ್ನು ಬಳಸುತ್ತಿದೆ ಎಂದು ಹೆಸರಿಸುವುದರಿಂದ ಪ್ರಾರಂಭಿಸಿ.
ಮೂರು ವಿಳಾಸಗಳು, ಮೂರು ಕೆಲಸಗಳು
ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ಡೀಬಗ್ ಮಾಡುವ ಮೊದಲು ಮೂರನ್ನೂ ಹೆಸರಿಸಿ, ಏಕೆಂದರೆ ಉತ್ತರವು ನೀವು ಮುಂದೆ ಪರಿಶೀಲಿಸುವ ವಸ್ತುವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ.
| Address | Job |
|---|---|
| Cloud VPN endpoint | where the IPsec peers meet |
| Internal IP | the address your route and firewall must name |
| External IPv4 | the platform's inbound mapping, not a guest address |
ಮೊದಲನೆಯದು ಸುರಂಗಕ್ಕೆ ಸೇರಿದೆ. ಎರಡನೆಯದು ನಿಮ್ಮ ಮಾರ್ಗ ಮತ್ತು ಫೈರ್‌ವಾಲ್ ವಿನ್ಯಾಸಕ್ಕೆ ಸೇರಿದೆ. ಮೂರನೆಯದು ಒಳಬರುವ ಇಂಟರ್ನೆಟ್ ಪ್ರವೇಶಕ್ಕೆ ಸೇರಿದೆ ಮತ್ತು ಅದು ಮ್ಯಾಪ್ ಆಗುತ್ತದೆ, ಜೋಡಣೆಯಾಗುವುದಿಲ್ಲ. ಅವುಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಕೆಲಸ ಮಾಡುವ ವಿನ್ಯಾಸವು ಉಳಿದೆರಡರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.
ಬಾಹ್ಯ ವಿಳಾಸವು ಎರಡನೇ ಇಂಟರ್ಫೇಸ್ ಏಕೆ ಅಲ್ಲ
Compute Engine ನಲ್ಲಿ ಆಂತರಿಕ ಮತ್ತು ಬಾಹ್ಯ ತಲುಪುವಿಕೆ ಹೇಗೆ ಭಿನ್ನವಾಗಿದೆ ಎಂಬುದಕ್ಕೆ ವಿಳಾಸ ಮಾರ್ಗದರ್ಶಿ ಅಧಿಕೃತ ಮೂಲವಾಗಿದೆ. Compute Engine ನ ಬಾಹ್ಯ IPv4 ಇನ್‌ಸ್ಟಾನ್ಸ್‌ನ ಏಕೈಕ ಆಂತರಿಕ NIC ಮೇಲೆ ಒಂದಕ್ಕೊಂದು ಮ್ಯಾಪಿಂಗ್ ಆಗಿದೆ, ಆದ್ದರಿಂದ ಅತಿಥಿಯು ಆ NIC ಮೇಲೆ ಎಂದಿಗೂ ಎರಡನೇ ಇಂಟರ್ಫೇಸ್ ಅಥವಾ ಎರಡನೇ ವಿಳಾಸವನ್ನು ನೋಡುವುದಿಲ್ಲ. VM ಒಳಗಿನಿಂದ ವರದಿ ಮಾಡುವುದು ಇನ್ನೂ ಒಂದು ಪ್ರಾಥಮಿಕ ಆಂತರಿಕ ವಿಳಾಸವೇ.
ಆದ್ದರಿಂದ ಖಾಸಗಿ ಕ್ಲೈಂಟ್ ಸುರಂಗದ ಮೂಲಕ 10.24.1.7 ಕಡೆಗೆ ಮಾರ್ಗ ಮಾಡಿದರೆ, ಮತ್ತು VM ನ ಬಾಹ್ಯ ವಿಳಾಸವನ್ನು ಗುರಿಯಾಗಿಸುವ ಕ್ಲೈಂಟ್ ಬೇರೆ ಮಾರ್ಗಗಳಲ್ಲಿರುತ್ತದೆ. ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕಾಗಿ ಫೈರ್‌ವಾಲ್ ನಿಯಮ ತೆರೆದರೂ ಸುರಂಗದ ಸಂಚಾರವನ್ನು ಹೊತ್ತೊಯ್ಯಬೇಕಾದ VPC ಮಾರ್ಗದಲ್ಲಿ ಏನೂ ಬದಲಾಗುವುದಿಲ್ಲ, ಮತ್ತು ಅತಿಥಿಯಲ್ಲಿನ ಮಾರ್ಗವನ್ನು ಸಂಪಾದಿಸಿದರೂ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಮ್ಯಾಪಿಂಗ್ ಚಲಿಸುವುದಿಲ್ಲ. ನಿಮ್ಮ ಮಾರ್ಗವು ಹೆಸರಿಸುವ ವಿಳಾಸವನ್ನು ಆರಿಸಿ, ನಂತರ ಅದನ್ನು ನಿಯಂತ್ರಿಸುವ ವಸ್ತುಗಳನ್ನಷ್ಟೇ ಪರಿಶೀಲಿಸಿ. ಈ ಶಿಸ್ತು ಈ ದೋಷನಿವಾರಣೆ ಮಾರ್ಗದಿಂದ ಹೆಚ್ಚಿನ ಊಹೆಗಳನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.
gcloud ನೊಂದಿಗೆ ಮಾರ್ಗವನ್ನು ನಡೆಯಿರಿ
ಇನ್‌ಸ್ಟಾನ್ಸ್‌ನಿಂದ ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಎರಡೂ ವಿಳಾಸಗಳನ್ನು ಒಂದೇ ವಸ್ತುವಿನಿಂದ ಓದಿ, ಇದರಿಂದ ನಿಮ್ಮ ದಾಖಲೆ ಯಾವುದನ್ನು ಕುರಿತು ಮಾತನಾಡುತ್ತಿದೆ ಎಂದು ತಿಳಿಯುತ್ತದೆ:
gcloud compute instances describe app-1 --zone=europe-west1-b \
--format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"ನಂತರ ಮಾರ್ಗವು ನಿಜವಾಗಿ ಅವಲಂಬಿಸಿರುವ ರೂಟಿಂಗ್ ಮತ್ತು ಅನುಮತಿಯನ್ನು ದೃಢೀಕರಿಸಿ:
gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1ಸುರಂಗವು ಘೋಷಿಸಿದ ಮತ್ತು ಕಲಿತ ಶ್ರೇಣಿಗಳನ್ನು ಓದಿ, ಕೆಲಸದ ಹೊರೆಯ ಸಬ್‌ನೆಟ್‌ಗಾಗಿ VPC ಮಾರ್ಗ, ಮತ್ತು ಸ್ಥಳೀಯ ಮೂಲವನ್ನು ಅನುಮತಿಸುವ ಫೈರ್‌ವಾಲ್ ನಿಯಮ. ಅತಿಥಿಯ ಮೇಲಿನ ಕೇಳುಗನು ಸಂಬಂಧಿತನಾಗುವ ಮೊದಲು ಈ ಮೂರೂ ಹೊಂದಿಕೆಯಾಗಬೇಕು.
ನಂತರ ಅತಿಥಿಯನ್ನು ಪರಿಶೀಲಿಸಿ: ಸೇವೆಯು ಆಂತರಿಕ ವಿಳಾಸದಲ್ಲಿ ಕೇಳುತ್ತಿದೆಯೇ, ಮತ್ತು ಅದರ ಹಿಂತಿರುಗುವ ಮಾರ್ಗವು ಮತ್ತೆ VPC ಮೂಲಕ ಹೋಗುತ್ತದೆಯೇ? ಕೇವಲ ಸಾರ್ವಜನಿಕ ವಿಳಾಸಕ್ಕೆ ಬದ್ಧವಾದ ಕೇಳುಗನು ಕ್ಲೌಡ್ ಬದಿಯ ಪ್ರತಿ ವಸ್ತುವೂ ಸರಿಯಾಗಿದ್ದರೂ ಈ ಪರೀಕ್ಷೆಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತಾನೆ.
ಸಾರ್ವಜನಿಕ ಪೂರ್ವಪ್ರತ್ಯಯ ಬೇರೆ ಪ್ರಶ್ನೆ
ಮೇಲಿನ ಯಾವುದೂ VPN ಒಳಗೆ ಸಾಗಿಸುವ ಪ್ರತಿ ವಿಳಾಸವೂ RFC1918 ಆಗಿರಬೇಕು ಎಂದು ಅರ್ಥವಲ್ಲ. ದೂರದ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಸಾರ್ವಜನಿಕ ಜಾಗದಿಂದ ಕಾನೂನುಬದ್ಧವಾಗಿ ಸಂಖ್ಯೆ ಮಾಡಬಹುದು, ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ರೂಟಿಂಗ್ ಬೆಂಬಲಿಸಿದರೆ ಮತ್ತು ನಿರ್ವಾಹಕನಿಗೆ ವಿಳಾಸದ ಅಧಿಕಾರ ಇದ್ದರೆ. ಇದು ಸಾಮಾನ್ಯ ವಿನ್ಯಾಸ ಆಯ್ಕೆ.
ಇದು ಸಾಮಾನ್ಯ ಬಾಹ್ಯ NAT ವಿಳಾಸವನ್ನು ಇನ್ನೊಂದು ಆಂತರಿಕ ಸಬ್‌ನೆಟ್ ವಿಳಾಸವೆಂದು ಪರಿಗಣಿಸುವಂತೆ ಅಲ್ಲ. ಒಂದು ನೀವು ಮಾರ್ಗ ಮಾಡುವ ಪೂರ್ವಪ್ರತ್ಯಯ; ಇನ್ನೊಂದು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಒಳಬರುವ ಪ್ರವೇಶಕ್ಕೆ ಅನ್ವಯಿಸುವ ಮ್ಯಾಪಿಂಗ್.
ಬಾಹ್ಯ IPv6 ಮತ್ತು ವಿಶೇಷವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಿದ ವಿಳಾಸ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ತಮ್ಮದೇ ಅರ್ಥಶಾಸ್ತ್ರವಿದೆ. ನಿಮ್ಮ ಯೋಜನೆ ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಅವಲಂಬಿಸಿದ್ದರೆ, IPv4 ಪ್ರಕರಣದಿಂದ ಸಾಮಾನ್ಯೀಕರಿಸುವ ಬದಲು ಆ ವೈಶಿಷ್ಟ್ಯಕ್ಕಾಗಿ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ದಾಖಲೆಯನ್ನು ಓದಿ. IPv4 ಮ್ಯಾಪಿಂಗ್ ಸಾಮಾನ್ಯ ಪ್ರಕರಣ, ಏಕೈಕವಲ್ಲ, ಮತ್ತು ಪ್ರತಿ ಅಪವಾದಕ್ಕೂ ತನ್ನದೇ ನಿಯಮಗಳಿವೆ.
ಅತಿಪಾತವಾಗುವ ಶ್ರೇಣಿಗಳು ಬೇರೆ ಸಮಸ್ಯೆ
ಅತಿಪಾತವಾಗುವ ಖಾಸಗಿ ಶ್ರೇಣಿಗಳು ಜನರು ಸಾರ್ವಜನಿಕ ವಿಳಾಸದ ಕಡೆಗೆ ತಿರುಗುವ ನಿಜವಾದ ಕಾರಣ, ಮತ್ತು ಅದು ತಪ್ಪಾದ ಸಾಧನ. ಗಮ್ಯಸ್ಥಾನವನ್ನು VM ನ NAT ವಿಳಾಸಕ್ಕೆ ಬದಲಿಸುವುದು ಅತಿಪಾತವನ್ನು ಪರಿಹರಿಸುವುದಿಲ್ಲ; ಪ್ಯಾಕೆಟ್ ಯಾವ ವಿಳಾಸಕ್ಕೆ ಎಂದು ಹೇಳಿಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ, ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ವ್ಯಾಖ್ಯಾನಿಸದೆ.
ಅತಿಪಾತವನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಪರಿಹರಿಸಿ: ಮರುಸಂಖ್ಯೆ ಮಾಡಿ, ಬೆಂಬಲಿತ ಅನುವಾದ ವಿನ್ಯಾಸ ಬಳಸಿ, ಅಥವಾ ಪೂರ್ವಪ್ರತ್ಯಯಗಳು ಘರ್ಷಿಸದ ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ಮಾರ್ಗ ಮಾಡಿ. ಇವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಮಾಲೀಕರಿರುವ ವಿನ್ಯಾಸ. NAT ವಿಳಾಸವು ವಿನ್ಯಾಸವಲ್ಲ.
ಎರಡು ಕ್ಷೇತ್ರಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ದಾಖಲಿಸಿ
ಸುರಂಗದ ಸಹಭಾಗಿ ಮತ್ತು ಕೆಲಸದ ಹೊರೆಯ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಎರಡು ಪ್ರತ್ಯೇಕ ರನ್‌ಬುಕ್ ಕ್ಷೇತ್ರಗಳಾಗಿ ದಾಖಲಿಸಿ, ಪ್ರತಿಯೊಂದೂ ಅದನ್ನು ಬೆಂಬಲಿಸುವ ಮಾರ್ಗ ಮತ್ತು ಫೈರ್‌ವಾಲ್ ನಿಯಮದೊಂದಿಗೆ. ಮೇಲೆ ಬರುವ IPsec ಸುರಂಗವು ಕಡೆಗಳು ಒಪ್ಪಿಗೆಯಲ್ಲಿವೆ ಎಂದಷ್ಟೇ ಹೇಳುತ್ತದೆ; ಕೆಲಸದ ಹೊರೆ ಯಾವ ವಿಳಾಸದಲ್ಲಿ ತಲುಪಬಹುದು ಎಂಬುದನ್ನೂ ಅದರ ಖಾಸಗಿ ಮಾರ್ಗ ಪೂರ್ಣವೇ ಎಂಬುದನ್ನೂ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.
ಇನ್ನೊಂದು ಬದಿಯಲ್ಲಿ ನಿಜವಾದ ಕ್ಲೈಂಟ್‌ನೊಂದಿಗೆ ಪರಿಶೀಲಿಸಿ: ಹೆಸರನ್ನು ಬಿಡಿಸಿ, ಅದು ಆಂತರಿಕ ವಿಳಾಸವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ ಎಂದು ದೃಢೀಕರಿಸಿ, ಸಂಪರ್ಕಿಸಿ ಮತ್ತು ಹಿಂತಿರುಗುವ ಸಂಚಾರವನ್ನು ಪರಿಶೀಲಿಸಿ. Compute Engine IP ವಿಳಾಸ ದಾಖಲೆ ಮೇಲೆ ಬಳಸಿದ ಆಂತರಿಕ-ವಿರುದ್ಧ-ಬಾಹ್ಯ ವ್ಯತ್ಯಾಸದ ಉಲ್ಲೇಖವಾಗಿದೆ.