نشانی VPN را در فهرست مجاز گذاشتید و هنوز مسدود است؟ ردش را بگیرید

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

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

نشانی در برنامه همان نشانیِ رسیده نیست

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

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

یک درخواست را تا مرز پالایشش دنبال کنید

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

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

iptables -vnL INPUT --line-numbers
iptables -S INPUT | head -n 40
ss -ltnp | grep -E ':(443|9443)\b'

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

مسیر را با یک ثبت محدود بررسی کنید

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

tcpdump -ni any 'tcp dst port 9443' -c 20

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

ترتیب زنجیره را بخوانید، نه فقط قاعده را

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

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

قاعده‌ای را که مالکش کنترل می‌کند تغییر دهید

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

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