ನಿಮ್ಮ GCP VM OpenVPN IPv6 ಪೂಲ್‌ಗೆ ಏಕೆ ಉತ್ತರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ

ನಿಮ್ಮ IPv6 VPN ಕ್ಲೈಂಟ್ ಕೆಲಸದ ಹೊರೆಗೆ ತಲುಪುತ್ತದೆ, ಕೆಲಸದ ಹೊರೆ ಸುರಂಗದೊಳಗೆ ಉತ್ತರಿಸುತ್ತದೆ, ಆದರೆ ಉತ್ತರ ಎಂದಿಗೂ ಬರುತ್ತಿಲ್ಲ. ಮೊದಲ ಪ್ರವೃತ್ತಿ ಫೈರ್‌ವಾಲ್ ಅಥವಾ ಸುರಂಗವನ್ನು ದೂಷಿಸುವುದು, ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಎರಡೂ ದೋಷಿಗಳಲ್ಲ. OpenVPN ನೀಡುವ ವಿಳಾಸವು ಸುರಂಗದೊಳಗೆ ಮಾತ್ರ ಇರುವ ಆಂತರಿಕ ಜಾಲವಾಗಿದೆ; fd42:90::/64 ನಿರ್ದಿಷ್ಟ VMನ ಹಿಂದೆ ಇರಬೇಕೆಂದು ನೀವು ಹೇಳುವವರೆಗೆ Google Cloud ಗೆ ಗೊತ್ತಿಲ್ಲ.

ಈ ಸತ್ಯವನ್ನು ಎರಡು ಪ್ರತ್ಯೇಕ ವ್ಯವಸ್ಥೆಗಳು ಕಲಿಯಬೇಕು, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ OpenVPN. VPC ಯಾವುದನ್ನಾದರೂ ಹಿಂತಿರುಗಿ ಕಳುಹಿಸುವ ಮೊದಲು ಮಾರ್ಗದ ಅಗತ್ಯವಿದೆ, ಮತ್ತು VM ಗೆ ಬರುವುದನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ಅನುಮತಿ ನೀಡಬೇಕು. ಯಾವುದೇ ಅರ್ಧದಲ್ಲಿ ತಪ್ಪಾದರೆ ಲಕ್ಷಣ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತದೆ.

ಪೂಲ್ ಆಂತರಿಕ ಜಾಲವೇ ಹೊರತು ಸಬ್‌ನೆಟ್ ಅಲ್ಲ

OpenVPN ನೀವು ಆಯ್ಕೆ ಮಾಡುವ ಶ್ರೇಣಿಯಿಂದ IPv6 ವಿಳಾಸಗಳನ್ನು ನೀಡಬಹುದು, ಮತ್ತು ಆ ಶ್ರೇಣಿ ಸುರಂಗದ ಎರಡು ತುದಿಗಳು ಒಪ್ಪುವ ಕಲ್ಪನೆ. ಅದು Google Cloud ಸಬ್‌ನೆಟ್ ಅಲ್ಲ, VPC ಸಬ್‌ನೆಟ್ ಪಟ್ಟಿಯಲ್ಲಿ ಕಾಣಿಸುವುದಿಲ್ಲ, ಮತ್ತು VM ನ ಜಾಲ ಸಂಪರ್ಕ ಸಾಧನವು ಆ ವಿಳಾಸಗಳನ್ನು ಪಡೆಯುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ಕ್ಲೈಂಟ್‌ಗೆ ಉತ್ತರಿಸುವ ಕೆಲಸದ ಹೊರೆ ಜಾಲವು ಮಾರ್ಗರಹಿತ ಎಂದು ಪರಿಗಣಿಸುವ ವಿಳಾಸಕ್ಕೆ ಪ್ಯಾಕೆಟ್ ಕಳುಹಿಸುತ್ತದೆ.

ಪೂಲ್ ಅನ್ನು VPC ಈಗಾಗಲೇ ಬಳಸುವ ಪ್ರತಿ ಶ್ರೇಣಿಯಿಂದ ಹೊರಗಿಡಿ. ನಿಮ್ಮ ಇತರ ಸುರಂಗಗಳ ಹಿಂದಿನ ಶ್ರೇಣಿಗಳಿಂದಲೂ ಅದನ್ನು ಹೊರಗಿಡಿ. ಅತಿಕ್ರಮಣವು ಸ್ವಚ್ಛ ಮಾರ್ಗನಿರ್ದೇಶನ ವೈಫಲ್ಯವನ್ನು ಹೊರೆಯಲ್ಲಿ ಮಾತ್ರ ಕಾಣುವ ಮಧ್ಯಂತರ ವೈಫಲ್ಯವನ್ನಾಗಿ ಮಾಡುತ್ತದೆ.

