Вебхук GitHub не доходить до приватного Jenkins: виправте шлях

Ви можете відкрити Jenkins через VPN і все одно побачити, що GitHub повідомляє про невдалий вебхук, бо це два різні з’єднання з двома різними власниками. Браузер іде тунелем, який узгодив ваш ноутбук; служба доставки GitHub починається в публічному інтернеті й не має маршруту в приватну мережу. Доступ до репозиторію цього не змінює, хоч сам Jenkins може без проблем брати з того самого репозиторію. Виберіть вхідну точку, релей або опитування, а потім перевірте шлях, яким подія справді йде.

Сеанс браузера доводить лише один напрямок

VPN-з’єднання відповідає на одне питання: чи може цей ноутбук дістатися внутрішнього хоста. Доставка вебхука питає про інше: чи може зовнішня служба відкрити з’єднання до того хоста. Те, що Jenkins бере з репозиторію, — вихідний трафік, і він нічого не каже про вхідну доступність. Тримайте обидва напрямки на окремих лініях схеми, включно з тим, яка сторона починає кожен.

Прочитайте запис доставки, перш ніж щось змінювати. Тайм-аут, скидання з’єднання й прийнятий запит, що не збігся з жодним завданням, мають трьох різних власників: мережу, проксі та налаштування тригера.

Варіант A: відкрити вузьку вхідну точку

Якщо організація вже публікує схвалений вхід, відкрийте шлях вебхука, а не панель керування. Зазвичай це означає правило зворотного проксі, яке приймає POST за URL хука і передає їх у Jenkins, поки адміністративний інтерфейс залишається недоступним ззовні.

curl -sS -o /dev/null -w "%{http_code}\n" -X POST https://jenkins.example.com/github-webhook/

Виконайте цей тест із мережі без доступу до VPN, бо успіх зсередини тунелю нічого не доводить. Вхідна точка має відхиляти запити без спільного секрету, який GitHub надсилає як заголовок підпису, і приймати лише той єдиний шлях і метод, які ви опублікували. Публічна консоль Jenkins — це не виправлення вебхука, а інцидент, що чекає на наступний сканер. Обмежте правило достатньо вузько, щоб решта застосунку зберегла попередні засоби контролю доступу.

Варіант B: розвернути напрямок релеєм

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

ssh -N -R 9000:localhost:8080 relay.example.net

Рекомендації Jenkins щодо вебхуків за міжмережевими екранами описують цю схему, і їх варто прочитати, перш ніж писати власний пересилач. Завершуйте TLS на релеї, перевіряйте підпис до того, як подія дійде до завдання, і стежте за вихідним каналом, бо тунель, що впав, виглядає точно як подія, яку так і не надіслали. Переконайтеся також, що релей зберігає тіло запиту байт у байт, оскільки перевірки підпису не проходять на JSON, який дорогою розібрали й заново закодували.

Варіант C: опитувати репозиторій

Опитування обмінює затримку на простоту і взагалі не потребує вхідного шляху. Jenkins може опитувати за розкладом, або невелике завдання може запитати API і запустити збирання, побачивши незнайому ревізію.

curl -sS -u "$USER:$TOKEN" "https://api.github.com/repos/OWNER/REPO/commits?per_page=1"

Кожне опитування витрачає виклики API і додає затримку між push і збиранням, що стає помітним на завантажених репозиторіях і спільних обмеженнях швидкості. Йому також потрібні облікові дані, збережені там, де працює опитувач, тож обмежте токен доступом до репозиторію лише на читання і змінюйте його, як будь-який інший секрет. Виберіть це, коли потік подій невеликий або коли вхідну точку ніколи не схвалять, і напишіть це в описі завдання, щоб потім ніхто не дивувався, чому збирання відстають.

Приймайте справжню доставку, а не завантаження сторінки

Який би варіант ви не обрали, приймальний тест — це подія, надіслана вихідною платформою, а не вкладка браузера, відкрита з привілейованого ноутбука. Надішліть порожній коміт у чернеткову гілку і прочитайте код відповіді доставки, журнал релея або вивід завдання опитування саме в такому порядку. Відповідь 200 від вхідної точки без збирання означає, що фільтр тригера неправильний; тайм-аут означає, що шлях усе ще закритий. Запишіть, яку з трьох схем використовують, інакше наступний відлагоджувач повторить тест у браузері й потрапить у той самий глухий кут.

Застосуйте ту саму логіку до зворотних викликів платежів та інших зовнішніх сповіщень: кожному потрібен власний маршрут у приватний застосунок, навіть коли в кожної людини вже є сеанс VPN. Шлях доставки належить до проєктування застосунку, а не до виноски про мережі.