GCP Cloud VPN: проверяйте шлюз, туннель и firewall по порядку

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

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

Между этой зелёной иконкой и ответом стоят четыре решения, и они отказывают в предсказуемом порядке. Начните с самого дешёвого.

Три объекта, и только один из них шифрует

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

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

Удалённая сторона держит свой список, обычно называемый доменом шифрования, и терминальное оборудование сравнивает его с вашим. Ни одна сторона не согласовывает селектор, который ей никогда не давали.

Тип маршрутизации решает, что попадает в таблицу маршрутов

Cloud VPN предлагает три формы маршрутизации, и они не смешиваются чисто. Маршрутизация на основе политик сохраняет статические пары селекторов, маршрутизация на основе маршрутов ждёт, что статические маршруты добавите вы сами, а динамическая объявляет префиксы через Cloud Router по BGP. Выберите одну осознанно.

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

Динамическая — единственная форма, позволяющая защищаемым префиксам меняться без пересоздания туннеля, и она втягивает Cloud Router в набор объектов, которые нужно проверить. Статические селекторы остаются рабочими, когда партнёр — аппаратный firewall, не умеющий говорить BGP. Тогда обоим концам нужны одинаковые диапазоны, и более конкретная запись должна победить на обеих сторонах. Пара, расходящаяся на одну подсеть, устанавливается и затем несёт половину вашего трафика.

Неявный запрет стоит за туннелем

Входящий трафик оценивается против неявного запрета с самым низким приоритетом, и этому правилу всё равно, что пакет пришёл зашифрованным. Пока правило firewall не назовёт локальный диапазон и используемый порт, пакет расшифровывается, проверяется и отбрасывается. Журнал VPN остаётся чистым всё это время, потому что туннель сделал ровно то, что обещал.

Вместо этого читайте журнал отказов firewall, когда туннель работает, а проверка завершается тайм-аутом, затем ограничьте правило исходным диапазоном и нужными портами:

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

Работа только одного направления — подсказка про firewall

Исходящий трафик ведёт себя иначе, потому что неявное правило разрешения позволяет экземплярам отправлять куда угодно. Центр обработки данных, который не достигает VM, часто стоит за безупречно работающим исходящим путём в обратную сторону. Эта асимметрия отделяет пропуск в firewall от отказа маршрутизации, ведь отказ маршрутизации ломает оба направления сразу. Проверьте обратное направление, прежде чем править ещё одно правило.

Создание адресов — тоже операция с квотами. Проект у предела используемых внешних адресов отклоняет подключение с ошибкой, которая читается как отказ в правах.

Селекторы, квоты, затем четыре проверки

Туннели, созданные в консоли, иногда возвращают пустой удалённый селектор трафика из gcloud compute vpn-tunnels describe, хотя сгенерированные маршруты корректно несут трафик. Сравните то, что фиксирует API, с диапазонами, которые вы действительно защищаете, прежде чем решать, что туннель неверен. Создание через API или SDK сохраняет селектор явным.

Квоты — другой простой недосмотр. Запрашивайте увеличение до окна обслуживания, а не во время него, и проверяйте количество адресов в том же проекте, что и шлюз.

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

Похожие статьи