fd42:90::/64 ನಂತಹ ಅನನ್ಯ ಸ್ಥಳೀಯ ವಿಳಾಸೀಕರಣವು ಈ ಆಂತರಿಕ ಜಾಲಕ್ಕೆ ಸೂಕ್ತ ಆಯ್ಕೆಯಾಗಿದೆ. ಪೂರ್ವಪ್ರತ್ಯಯವು ವಿನ್ಯಾಸವು ಸ್ವಭಾವತಃ ಖಾಸಗಿಯಾಗಿದೆ ಎಂದು ನೆನಪಿಸುತ್ತದೆ. ULA ಪೂಲ್‌ನಲ್ಲಿ ಯಾವುದೂ ಅದನ್ನು ಸಾರ್ವಜನಿಕ ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿ ಕಾನೂನುಬದ್ಧ ಮೂಲವನ್ನಾಗಿ ಮಾಡುವುದಿಲ್ಲ.

VPC ಗೆ ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ಮುಂದಿನ ಹಾಪ್ ನೀಡಿ

ಉತ್ತರಕ್ಕೆ ಗಮ್ಯಸ್ಥಾನ ಪೂಲ್ ಆಗಿರುವ ಮತ್ತು ಮುಂದಿನ ಹಾಪ್ VPN VM ಆಗಿರುವ VPC ಮಾರ್ಗ ಬೇಕು. ಪ್ರಸ್ತುತ ಸ್ಥಿರ-ಮಾರ್ಗ ದಸ್ತಾವೇಜು IPv6 ಗಮ್ಯಸ್ಥಾನ ಶ್ರೇಣಿಗಳನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಯಾವ ಮುಂದಿನ ಹಾಪ್ ಪ್ರಕಾರಗಳು ಅರ್ಹವೆಂದು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಹಳೆಯ IPv4 ಉದಾಹರಣೆಯನ್ನು ನಕಲಿಸುವ ಬದಲು ನಿಮ್ಮ ಟೋಪಾಲಜಿಗೆ ಬೆಂಬಲಿತ ರೂಪವನ್ನು ಪರಿಶೀಲಿಸಿ.

ಮುಂದಿನ ಹಾಪ್ ವಿಳಾಸವು ಇನ್‌ಸ್ಟೆನ್ಸ್ ನ ಕ್ಲೌಡ್ ಇಂಟರ್ಫೇಸ್‌ಗೆ ನಿಜವಾಗಿ ನಿಗದಿಪಡಿಸಲಾದ ವಿಳಾಸವಾಗಿರಬೇಕು. VM ನ ಆಂತರಿಕ ಸುರಂಗ ವಿಳಾಸವು ಆ ವಿಳಾಸವಲ್ಲ. ಹಾಗಿದ್ದರೂ ಅದನ್ನು ಬಳಸಿದರೆ ಸ್ವಚ್ಛವಾಗಿ ಸ್ಥಾಪನೆಯಾಗುವ ಮತ್ತು ಎಂದಿಗೂ ಪ್ಯಾಕೆಟ್‌ಗೆ ಹೊಂದಿಕೆಯಾಗದ ಮಾರ್ಗ ಉಂಟಾಗುತ್ತದೆ. ಮಾರ್ಗ ಬರೆಯುವ ಮೊದಲು ಇಂಟರ್ಫೇಸ್ ಪಟ್ಟಿಯನ್ನು ಓದಿ.

ಮಾರ್ಗದ ಆದ್ಯತೆ ನಮೂದಿನಷ್ಟೇ ಮುಖ್ಯ. ಸಬ್‌ನೆಟ್ ಮಾರ್ಗಗಳು ನೀವು ಸೇರಿಸುವ ಕಸ್ಟಮ್ ಮಾರ್ಗಗಳಿಗಿಂತ ಹೆಚ್ಚು ನಿರ್ದಿಷ್ಟವಾಗಿವೆ, ಆದ್ದರಿಂದ ಇರುವ ಸಬ್‌ನೆಟ್ ಶ್ರೇಣಿಯಿಂದ ಕತ್ತರಿಸಿದ ಪೂಲ್ ಕಸ್ಟಮ್ ಮಾರ್ಗವನ್ನು ಹೇಗೆ ಬರೆದರೂ ಸಬ್‌ನೆಟ್ ಮಾರ್ಗಕ್ಕೆ ಸೋಲುತ್ತದೆ. ಪ್ರತ್ಯೇಕ ಪೂಲ್ ಆಯ್ಕೆ ಮಾಡಿ, ನಂತರ ಮಾರ್ಗವು ಇನ್‌ಸ್ಟೆನ್ಸ್ ಅನ್ನು ಮುಂದಿನ ಹಾಪ್ ಮತ್ತು ಸರಿಯಾದ ಗಮ್ಯಸ್ಥಾನ ಪೂರ್ವಪ್ರತ್ಯಯವಾಗಿ ತೋರಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ:

