GCP Cloud VPN: проверявайте шлюза, тунела и защитната стена по ред

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

Конзолата ви показва зелен тунел, локалният мониторинг все още не може да достигне нито един инстанс, а преизграждането на тунела изглежда като очевидното решение. Рядко е така. Установеният тунел доказва само, че два шлюза са завършили IKE обмена. Той не казва нищо за това дали пакетът някога е бил допуснат във вашия VPC.

Четири решения стоят между тази зелена икона и отговора и те се провалят в предвидим ред. Започнете с най-евтиното.

Три обекта и само един от тях криптира

VPN шлюзът притежава външния адрес, към който криптира вашият партньор. В конзолата никога не го създавате на ръка: изберете или резервирайте адрес във формата за връзка и шлюзът се появява с него. HA шлюзът заема два адреса на два интерфейса, което има значение при проверката на квотите по-късно.

Тунелът е сдвояването между този шлюз и партньора. Той носи споделената тайна и селекторите на трафик, които обещава да защитава. Именно в тези селектори започват повечето тихи откази. Тунел, чийто локален селектор покрива 10.0.0.0/24, няма да доставя 10.0.1.0/24, колкото и здрав да изглежда статусът.

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

Типът маршрутизация решава какво достига до таблицата с маршрути

Cloud VPN предлага три форми на маршрутизация и те не се смесват чисто. Маршрутизацията, базирана на политики, пази статичните двойки селектори, маршрутизацията, базирана на маршрути, очаква вие сами да добавите статични маршрути, а динамичната маршрутизация обявява префикси през Cloud Router по BGP. Изберете една нарочно.

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

Динамичната е единствената форма, която позволява защитените префикси да се променят без преизграждане на тунела, и тя вкарва Cloud Router в набора от обекти, които трябва да проверите. Статичните селектори остават работоспособни, когато партньорът е хардуерна защитна стена, която не може да говори BGP. Тогава двата края се нуждаят от едни и същи диапазони и по-конкретният запис трябва да победи и в двата. Двойка, която се разминава с една подмрежа, се установява и след това носи половината от трафика ви.

Подразбиращото се забранено стои зад тунела

Входящият трафик се оценява срещу подразбиращо се забранено с най-нисък приоритет и това правило не се интересува, че пакетът е пристигнал криптиран. Докато правило в защитната стена не назове локалния диапазон и използвания порт, пакетът се декриптира, инспектира и отхвърля. VPN журналът остава чист през цялото време, защото тунелът направи точно това, което обеща.

Вместо това четете журнала за откази на защитната стена, когато тунелът е активен, а проверката изтича, после ограничете правило до изходния диапазон и портовете, които ви трябват:

gcloud compute firewall-rules create allow-from-dc \
  --network=vpn-vpc \
  --direction=INGRESS \
  --source-ranges=192.168.10.0/24 \
  --allow=tcp:22,tcp:5432,icmp

Работата само в една посока е подсказка за защитната стена

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

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

Селектори, квоти, после четирите проверки

Създадените в конзолата тунели понякога връщат празен отдалечен селектор на трафик от gcloud compute vpn-tunnels describe, докато генерираните маршрути пренасят трафика правилно. Сравнете какво записва API с диапазоните, които наистина защитавате, преди да решите, че тунелът е грешен. Създаването му през API или SDK запазва селектора явен.

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

Работете отвън навътре: статус на партньора, двата списъка със селектори, маршрут за всяка страна, входящо правило за изходния диапазон и порт, после прихващане на пакети. Запишете адреса на шлюза, двата списъка със селектори и типа маршрутизация в заявката за промяна, докато тунелът е нов, защото следващият инженер, който добави подмрежа, ще се нуждае и от трите.

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