چگونه یک پراکسی عمومی از طریق VPN به یک مبدأ خصوصی می‌رسد

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

دو مدلی که روی یک نمودار شبیه هم به نظر می‌رسند

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

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

TLS کجا متوقف می‌شود و واقعاً چه چیزی را اثبات می‌کند

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

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

فقط به سرآیندهای ارسال‌شده از پراکسی اعتماد کنید

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

curl -s -o /dev/null -w '%{http_code}
' -H 'X-Forwarded-For: 203.0.113.9' http://172.20.5.40/

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

مبدأ را دقیقاً از یک جا قابل دسترس نگه دارید

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

ss -ltnp | grep -E ':(80|443)'

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