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

تیکت معمولاً چه چیزی را توصیف می‌کند

تلفنی را روی Wi-Fi با یک تونل برپا تصور کنید. واسط Wi-Fi یک نشانی LAN دارد، واسط تونل یک نشانی درونی تخصیص‌یافته دارد، و درخواستی که از تونل بیرون می‌رود به یک سرویس عمومی از هر مبدأیی می‌رسد که از هر ترجمه‌ای در مسیر جان سالم به در ببرد. اپی که نشانی درونی را چاپ می‌کند و سروری که مبدأ ترجمه‌شده را ثبت می‌کند هر دو درست گزارش می‌دهند، و این دو مقدار هرگز یکی نخواهند شد.

این سه مشاهده در آنچه می‌توانند اثبات کنند متفاوت‌اند، نه فقط در آنچه توصیف می‌کنند.

ObservationWhat it describesWhat it cannot prove
An address on a local interfaceOne configured attachment: Wi-Fi, cellular or a tunnelThe source a remote site receives
A socket's local endpointThe binding used by that one connectionThe address after translation further along
The peer address at a serviceWhat arrived at that observation pointAny other interface on the phone

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

یک فراخوان سوکت به چه چیزی می‌تواند پاسخ دهد و به چه چیزی نه

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

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

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

مشاهده‌ای را انتخاب کنید که با پرسش می‌خواند

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

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

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

نام واسط‌ها یک آشکارساز نیست

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

فیلد را به نام مشاهده‌ای بنامید که نگه می‌دارد. local_interface_address، socket_local_endpoint و service_observed_source دست‌وپاگیر و بی‌ابهام‌اند، و بی‌ابهامی چیزی است که می‌خواهید وقتی مقدار یک هفته بعد در یک تیکت پشتیبانی می‌افتد. یک ستون به نام device IP هر سه را جمع می‌کند و بعد به آن اعتماد می‌شود چنان که گویی یکی است.

هویت را از ستون نشانی بیرون نگه دارید

یک خروجی مشترک VPN هویت کاربر نیست، و یک نشانی خصوصی اعتبارنامه دسترسی نیست. هر دو یک مسیر را توصیف می‌کنند نه یک شخص، و برخورد با هر یک از این دو به عنوان احراز هویت یک حادثه مسیریابی را به تصمیم مجوز تبدیل می‌کند.

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

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

مقالات مرتبط