ریست TCP ثابت نمی‌کند که VPN شما مسدود شده است

عبارت «اتصال ریست شد، راه‌اندازی دوباره» در گزارش کلاینت ظاهر می‌شود و نتیجه پیش از شواهد می‌رسد. کسی تصمیم می‌گیرد که شبکه VPN را مسدود می‌کند، یا گواهی اشتباه است، یا کشوری خاص دخالت می‌کند. ریست یک بسته TCP است که اتصال را پایان می‌دهد، و خط گزارش ثبت می‌کند که کلاینت شما یکی دریافت کرده است. اما دستگاهی که آن را فرستاده یا دلیل ارسال را نام نمی‌برد.

ریست یک بسته است، نه حکم

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

این تمام چیزی است که کلاینت می‌داند. RST می‌توانست از سرور، یک پروکسی، یک فایروال یا یک توزیع‌کننده بار که وضعیتش را از دست داده آمده باشد.

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

تأیید کنید کدام اتصال ریست شده است

نخست بررسی کنید که پروفایل فعال واقعاً از TCP استفاده می‌کند. ریست روی تونل UDP بی‌معناست، و گزارش یک پروکسی HTTP می‌تواند به بخش TCP دیگری غیر از خود VPN مربوط باشد.

مقصد، درگاه، زمان تلاش و مرحله‌ای را که کلاینت به آن رسیده بود ثبت کنید.

مرحله سودمندترین فیلد است. ریست در هنگام دست‌دادن TLS به یک گروه از مظنونان اشاره دارد؛ ریست پس از احراز هویت به گروهی دیگر. بدون مرحله، هر نظریه‌ای جور درمی‌آید.

دو سر مسیر را مقایسه کنید

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

اگر می‌توانید، هم در کلاینت و هم در سرور ضبط کنید. ریستی که در کلاینت دیده می‌شود اما در سرور دیده نمی‌شود، در سرور آغاز نشده است.

مراقب قطعه‌های RST در هر دو جهت باشید:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

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

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

این هنوز یک دستگاه میانی مشخص را شناسایی نمی‌کند. دامنه را به یک مسیر محدود می‌کند، که نتیجه‌ای سودمند و صادقانه است.

تفاوت میان «این مسیر شکست می‌خورد» و «این کنشگر نام‌برده آن را ایجاد کرد» را حفظ کنید. اولی آزمون‌پذیر است؛ دومی معمولاً از یک کلاینت تنها نیست.

اصلاح را بدون تغییر تنظیمات اعتماد بررسی کنید

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

مؤلفه شناسایی‌شده را از طریق مالکش اصلاح کنید، سپس همان پروفایل و همان مشاهده را تکرار کنید:

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

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