IP خروجی VPN اثبات تونل نیست: سرورها چه می‌بینند

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

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

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

هر چیزی پس از آن نشانی مبدأ دادهٔ برنامه است و برنامه تنها تا جایی می‌تواند به آن اعتماد کند که آن را احراز هویت می‌کند.

آزمایش کنید خروجی شما چگونه دیده می‌شود

پیش از نوشتن قاعده از هر دو سر مسیر را ببینید. دید کارخواه از خروجی خودش و دید سرور از اتصال دو واقعیتی هستند که اهمیت دارند.

curl -sS https://api.ipify.org; echo
ss -tn state established '( sport = :443 )' | head

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

فقط یکی از دو مجموعهٔ خروجی را می‌توان فهرست کرد

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

curl -sS https://check.torproject.org/torbulkexitlist | wc -l

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

نشانی‌ها را به‌عنوان ورودی سیاست به کار ببرید، نه به‌عنوان اثبات

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

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