Тунелът работи, виртуална машина достига до локалния сървър, а услугата Cloud Run изтича по време на същия хост. Това е нормалната отправна точка за тази задача и тунелът рядко е причината. Ревизията на Cloud Run по подразбиране не се намира във вашата VPC, а щом се намери, тя използва собствени адреси на източника, а не подмрежата на виртуалната машина, която вече сте маршрутизирали. Runbook-ът по-долу свързва услугата, маршрутизира действителния ѝ диапазон на източника и след това доказва пътя от ревизията, обслужила заявката. Изпълнете го в този ред, защото пропускането на първата стъпка е причината толкова много такива случаи да завършват с промяна във VPN, която не поправя нищо.

Свържете ревизията, преди да отстранявате грешки в тунела

Cloud Run поддържа Direct VPC изход, което поставя трафика на услугата в подмрежа във вашата VPC без конектор Serverless VPC Access. За съществуваща услуга актуализацията изглежда така:

gcloud run services update SERVICE \
  --region=REGION --network=NETWORK --subnet=SUBNET \
  --vpc-egress=private-ranges-only

Заменете заместителите, прегледайте какво прави внедряването с живия трафик и изберете подмрежа в региона на услугата с достатъчен капацитет за адреси и правилните мрежови разрешения.

Изберете режима на изход, който отговаря на дестинацията

private-ranges-only изпраща дестинациите, които класифицира като частни, през VPC. Това не означава „всичко, което е достъпно през VPN“, и тази разлика се появява, когато локалната услуга е в диапазон, който настройката не класифицира по този начин. Ако дестинацията не е покрита, all-traffic е другият документиран режим и изпраща всичко през VPC, включително публичните зависимости на услугата. Изберете съзнателно и запишете последствието в записа за промяната.

Услуга, която вече използва конектор, изисква миграция, а не превключване, затова я планирайте, вместо да конфигурирате и двете.

Маршрутизирайте източника на Cloud Run, а не източник на виртуална машина

Direct VPC изходът разпределя временни адреси от избраната подмрежа и локалната страна трябва да връща трафик към този диапазон. Обратен маршрут или разрешение на защитната стена, написани за друга подмрежа на виртуална машина, ще изглеждат правилни на диаграмата и ще се провалят на практика. Вземете CIDR на подмрежата от VPC, а не от паметта, след което потвърдете, че crypto ACL или таблицата за маршрутизация на отдалеченото устройство го включва.

При динамично маршрутизиране проверете какво действително обявява Cloud Router и какво импортира VPC, включително всяка политика за персонализирано обявяване. Маршрут, който съществува в конзолата, но не е избран за тази дестинация, е същото като липса на маршрут.

Три условия, които трябва да са изпълнени едновременно

Работещият път изисква всичко изброено, а всяко от тях се проваля по свой начин:

  • Маршрут във VPC към локалния префикс през предвидената връзка Cloud VPN.
  • Обратен маршрут на локалната страна за подмрежата на Cloud Run.
  • Обхват на защита на защитната стена и IPsec, позволяващ източника, дестинацията и порта.

Липсващият маршрут обикновено изглежда като изчакване без доказателства от отдалечената страна. Проблем с обратния маршрут изглежда като пристигаща заявка и изчезващ отговор. Проблем със защитната стена или селектора може да изглежда като отказ или като тихо отхвърляне, в зависимост от устройството. Изясняването кое от трите имате значително стеснява следващата команда.

Не добавяйте един временен адрес на Cloud Run в списъка с разрешени. Използвайте диапазона на подмрежата и схема за оторизация, която подхожда на приложението.

Тествайте ревизията, обслужила заявката

Прегледайте внедрените мрежови настройки и разпределението на трафика, преди да тествате, защото актуализация може да създаде нова ревизия, докато заявките още достигат до по-стара. След това изпълнете същата операция, която изпълнява заявката на потребителя, от тази ревизия. Ако дестинацията е частно име на хост, проверете разрешаването му в тази среда и адреса, който е дало, защото отговорът на корпоративния DNS от вашия лаптоп не доказва нищо за пространството от имена на услугата. Запазете проверката на името на хоста по TLS и собствената автентикация на отдалеченото приложение.

Очаквайте документираните закъснения при свързване при стартиране на Direct VPC и дайте на клиента стратегия за готовност или повторен опит, вместо да диагностицирате всяко студено стартиране като счупен тунел.

Връщане назад и какво това не прави

За връщане назад върнете мрежовите настройки и настройките за изход на услугата към предишните им стойности и потвърдете, че по-ранната ревизия все още обслужва трафик. Запазете командата gcloud в записа за промяната, защото обратното на частична промяна не е очевидно след шест седмици. Премахването на връзката към VPC връща услугата към предишния ѝ път на изход, което може да е точно това, което искате по време на инцидент.

Този дизайн покрива връзките, които Cloud Run инициира, и техните отговори. Той не дава на локалната мрежа адресируем сокет вътре в услугата, защото входящото излагане е решение за ingress.

Подобни статии