Terraform ਵਿੱਚ GCP Classic VPN: ਟਨਲ ਨੂੰ ਰੂਟ-ਆਧਾਰਿਤ ਬਣਾਓ

Classic VPN ਵਿੱਚ ਲੇਬਲ ਵਿਵਹਾਰ ਤੈਅ ਨਹੀਂ ਕਰਦਾ। ਰੂਟ-ਆਧਾਰਿਤ ਦਾ ਮਤਲਬ ਹੈ 0.0.0.0/0 ਸਥਾਨਕ ਚੋਣਕਰਤਾ, ਮੇਲ ਖਾਂਦੇ ਦੂਰਸਥ ਚੋਣਕਰਤਾ ਅਤੇ ਸਪਸ਼ਟ ਰੂਟ।

ਯੋਜਨਾ ਸਾਫ਼ ਤੌਰ 'ਤੇ ਲਾਗੂ ਹੁੰਦੀ ਹੈ, ਟਨਲ ਉੱਪਰ ਆਉਂਦੀ ਹੈ, ਅਤੇ ਕਨਸੋਲ ਇਸਨੂੰ ਨੀਤੀ-ਆਧਾਰਿਤ ਕਹਿੰਦਾ ਹੈ। ਟ੍ਰੈਫਿਕ ਫਿਰ ਵੀ ਨਹੀਂ ਲੰਘਦਾ, ਅਤੇ 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 ਸੰਦਰਭ ਵਿੱਚ।

ਸੰਬੰਧਿਤ ਲੇਖ