GCP Classic VPN у Terraform-у: учините тунел рутираним

У 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 подмреже које планирате да користите. Ако било која страна сузи, фаза 2 не успева иако фаза 1 успева. То је најчешћи облик конфигурације која у конзоли изгледа исправно и не носи саобраћај.

Иштампајте селекторе обе стране један поред другог при прегледу промене.

Поделите статичку адресу на две примене

Прављење резервисане адресе и тунела који се на њу позива у једној примени познат је извор нестабилности, јер адреса мора да постоји пре него што правило прослеђивања може да је користи. Прво примените само ресурс адресе, затим додајте портал, правила прослеђивања и тунел и примените поново. Terraform чита постојећу адресу из стања при другом покретању и поново је користи. Ако то прескочите, тунел може добити нову јавну адресу при свакој примени, што сваки пут квари конфигурацију партнера.

Две примене сада су јефтиније од промене партнера при сваком издању.

Проверите преговарање, не ознаку

После примене проверите три одвојене чињенице: тунел пријављује успостављену везу, рута постоји са предвиђеним следећим скоком, а партнер пријављује да су и фаза 1 и фаза 2 подигнуте.

Тунел је подигнут док је фаза 2 доле, што значи да се две стране не слажу око селектора:

  • Једна страна наводи подмрежу коју друга не наводи.
  • Једна страна користи агрегат који је друга сузила.
  • Рута постоји, али показује на други тунел.

Classic VPN је један тунел са нижим SLA од HA VPN, а HA VPN користи два интерфејса, два тунела и BGP са различитим типовима ресурса. Копирање класичног примера у HA конфигурацију и очекивање да ће се поља селектора понашати исто је посебна грешка коју вреди избећи. Сама поља тунела су документована у референци за google_compute_vpn_tunnel.

Повезани чланци