پورت VPN فوروارد‌شده: آنچه بازدیدکنندگان و ارائه‌دهنده می‌توانند ببینند
یک نگاشت ورودی به سرویس هویت عمومی می‌دهد، نه نام شما. جدا کنید که بازدیدکننده چه چیزی را می‌تواند پیوند دهد، ارائه‌دهنده چه می‌داند و چه مدت دوام می‌آورد.
فوروارد کردن یک پورت به غریبه‌ها مسیری به یک سرویس از طریق نشانی عمومی ارائه‌دهنده می‌دهد. همین یک تغییر، همزمان بر میزان قرار گرفتن در معرض و شناخت‌پذیری اثر می‌گذارد و هیچ‌یک از این دو نام کسی را که سرویس را اداره می‌کند منتشر نمی‌کند. جدا نگه داشتن این دو از خطاهای متضاد پرهیز می‌کند: تلقی کردن 'فوروارد' به عنوان ناشناسی و تلقی کردن آن به عنوان شناسایی. سه پرسش آنها را به‌روشنی جدا می‌کند و پاسخ‌ها از شواهد متفاوت می‌آیند.
سه شیء، سه پرسش متفاوت
نشانی عمومی را از برنامه‌ای که پشت آن پاسخ می‌دهد جدا نگه دارید و هر دو را از شخص یا سازمانی که این کار را اداره می‌کند جدا نگه دارید. هر یک مخاطب و شواهد خود را دارد. آمیختن آنها نتیجه‌هایی می‌دهد که مرتب به نظر می‌رسند و نادرست‌اند.
به همین ترتیب آنها را بررسی کنید. پرسش نخست درباره دسترس‌پذیری است، دومی پرسش هویت برنامه و سومی پرسش انتساب است که دو مورد نخست فقط تا حدی درباره آن روشنگری می‌کنند. وقتی کسی می‌پرسد آیا فوروارد کردن پورت خصوصی است، بپرسید کدام یک از این سه را مقصود دارد. پاسخ‌ها واقعاً تفاوت دارند و یک صفحه سیاست معمولاً فقط یکی از آنها را پوشش می‌دهد.
بازدیدکننده چه چیزی را می‌تواند میان نقاط پایانی پیوند دهد
بازدیدکننده به نقطه پایانی متصل می‌شود و آنچه را برنامه به‌طور مشروع ارائه می‌دهد می‌بیند: 'نام میزبان'، نام گواهی، صفحه ورود، محتوای منتشرشده. این جزئیات سرویس را شناسایی می‌کنند حتی وقتی نشانی دسترسی معمول آن پشت تونل پنهان است. دو نقطه پایانی که همان سایت نامدار را ارائه می‌دهند به ناظران پایه‌ای برای پیوند دادن آنها می‌دهند. هیچ چیز در این رفتار نشتی نیست، زیرا برنامه برای دیده شدن طراحی شده است.
تطابق گواهی‌ها، تغییر مسیرها و محتوای صفحه میان دو نقطه پایانی نشانه‌ای قوی است که به یک سرویس تعلق دارند. این همچنان ادعایی درباره سرویس است، نه درباره یک انسان، تا زمانی که رکورد دیگری آن دو را به هم پیوند دهد.
راهنمای حریم خصوصی IETF توضیح می‌دهد که چگونه شناسه‌های پایدار امکان مرتبط ساختن تعامل‌ها را در طول زمان می‌دهند. همبستگی به معنای انتساب نیست، زیرا چند نفر ممکن است یک سرویس را اداره کنند و یک نشانی می‌تواند میان مشترکان بی‌ارتباط جابه‌جا شود. همین تمایز مانع می‌شود که یافته همبستگی به اتهام تبدیل شود.
ارائه‌دهنده فوروارد چه چیزی باید بداند
برای تحویل یک اتصال ورودی، سیستم ارائه‌دهنده باید رابطه فعال میان نقطه ورود عمومی و مقصد داخلی را نگه دارد. این واقعیت عملیاتی با آنچه بازدیدکننده می‌بیند متفاوت است و باز هم با آنچه ارائه‌دهنده تصمیم می‌گیرد نگه دارد تفاوت دارد. وقتی صفحه سیاست را می‌خوانید دو پرسش را جدا نگه دارید، زیرا یکی اجتناب‌ناپذیر است و دیگری یک تصمیم. این جمله که تاریخچه مرور نگه داشته نمی‌شود، چیزی درباره تاریخچه نگاشت‌ها نمی‌گوید.
اینکه نگاشت‌های تاریخی، ارتباط‌های حساب یا رکوردهای اتصال باقی می‌مانند یا نه، پرسشی است درباره سیاست و پیاده‌سازی واقعی ارائه‌دهنده. فوروارد کردن ثابت نمی‌کند که هر دسته ثبت می‌شود. مشخصاً بپرسید کدام فیلدها پس از برداشتن نگاشت باقی می‌مانند و برای چه مدت.
دسترس‌پذیری ورودی از مسیریابی خروجی کلاینت، DNS و رفتار خطا نیز جدا است. افزودن یک نگاشت توصیف نمی‌کند که بقیه ترافیک کلاینت چگونه خارج می‌شود.
مدت دوام نگاشت، میزان قرار گرفتن در معرض را تغییر می‌دهد
یک نگاشت ممکن است برای یک نشست، برای یک رزرو، یا تحت سیاست ارائه‌دهنده‌ای که آن را تغییر می‌دهد دوام بیاورد. نه تخصیص دائمی و نه چرخش مداوم را نباید فرض کرد؛ رفتار مستند محصول را بخوانید و آنچه مشاهده می‌کنید یادداشت کنید. دو مشاهده با فاصله یک هفته درباره 'چرخش' بیشتر می‌گویند تا هر جمله بازاریابی در صفحه محصول. بازه مشاهده‌شده را کنار نقطه پایانی در یادداشت‌هایتان بنویسید، زیرا بازه بخشی از میزان قرار گرفتن در معرض است.
طول عمر تغییر می‌دهد که چه همبستگی ممکن است. یک نقطه پایانی پایدار ردیابی بلندمدت یک سرویس را دعوت می‌کند، در حالی که یکی چرخشی هر مشاهده را سخت‌تر به مشاهده پیشین متصل می‌کند. هیچ‌یک از این دو ویژگی تضمینی درباره رکوردهای ارائه‌دهنده نیست و هیچ‌یک جایگزین تصمیم درباره آنچه خود سرویس منتشر می‌کند نیست.
آگاهانه منتشر کنید، سپس هر دو در را ببندید
تأیید کنید که ارائه‌دهنده پروتکلی را که نیاز دارید مجاز می‌داند، که شنونده مقصد همانی است که منظورتان بود و اینکه کنترل‌های میزبان و برنامه هنوز دسترسی را محدود می‌کنند. پیش از انتشار ببینید سرویس چه چیزی به یک غریبه ارائه خواهد داد. این دو فرمان گواهی و سرصفحه‌هایی را که بازدیدکننده دریافت می‌کند نشان می‌دهند.
openssl s_client -connect pub.example.net:443 -brief < /dev/null
curl -sSI https://pub.example.net/انتشار یک چیز، افشای صفحه‌های مدیریت آن یا حذف ورود برنامه را توجیه نمی‌کند و ترجمه به سرویسی که هرگز TLS نداشته است TLS نمی‌دهد. پروتکل رمزگذاری‌شده و بررسی‌های هویت سرور را در جای خود نگه دارید، صرف‌نظر از اینکه ترافیک چگونه می‌رسد. سپس سرصفحه‌های پاسخ را بررسی کنید، زیرا یک 'بنر' یا صفحه اشکال‌زدایی می‌تواند به یک غریبه بیشتر از آنچه سرویس قصد دارد بگوید. آنچه این دو فرمان برمی‌گردانند همان دیدگاهی است که یک ناظر می‌بیند.
بازنشسته کردن سرویس یعنی دو بستن، نه یکی: نگاشت را از طریق صاحبش پس بگیرید، سپس شنونده و حق‌تقدم را به عنوان دو مورد جدا بررسی کنید. نقطه پایانی نشانک‌شده که از پاسخ دادن باز می‌ایستد، اعتبارنامه‌ای را لغو نمی‌کند و اطلاعاتی را که پیش‌تر تحویل داده شده بازنمی‌گرداند.