Terraform ನಲ್ಲಿ GCP Classic VPN: ಟನೆಲ್ ಅನ್ನು ಮಾರ್ಗ ಆಧಾರಿತ ಮಾಡಿ

ಯೋಜನೆ ಸ್ವಚ್ಛವಾಗಿ ಅನ್ವಯವಾಗುತ್ತದೆ, ಟನೆಲ್ ಮೇಲೆ ಬರುತ್ತದೆ, ಮತ್ತು ಕನ್ಸೋಲ್ ಅದನ್ನು ನೀತಿ ಆಧಾರಿತ ಎಂದು ಕರೆಯುತ್ತದೆ. ಸಂಚಾರ ಇನ್ನೂ ಹಾದುಹೋಗುವುದಿಲ್ಲ, ಮತ್ತು Terraform ಸಂಪನ್ಮೂಲದಲ್ಲಿ ಮಾರ್ಗ ಆಧಾರಿತ ಟಾಗಲ್ ಹುಡುಕುವುದು ಎಲ್ಲಿಗೂ ತಲುಪುವುದಿಲ್ಲ ಏಕೆಂದರೆ ಅಂತಹ ಕ್ಷೇತ್ರವಿಲ್ಲ. Classic VPN ನಲ್ಲಿ ಮಾರ್ಗ ಆಧಾರಿತ ವರ್ತನೆ ನೀವು ಆಯ್ಕೆ ಮಾಡುವ ಮೋಡ್ ಅಲ್ಲ. ಸ್ಥಳೀಯ ಸಂಚಾರ ಸೆಲೆಕ್ಟರ್ 0.0.0.0/0 ಆಗಿದ್ದಾಗ, ದೂರದ ಸೆಲೆಕ್ಟರ್‌ಗಳು ನಿಜವಾಗಿ ಬಯಸುವ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿದಾಗ ಮತ್ತು ಮಾರ್ಗವು ಟನೆಲ್‌ಗೆ ತೋರಿಸಿದಾಗ ಇದು ಸಿಗುತ್ತದೆ. ಮೂರು ವಿಷಯಗಳು, ಮತ್ತು ಲೇಬಲ್ ಅವನ್ನು ಅನುಸರಿಸುತ್ತದೆ.

ಪುರಾಣ: ಟನೆಲ್ ಮೋಡ್ ಕ್ಷೇತ್ರ

ಕನ್ಸೋಲ್ ಲೇಬಲ್ API ಸೆಲೆಕ್ಟರ್‌ಗಳಲ್ಲಿ ಏನನ್ನು ನೋಡುತ್ತದೆ ಎಂಬುದನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತದೆ. ಸಂಪನ್ಮೂಲದಲ್ಲಿ ಯಾವುದೂ ಮಾರ್ಗ ಆಧಾರಿತ ಎಂದು ಹೇಳುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಸರಿ ಮೌಲ್ಯಕ್ಕೆ ಹೊಂದಿಸಲು ಏನೂ ಇಲ್ಲ.

ಆ ಕ್ಷೇತ್ರವನ್ನು ಹುಡುಕುವುದು ಸಮಸ್ಯೆಯ ಮೊದಲ ಗಂಟೆಯನ್ನು ತಿನ್ನುತ್ತದೆ, ಆದರೆ ಸೆಲೆಕ್ಟರ್ ಮೌಲ್ಯಗಳನ್ನು ಓದಲು ಕೊನೆಯ ಐದು ನಿಮಿಷ ಬೇಕು.

ಇಲ್ಲಿ ಮಾರ್ಗ ಆಧಾರಿತ ಎಂದರೆ ಏನು

Google Classic VPN ನ ಮಾರ್ಗ ಆಧಾರಿತ ಟನೆಲ್‌ಗಳನ್ನು ನೀತಿ ಆಧಾರಿತ ಟನೆಲ್‌ಗಳೆಂದು ದಾಖಲಿಸುತ್ತದೆ, ಅವುಗಳ ಸ್ಥಳೀಯ ಸೆಲೆಕ್ಟರ್ 0.0.0.0/0 ಆಗಿರುತ್ತದೆ. ಕೇವಲ ದೂರದ ಶ್ರೇಣಿಗಳಿಗೆ ಹೆಸರು ನೀಡಲಾಗುತ್ತದೆ, ಮತ್ತು ಸ್ಥಳೀಯ ಬದಿಯನ್ನು ಯಾವುದೇ ವಿಳಾಸವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ ನಿಮ್ಮ ಸಂರಚನೆಯಲ್ಲಿ ಗುರುತು ಮೋಡ್ ಅಲ್ಲ, ಮೌಲ್ಯ. ಎರಡೂ ಸೆಲೆಕ್ಟರ್‌ಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಬರೆಯಿರಿ ಮತ್ತು ಯೋಜನೆಯ ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ಓದಿ:

local_traffic_selector  = ["0.0.0.0/0"]
remote_traffic_selector = ["10.20.0.0/16"]

ಆ ತುಣುಕಿನಲ್ಲಿ ಪೀರ್ ಪ್ರಿಫಿಕ್ಸ್ ಉದಾಹರಣೆಯಷ್ಟೇ; ಆಕಾರವೇ ಮುಖ್ಯ ಭಾಗ.

ಮಾರ್ಗವು ಪ್ರತ್ಯೇಕ ವಸ್ತು

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

resource "google_compute_route" "office" {
  name                = "office-via-vpn"
  dest_range          = "10.20.0.0/16"
  network             = google_compute_network.vpc.name
  next_hop_vpn_tunnel = google_compute_vpn_tunnel.to_office.id
  priority            = 1000
}

ಟನೆಲ್ ಇರುವ ಅದೇ ಮಾಡ್ಯೂಲ್‌ನಲ್ಲಿ ಮಾರ್ಗವನ್ನು ರಚಿಸಿ, ಇದರಿಂದ ಎರಡೂ ಪರಿಶೀಲನೆಯಲ್ಲಿ ಬೇರೆಯಾಗದಂತೆ.

ಪೀರ್‌ನಲ್ಲಿ ಸೆಲೆಕ್ಟರ್‌ಗಳನ್ನು ಪ್ರತಿಬಿಂಬಿಸಿ

ದೂರದ ಸಾಧನವನ್ನು ಕನ್ನಡಿ ಚಿತ್ರದೊಂದಿಗೆ ಸಂರಚಿಸಬೇಕು: ಅದರ ಸ್ಥಳೀಯ ಶ್ರೇಣಿ ನಿಮ್ಮ ದೂರದ ಸೆಲೆಕ್ಟರ್, ಮತ್ತು ಅದರ ದೂರದ ಶ್ರೇಣಿ ನೀವು ಬಳಸಲು ನಿರೀಕ್ಷಿಸುವ GCP ಉಪಜಾಲಗಳನ್ನು ಆವರಿಸಬೇಕು. ಯಾವುದೇ ಬದಿ ಕಿರಿದಾದರೆ, ಹಂತ 1 ಯಶಸ್ವಿಯಾದರೂ ಹಂತ 2 ವಿಫಲವಾಗುತ್ತದೆ. ಕನ್ಸೋಲ್‌ನಲ್ಲಿ ಸರಿಯಾಗಿ ಕಾಣುತ್ತದೆ ಆದರೆ ಯಾವುದೇ ಸಂಚಾರವನ್ನು ಸಾಗಿಸದ ಸಂರಚನೆಯ ಸಾಮಾನ್ಯ ರೂಪ ಇದು.

ಬದಲಾವಣೆ ಪರಿಶೀಲನೆಯ ಸಮಯದಲ್ಲಿ ಎರಡೂ ಬದಿಗಳ ಸೆಲೆಕ್ಟರ್‌ಗಳನ್ನು ಅಕ್ಕಪಕ್ಕದಲ್ಲಿ ಮುದ್ರಿಸಿ.

ಸ್ಥಿರ ವಿಳಾಸವನ್ನು ಎರಡು ಅನ್ವಯಗಳಾಗಿ ವಿಭಜಿಸಿ

