Казалось бы, мелочь в сети
DigitalOcean постепенно уводит исходящий (egress) трафик VPC с «просто публичного IP дроплета / Reserved IP» на отдельный сервис — VPC NAT Gateway. Идея здравая: backend сидит в приватной сети, в интернет ходит через централизованный NAT с одним статическим публичным egress IP. Это ближе к AWS NAT Gateway и удобнее для firewall allowlist у внешних API.
На бумаге переключение — пара вечеров. На практике у нас оно упёрлось не в DigitalOcean, а в whitelist крупного американского платёжного шлюза. «Простая» смена IP заняла около двух недель.
Как было раньше
Классическая схема на Droplet:
- есть Reserved IP (floating) — привычный «белый» адрес;
- исходящие к платёжке / банкам / webhooks часто шли с этого же (или с основного публичного) IP;
- в кабинете шлюза в whitelist висел один-два адреса — и годы работало.
Меняешь дроплет — Reserved IP перевешиваешь, egress для партнёров остаётся тем же. Комфортно.
Что поменялось с NAT Gateway
С NAT Gateway исходящий трафик идёт через отдельный managed-сервис, а не «с сетевой карточки дроплета как раньше». У gateway появляется свой статический public egress IP на весь срок жизни ресурса.
Важный нюанс, о который мы ударились:
- старый Reserved IP от дроплета нельзя просто «повесить» на NAT Gateway как привычный floating;
- на create можно попытаться задать адрес (в т.ч. из BYOIP), но это не тот же UX, что «перекинул Reserved IP на новый droplet»;
- в типичном сценарии после включения NAT вы получаете новый egress IP — и все внешние allowlist надо обновлять.
# смысл схемы (упрощённо)
VPC private Droplets --> NAT Gateway (static egress IP) --> Internet / Payment API
# раньше часто:
Droplet (+ Reserved IP) --> Payment API
Почему «просто переключить» заняло две недели
Технически на стороне DigitalOcean маршрут через NAT настраивается относительно быстро: gateway, default route в VPC, проверка curl ifconfig.me с дроплета — видите новый IP. Дальше начинается внешний мир.
- Новый egress IP нужно добавить в whitelist платёжного API.
- Платёжный шлюз — довольно крупный игрок в США (название сознательно не пишу). Добавление IP у них делается медленно: тикеты, очереди, «security review», эскалации.
- Параллельно всплыла блокировка ещё на одном уровне (фильтр/ACL/антифрод-контур поверх простого IP list) — пока не сняли/не согласовали, трафик частил отказами даже когда «IP вроде добавили».
- Итог: инфраструктурный cutover готов, платежи — нет. Ждём саппорт.
Новогодняя ночь и три недели переписки
Отдельно — про человеческий фактор. Вся новогодняя ночь, неделя до праздников и ещё примерно две недели после ушли в переписку с саппортом платёжки. Со стороны выглядело так: мы даём IP, логи, примеры запросов, скриншоты ошибок; они отвечают шаблонными отписками в духе «мы передали в соответствующую команду», «пожалуйста, подождите», «убедитесь, что используете правильный endpoint». Сделать по сути мало что могли — рычаг у внутренней security/ops-очереди, а не у L1, который с вами в чате.
Две недели для бизнеса — это не «сетевая миграция». Это простой или деградация платежей из‑за чужого SLA на whitelist, пока ваш NAT уже давно зелёный.
Что бы сделал иначе
- Заранее завести второй egress IP и подать в whitelist за недели до cutover (dual-run).
- Явно спросить у платёжки: только IP ACL или ещё ASN/geo/WAF-слой.
- Не совмещать миграцию NAT с праздничным окном — у enterprise-саппорта праздники = мёртвая зона.
- Держать rollback: старый путь egress, пока новый IP не подтверждён end-to-end платежом, а не только
ping. - Фиксировать в тикетах deadline бизнеса — иначе вас кормят «мы работаем над этим» бесконечно.
Вывод
VPC NAT Gateway у DigitalOcean — нормальная эволюция: исходящий трафик через отдельный сервис со статическим egress IP, ближе к «взрослому» облаку. Но старые Reserved IP не магически переезжают на этот контур, а значит меняется адрес, который видят партнёры. У нас «простая» смена упёрлась в медленный whitelist и дополнительную блокировку у крупного американского платёжного шлюза — и растянулась на две недели переписок, включая новогоднюю ночь. Мораль: планируйте egress-миграцию как compliance/vendor-проект, а не как iptables на вечер.