Что делать с IP-шлюзом (gateway), если обновился один из сервисов?

Да ты посмотри, какая тема интересная подъехала! Сервис обновился — и тут же, как по маслу, начинается: а шлюз-то наш, блядь, теперь что, в танце пуститься должен? Ну да, ёпта, если сервис начал выёбываться и менять свои сетевые повадки, то без изменений на шлюзе — нихуя не заработает. Сейчас разжую.

Смотри, тут три главных сценария, где наш шлюз может накрыться медным тазом.

1. Сервис вздумал порт или протокол поменять. Ну ясен пень, если раньше он на 8080-м сидел, а теперь переполз на 8443 и с HTTPS замутил, то все наши старые правила — просто в помойку. Надо в ACL или NAT тыкать, как слепой котёнок, пока не попадёшь куда надо. Вот, например, на линуксовом шлюзе с iptables:

# Старое правило для порта 8080 выкидываем нахуй
iptables -D FORWARD -p tcp --dport 8080 -j ACCEPT
# А теперь пускаем трафик на новый порт 8443
iptables -A FORWARD -p tcp --dport 8443 -j ACCEPT

А если у тебя Cisco-маршрутизатор торчит, то там тоже всё просто, блядь:

no access-list 101 permit tcp any any eq 8080
access-list 101 permit tcp any any eq 8443

2. Сервис вообще съебал на другой IP-адрес или в другую подсеть. Вот это уже, блядь, хитрая жопа. Надо лезть в статические маршруты и смотреть, не упёр ли он в никуда. Может, ему новый путь проложить через шлюз 10.0.0.1?

ip route add 192.168.2.0/24 via 10.0.0.1 dev eth0

Главное — не накосячить, а то весь трафик уйдёт в сраку.

3. Сервис решил стать параноиком и включил шифрование (TLS). Ну тут, ёперный театр, вообще веселье начинается. Если шлюз у тебя умный и в SSL-инспекцию играет, то придётся ему новые сертификаты впендюрить или правила DPI подкрутить. А иначе он будет смотреть на зашифрованный поток как баран на новые ворота — нихуя не понимая.

Как вообще это делать, чтобы не обосраться?

1. Меняем конфигурацию. Но не руками, блядь, а через какой-нибудь Ansible или Terraform, если шлюз в облаке. Чтобы всё по-взрослому, с историей и возможностью отката. Руками ты только всё просрёшь, я тебе гарантирую.
2. Тестируем, блядь! Не просто "ой, вроде работает". Берёшь хост, который похож на боевой, и гоняешь curl, telnet или свои проверки через обновлённый шлюз. Пока не убедишься, что всё летает — не успокаивайся. Доверия ебать ноль ко всем этим изменениям.
3. Готовим план отката. Это святое. Перед тем как что-то трогать, ты должен чётко знать, как вернуть всё как было, если пиздец наступит. Потому что когда всё полетит к чертям, у тебя волнение ебать, а терпения — ноль ебать. А с готовым планом ты хотя бы не будешь метаться как угорелый.

Короче, чувак, суть в чём: сервис — он как мартышлюшка, прыгает куда хочет. А шлюз — это такой строгий охранник, которому надо каждый раз объяснять новые правила пропуска. Не объяснишь — будет тебе хиросима, а не работа.