gcloud compute routes create vpn6-return \
  --network=vpn-vpc \
  --destination-range=fd42:90::/64 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b

ಫಾರ್ವರ್ಡಿಂಗ್ ಎರಡು ಬಾರಿ ಸಕ್ರಿಯಗೊಳಿಸಬೇಕು

ಮಾರ್ಗವು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಇನ್‌ಸ್ಟೆನ್ಸ್ ಗೆ ತಲುಪಿಸುತ್ತದೆ. ಅದು ತನಗೆ ಉದ್ದೇಶಿಸದ ಯಾವುದನ್ನಾದರೂ ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ಇನ್‌ಸ್ಟೆನ್ಸ್ ಅನ್ನು ಸಿದ್ಧಗೊಳಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಆ ಅನುಮತಿ ಎರಡು ಮಟ್ಟಗಳಲ್ಲಿ ಇದೆ.

ಕ್ಲೌಡ್ ಬದಿಗೆ ಇನ್‌ಸ್ಟೆನ್ಸ್ ನ ಫಾರ್ವರ್ಡಿಂಗ್ ಸಾಮರ್ಥ್ಯ ಸಕ್ರಿಯವಾಗಿರಬೇಕು; ಇದು VM ತನ್ನದಲ್ಲದ ವಿಳಾಸಗಳಿಗೆ ಸಂಚಾರವನ್ನು ಸ್ವೀಕರಿಸಿ ಮುಂದೆ ರವಾನಿಸಲು ಅನುವು ಮಾಡುವ ಸೆಟ್ಟಿಂಗ್. ಅತಿಥಿ ಬದಿಗೆ ತನ್ನದೇ IPv6 ಫಾರ್ವರ್ಡಿಂಗ್ ಬೇಕು, ಏಕೆಂದರೆ ಪ್ಯಾಕೆಟ್ ಬಂದ ನಂತರ ಕೆರ್ನೆಲ್ ಪ್ರತ್ಯೇಕ ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಒಂದೇ ಉತ್ತರ ಸುರಂಗ ದಾಟುವ ಮೊದಲು ಎರಡೂ ಆನ್ ಆಗಿರಬೇಕು.

sysctl -w net.ipv6.conf.all.forwarding=1

ನಂತರ ಫೈರ್‌ವಾಲ್ ನಿಯಮಗಳು ಆಂತರಿಕ ಮೂಲ ಶ್ರೇಣಿಯನ್ನು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಅನುಮತಿಸಬೇಕು. Google Cloud ಡಿಕ್ಯಾಪ್ಸುಲೇಟೆಡ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ VPC ಸಬ್‌ನೆಟ್ ಅನ್ನು ಮಾತ್ರ ಒಳಗೊಳ್ಳುವ ನಿಯಮವು ಸುರಂಗ ಈಗಾಗಲೇ ಯಶಸ್ವಿಯಾದ ನಂತರ ಪೂಲ್ ಸಂಚಾರವನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ. ಪೂಲ್ ಅನ್ನು ಒಳಬರುವ ನಿಯಮದಲ್ಲಿ ಮೂಲ ಶ್ರೇಣಿಯಾಗಿ ಸೇರಿಸಿ, ಮತ್ತು ಯಾವುದೇ ಕಸ್ಟಮ್ ಹೊರಹೋಗುವ ನೀತಿ ಉತ್ತರವನ್ನು ತಡೆಯುತ್ತಿಲ್ಲ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಸೂಚ್ಯ ಅನುಮತಿ ನಿಯಮವು ಡೀಫಾಲ್ಟ್ ಪ್ರಕರಣವನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ, ಕೈಬರಹದ ಹೊರಹೋಗುವ ನಿಯಮವು ಒಳಗೊಳ್ಳುವುದಿಲ್ಲ.

