Статична вихідна IP-адреса

Клієнтам, чиї приймачі стоять за брандмауером, потрібна фіксована IP-адреса для списку дозволених.

Налаштування для цього в Railhook немає: HTTP-клієнт воркера не має параметра forward-проксі й не читає HTTP_PROXY чи HTTPS_PROXY. Розв’язуйте задачу рівнем нижче. Доставки надсилає лише воркер, тож фіксація його вихідної адреси фіксує її для кожного вебхука.

worker  →  your network's outbound address  →  your customer's endpoint
                        ↑
            this is the address they allowlist

Типово це будь-яка адреса вашої інфраструктури (публічна IP-адреса вузла, спільний пул NAT, адреса, що змінюється із заміною вузла), і жодну з них не можна внести до списку дозволених.

Варіант 1: NAT-шлюз зі статичною IP-адресою

Розмістіть підмережу воркера за керованим NAT-шлюзом зі статичною адресою. Почніть із цього: він не потребує налаштувань Railhook і переживає заміну вузлів.

Середовище	Сервіс	Що прикріпити
AWS	NAT Gateway	Elastic IP у таблиці маршрутів приватної підмережі вузлів воркера
Google Cloud	Cloud NAT	Зарезервовану статичну зовнішню IP-адресу
Azure	NAT Gateway	Статичну публічну IP-адресу
Інші провайдери, bare metal	Хост-шлюз	Плаваючу IP-адресу; типовий маршрут воркера має йти через цей хост

Опублікуйте дві адреси

Один NAT-шлюз є єдиною точкою відмови. Другу адресу клієнтам простіше внести до списку дозволених заздалегідь, ніж посеред збою.

Варіант 2: окремий пул вузлів

Щоб фіксована адреса була лише для вебхуків, запускайте воркер на вузлах за NAT, а інші навантаження деінде. Тоді трафік панелі, резервні копії й завантаження образів не йдуть через адресу, яка може бути дорогою чи мати ліміти.

Обережно

У Helm-чарті nodeSelector і tolerations є спільними значеннями верхнього рівня для API і воркера. Щоб розмістити окремо лише воркер, змініть його deployment патчем або задайте для нього окреме перевизначення значень.

Варіант 3: вихідний шлюз

Якщо у вас є service mesh або вихідний шлюз (Istio, Cilium), спрямуйте трафік воркера через нього. Перенаправлення відбувається нижче рівня застосунку, тож налаштування Railhook не потрібне.

Вихідний шлюз також може журналювати чи обмежувати, куди йдуть доставки. Він доповнює власний захист Railhook від SSRF, але не замінює його: Railhook перевіряє кожен URL доставки до формування запиту й відхиляє приватні адреси, якщо їх не дозволено через WEBHOOK_ALLOW_PRIVATE_IPS або WEBHOOK_ALLOWED_HOSTS.

Що повідомити клієнтам

Опублікуйте адреси там, де клієнти знайдуть їх без запиту, і вкажіть:

1. Усі адреси, які можуть використовуватися.
2. Що список може змінитися і за скільки часу ви попередите. Список дозволених, змінений без попередження, означає збій на чужій інфраструктурі.

Це стосується лише вебхуків, які надсилаєте ви. Провайдерам, що надсилають вебхуки до Railhook, потрібна ваша адреса для вхідних вебхуків, а не список дозволених.