چرا Port-Share همه بازدیدکنندگان وب‌سایت را شبیه localhost نشان می‌دهد

هر خط در گزارش دسترسی همان نشانی loopback را نشان می‌دهد، در حالی که خود صفحه بارگذاری می‌شود و گواهی درست بررسی می‌شود. هیچ چیز به معنای دسترس‌ناپذیری خراب نیست، و همین است که باعث می‌شود این وضعیت ماه‌ها دوام بیاورد. آنچه خراب شده انتساب است: بک‌اند وب نشانی گامی را ثبت می‌کند که اتصال را ارسال مجدد کرده، و هر تصمیم بعدی که به گزارش اعتماد کرد همان پاسخ نادرست را به ارث برد.

بررسی‌های زیر از سیم به سمت داخل می‌روند. در نخستین بررسی‌ای که مقدار مشاهده‌شده را توضیح می‌دهد توقف کنید، زیرا هر گام بعدی فرض می‌کند گام‌های پیشین از پیش درست‌اند. هیچ‌یک از آن‌ها نیازمند حدس‌زدن پیکربندی فرانت‌اند نیست.

دو اتصال را دنبال کنید، نه خط گزارش را

Port-Share دو پروتکل را روی یک شنونده TCP چندگانه می‌کند. OpenVPN نخستین بایت‌های اتصال ورودی را بررسی می‌کند، اگر شبیه پروتکل خودش باشد نگهش می‌دارد، و هر چیز دیگر را به مقصد دوم می‌سپارد. آن مقصد معمولاً یک سرور وب روی همان میزبان است، بنابراین سوکت پذیرفته‌شده سرور وب فرایند OpenVPN را به عنوان همتا دارد.

ss -ltnp 'sport = :443'
ss -tnp 'dport = :8080'

فرمان نخست نشان می‌دهد شنونده عمومی از آنِ کیست. فرمان دوم اتصال‌هایی را نشان می‌دهد که به درگاه بک‌اند می‌رسند، و نشانی همتای آن‌ها همان چیزی است که گزارش دسترسی چاپ می‌کند. اگر آن همتا loopback باشد، گزارش دقیق است و اطلاعات یک لایه پیش‌تر گم شده. تغییر نام فیلد گزارش یا فعال‌کردن ماژول IP مشتری نشانی‌ای را که اتصال هرگز حمل نکرده بازنمی‌گرداند.

این همان بررسی‌ای است که همه چیز دیگر را تعیین می‌کند. اگر همتای بک‌اند نشانی مرورگر باشد، اشتراک درگاه مشکل شما نیست و قالب گزارش مشکل است.

ارسال لایه انتقال، تزریق سرآیند نیست

فرستنده بایت‌ها را جابه‌جا می‌کند. HTTP را تجزیه نمی‌کند، پس نمی‌تواند سرآیندی به درخواستی بیفزاید که هرگز آن را به عنوان درخواست نمی‌خواند، و نمی‌تواند چیزی به جریان TLS بیفزاید که دست‌نخورده عبور می‌دهد. ماژولی که منتظر سرآیند پراکسی است همچنان منتظر چیزی می‌ماند که هیچ مؤلفه‌ای تولید نمی‌کند.

دو سازوکار می‌توانند نشانی اصلی را حمل کنند و هر دو به توافق در دو طرف نیاز دارند. پروتکل PROXY سرآیند کوچکی به ابتدای اتصال می‌افزاید و بک‌اند باید برای انتظار آن پیکربندی شده باشد؛ بک‌اندی که انتظارش را ندارد آن بایت‌ها را آغاز درخواست می‌پندارد و به شکلی گیج‌کننده شکست می‌خورد. سرآیندهای پراکسی مورد اعتماد مانند X-Forwarded-For وقتی کار می‌کنند که پراکسی آگاه به HTTP آن‌ها را تنظیم کند و به بک‌اند گفته شود کدام همتاها مجاز به ادعای آن‌ها هستند.

هیچ‌یک خودکار نیست و هیچ‌یک به‌طور پیش‌فرض ایمن نیست. بک‌اندی که به هر سرآیند ارسال‌شده ورودی باور کند به مشتری اجازه می‌دهد نشانی خودش را انتخاب کند، و این یک نادرستی در گزارش را به دورزدن کنترل دسترسی تبدیل می‌کند. نمایش را یک بار روی میزبان آزمایشی اجرا کنید پیش از آنکه به هیچ سرآیندی در مسیر تولید اعتماد کنید.