ಯಾರು ಯಾವುದನ್ನು ಹೊಂದಿದ್ದಾರೆ ಎಂದು OpenVPN ಗೆ ಹೇಳಿ

ಆ ಕ್ಲೈಂಟ್ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಹೊಂದಿದೆ ಎಂದು ತಿಳಿದಾಗ OpenVPN ಕ್ಲೈಂಟ್‌ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ. ಪೂಲ್‌ನಿಂದ ಬರುವ ಕ್ಲೈಂಟ್ ವಿಳಾಸಗಳನ್ನು ಪೂಲ್ ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವ ಸರ್ವರ್ ಸೂಚನೆ ನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ಕ್ಲೈಂಟ್‌ನ ಹಿಂದಿನ ಸಬ್‌ನೆಟ್ ಬೇರೆ ಜೋಡಣೆಯಾಗಿದ್ದು ಆ ಕ್ಲೈಂಟ್‌ಗೆ ಸ್ಪಷ್ಟ ಮಾಲೀಕತ್ವ ನಮೂದು ಬೇಕು.

ಎರಡನ್ನೂ ಗೊಂದಲಿಸಿದರೆ ಸರ್ವರ್‌ಗೆ ಪಿಂಗ್ ಕೆಲಸ ಮಾಡುವ ಮತ್ತು ಅದರ ಹಿಂದೆ ಏನೂ ಕೆಲಸ ಮಾಡದ ಸುರಂಗ ಉಂಟಾಗುತ್ತದೆ. ನೀವು ಯಾವ ಪ್ರಕರಣವನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದೀರಿ ಎಂದು ನಿರ್ಧರಿಸಿ, ನಂತರ ಎರಡನೇ push ಸಾಲು ಸೇರಿಸಿ ನಿರೀಕ್ಷಿಸುವ ಬದಲು ಹೊಂದಿಕೆಯಾಗುವ ನಮೂದನ್ನು ಬರೆಯಿರಿ.

ಇಂಟರ್ನೆಟ್ ಹೊರಹೋಗುವಿಕೆಯನ್ನು ಈ ವಿನ್ಯಾಸದಿಂದ ಹೊರಗಿಡಿ

ಖಾಸಗಿ ಪ್ರವೇಶ ಮತ್ತು ಇಂಟರ್ನೆಟ್ ಪ್ರವೇಶ ಪ್ರತ್ಯೇಕ ಯೋಜನೆಗಳು. ಮಾರ್ಗನಿರ್ದೇಶನ ಮತ್ತು ಫಾರ್ವರ್ಡಿಂಗ್ ಒಪ್ಪಿದ ನಂತರ ULA ಪೂಲ್ ಸುರಂಗದ ಮೂಲಕ VPC ಕೆಲಸದ ಹೊರೆಗಳನ್ನು ತಲುಪಬಲ್ಲದು, ಮತ್ತು ಅದೇ ಪೂಲ್‌ಗೆ VPC ಮೂಲಕ ಸಾರ್ವಜನಿಕ ಇಂಟರ್ನೆಟ್‌ಗೆ ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ, ಏಕೆಂದರೆ ಕ್ಲೌಡ್ ಗೇಟ್‌ವೇ ಅನಿಯಂತ್ರಿತ ಸುರಂಗ ಮೂಲವನ್ನು ತನ್ನದಾಗಿ ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ.

ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಇಂಟರ್ನೆಟ್ ಹೊರಹೋಗುವಿಕೆಯೂ ಬೇಕಾದರೆ, ಅದಕ್ಕೆ ಬೆಂಬಲಿತ ವಿಳಾಸೀಕರಣ ಮತ್ತು ಮಾರ್ಗನಿರ್ದೇಶನ ವಿನ್ಯಾಸವನ್ನು ಯೋಜಿಸಿ, ಅದನ್ನು ಖಾಸಗಿ ಪೂಲ್‌ನಿಂದ ಸ್ವತಂತ್ರವಾಗಿ ಇರಿಸಿ ಮತ್ತು ಎರಡು ಮಾರ್ಗಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ. ಒಂದು ಕೆಲಸ ಮಾಡುವ ಮಾರ್ಗವು ಇನ್ನೊಂದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಎರಡನ್ನೂ ಬೆರೆಸುವ ವಿನ್ಯಾಸವು ಮುರಿದ ಸುರಂಗದಂತೆ ಕಾಣುವ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ.