میتوانید 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 و ساخت میافزاید که در مخزنهای پرترافیک و محدودیتهای نرخ مشترک دیده میشود. همچنین به اعتبارنامههایی نیاز دارد که هر جا نظرسنج اجرا میشود ذخیره شوند، پس توکن را به دسترسی فقطخواندنی به مخزن محدود کنید و مانند هر راز دیگری آن را بچرخانید. این را وقتی حجم رویدادها کم است یا وقتی هیچ نقطه ورودی هرگز تأیید نمیشود انتخاب کنید و آن را در شرح کار بنویسید تا بعداً کسی نپرسد چرا ساختها عقب میافتند.

یک تحویل واقعی را بپذیرید، نه بارگذاری صفحه

هر گزینهای که انتخاب کردهاید، آزمون پذیرش رویدادی است که پلتفرم منبع میفرستد، نه زبانه مرورگری که از لپتاپی دارای امتیاز باز شده باشد. یک کامیت خالی به شاخه موقت push کنید و کد پاسخ تحویل، گزارش رله یا خروجی کار نظرسنجی را به همین ترتیب بخوانید. پاسخ 200 از نقطه پایانی بدون ساخت یعنی فیلتر ماشه اشتباه است؛ پایان مهلت یعنی مسیر هنوز بسته است. ثبت کنید کدام یک از سه طرح در استفاده است، وگرنه نفر بعدی که اشکالزدایی میکند آزمون مرورگر را تکرار میکند و به همان بنبست میرسد.

همین استدلال را به بازخوانیهای پرداخت و دیگر اعلانهای بیرونی تعمیم دهید: هر کدام به مسیر خودش به برنامه خصوصی نیاز دارد، حتی وقتی هر انسانی از قبل نشست VPN دارد. مسیر تحویل به طراحی برنامه تعلق دارد، نه به پانوشتی درباره شبکه.

مقالات مرتبط