curl -sS -H 'X-Forwarded-For: 127.0.0.1' https://site.example.com/health
grep -F '127.0.0.1' /var/log/nginx/access.log | tail -n 3

پوشه اختیاری نگاشت مبدأ

اشتراک درگاه یک آرگومان پوشه اختیاری دارد که نگاشتی میان نشانی مبدأ اصلی و اتصال ارسال‌کننده ثبت می‌کند، روی سکوهایی که این ویژگی در آن‌ها پیاده‌سازی شده است. انتظار می‌رود سمت وب به آن نگاشت مراجعه کند؛ این یک سرآیند نیست و در درخواست تزریق نمی‌شود.

آن طراحی ارزش دانستن دارد، زیرا توضیح می‌دهد چرا برخی استقرارها نشانی‌های واقعی را گزارش می‌کنند و برخی نه، با پیکربندی فرانت‌اندِ ظاهراً یکسان. تفاوت در سمت دریافت‌کننده است و معمولاً در ماژول یا وصله‌ای زندگی می‌کند که بیشتر سرورهای وب بسته‌بندی‌شده آن را به‌طور پیش‌فرض فعال نمی‌کنند. مستندات سرور وب خود را برای قلاب دقیقی که ارائه می‌دهد بخوانید و تأیید کنید ماژول بارگذاری شده است، نه اینکه آن را فرض کنید.

اگر این مسیر را بروید، آن را یکپارچه‌سازی دو نیمه بدانید: نگاشتی که فرستنده می‌نویسد و جست‌وجویی که بک‌اند انجام می‌دهد. هر دو را بررسی کنید و تأیید کنید پوشه از راه‌اندازی دوباره جان سالم به در می‌برد و روی شنونده‌ای پرترافیک بی‌مرز رشد نمی‌کند.

تصمیم بگیرید کدام مؤلفه ضامن نشانی است

پیش از تغییر پیکربندی، مؤلفه‌ای را که مجاز به ادعای نشانی مشتری است و مؤلفه‌هایی را که مجاز به باور آن‌اند نام ببرید. یک پاسخ نوشته‌شده از لغزش معمول جلوگیری می‌کند، جایی که سه لایه مختلف هر یک به منبعی متفاوت اعتماد می‌کنند.

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

آنچه کار نمی‌کند این است که نشانی loopback ارسال‌شده را شاهدی بگیریم بر اینکه درخواست روی همین ماشین آغاز شده. این استنتاج دقیقاً برعکس است: نشانی حاضر است چون یک مؤلفه محلی اتصال را ساخته. قاعده‌ای که این‌گونه نوشته شود هر کسی را که به شنونده برسد می‌پذیرد.

قاعده را بیازمایید، نه صفحه را

صفحه‌ای که بارگذاری می‌شود ثابت می‌کند مسیر ارسال مجدد کار می‌کند و درباره انتساب چیزی نمی‌گوید. مصرف‌کننده نشانی را بیازمایید: قاعده دسترسی، محدودیت نرخ، ورودی حسابرسی، جست‌وجوی جغرافیایی.

curl -sS -o /dev/null -w '%{http_code}\n' https://site.example.com/
tail -n 5 /var/log/nginx/access.log
grep -c '' /var/log/nginx/access.log

یک درخواست خارجی مجاز را با هر دو گزارش فرانت‌اند و بک‌اند مقایسه کنید و تأیید کنید قاعده‌ای که باید رد کند همچنان رد می‌کند و یکی که باید بپذیرد همچنان می‌پذیرد. اگر خط گزارش درست است اما قاعده همچنان طوری رفتار می‌کند که گویی همه محلی‌اند، قاعده فیلدی متفاوت از آنچه اصلاح کردید می‌خواند.

با نوشتن زنجیره انتساب در یادداشت‌های استقرار تمام کنید: کدام شنونده، کدام فرستنده، کدام سرآیند یا نگاشت، و کدام بک‌اند پیکربندی شده تا به آن اعتماد کند. نفر بعدی که خطی از گزارش را می‌خواند به هر چهار مورد نیاز دارد، و نبود آن یادداشت همان چیزی است که باعث می‌شود همان تیکت یک سال بعد دوباره باز شود. آن را کنار پیکربندی نگه دارید نه در رشته گفت‌وگو.