ಮೀಸಲಾದ ವಿಳಾಸ ಮತ್ತು ಅದನ್ನು ಉಲ್ಲೇಖಿಸುವ ಟನೆಲ್ ಅನ್ನು ಒಂದೇ ಅನ್ವಯದಲ್ಲಿ ರಚಿಸುವುದು ಅಸ್ಥಿರತೆಯ ತಿಳಿದ ಮೂಲವಾಗಿದೆ, ಏಕೆಂದರೆ ಮುಂದುವರಿಕೆ ನಿಯಮ ಅದನ್ನು ಬಳಸುವ ಮೊದಲು ವಿಳಾಸ ಇರಬೇಕು. ಮೊದಲು ವಿಳಾಸ ಸಂಪನ್ಮೂಲವನ್ನು ಮಾತ್ರ ಅನ್ವಯಿಸಿ, ನಂತರ ಗೇಟ್‌ವೇ, ಮುಂದುವರಿಕೆ ನಿಯಮಗಳು ಮತ್ತು ಟನೆಲ್ ಸೇರಿಸಿ ಮತ್ತೆ ಅನ್ವಯಿಸಿ. Terraform ಎರಡನೇ ರನ್‌ನಲ್ಲಿ ಸ್ಥಿತಿಯಿಂದ ಇರುವ ವಿಳಾಸವನ್ನು ಓದಿ ಮರುಬಳಕೆ ಮಾಡುತ್ತದೆ. ಇದನ್ನು ಬಿಟ್ಟರೆ, ಪ್ರತಿ ಅನ್ವಯದಲ್ಲಿ ಟನೆಲ್‌ಗೆ ಹೊಸ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಸಿಗಬಹುದು, ಇದು ಪ್ರತಿ ಬಾರಿ ಪೀರ್ ಸಂರಚನೆಯನ್ನು ಮುರಿಯುತ್ತದೆ.

ಈಗ ಎರಡು ಅನ್ವಯಗಳು ಪ್ರತಿ ಬಿಡುಗಡೆಯಲ್ಲಿ ಪೀರ್ ಬದಲಾವಣೆಗಿಂತ ಅಗ್ಗ.

ಲೇಬಲ್ ಅಲ್ಲ, ಮಾತುಕತೆಯನ್ನು ಪರಿಶೀಲಿಸಿ

ಅನ್ವಯಿಸಿದ ನಂತರ ಮೂರು ಪ್ರತ್ಯೇಕ ಸತ್ಯಗಳನ್ನು ಪರಿಶೀಲಿಸಿ: ಟನೆಲ್ ಸಂಪರ್ಕ ಸ್ಥಾಪಿತ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ, ಮಾರ್ಗ ಉದ್ದೇಶಿತ ಮುಂದಿನ ಹಾಪ್‌ನೊಂದಿಗೆ ಇದೆ, ಮತ್ತು ಪೀರ್ ಹಂತ 1 ಮತ್ತು ಹಂತ 2 ಎರಡೂ ಮೇಲಿದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ.

ಟನೆಲ್ ಮೇಲಿದ್ದು ಹಂತ 2 ಕೆಳಗಿದ್ದರೆ ಎರಡೂ ಬದಿಗಳು ಸೆಲೆಕ್ಟರ್‌ಗಳ ಬಗ್ಗೆ ಒಪ್ಪುವುದಿಲ್ಲ ಎಂದರ್ಥ:

• ಒಂದು ಬದಿ ಇನ್ನೊಂದು ಪಟ್ಟಿ ಮಾಡದ ಉಪಜಾಲವನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ.
• ಒಂದು ಬದಿ ಇನ್ನೊಂದು ಕಿರಿದು ಮಾಡಿದ ಸಮುಚ್ಚಯವನ್ನು ಬಳಸುತ್ತದೆ.
• ಮಾರ್ಗ ಇದೆ ಆದರೆ ಬೇರೆ ಟನೆಲ್‌ಗೆ ತೋರಿಸುತ್ತದೆ.

Classic VPN HA VPN ಗಿಂತ ಕಡಿಮೆ SLA ಹೊಂದಿರುವ ಒಂದೇ ಟನೆಲ್, ಮತ್ತು HA VPN ಎರಡು ಇಂಟರ್ಫೇಸ್, ಎರಡು ಟನೆಲ್ ಮತ್ತು ವಿಭಿನ್ನ ಸಂಪನ್ಮೂಲ ಪ್ರಕಾರಗಳ BGP ಬಳಸುತ್ತದೆ. ಕ್ಲಾಸಿಕ್ ಉದಾಹರಣೆಯನ್ನು HA ಸಂರಚನೆಗೆ ನಕಲಿಸಿ ಸೆಲೆಕ್ಟರ್ ಕ್ಷೇತ್ರಗಳು ಅದೇ ರೀತಿ ವರ್ತಿಸುತ್ತವೆ ಎಂದು ನಿರೀಕ್ಷಿಸುವುದು ತಪ್ಪಿಸಬೇಕಾದ ಪ್ರತ್ಯೇಕ ತಪ್ಪು. ಟನೆಲ್ ಕ್ಷೇತ್ರಗಳು ಸ್ವತಃ google_compute_vpn_tunnel ಉಲ್ಲೇಖದಲ್ಲಿ.