OpenVPN روی 443 هنوز مسدود است؟ ببینید شبکه چه چیزی را بازرسی می‌کند

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

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

شنونده بومی VPN روی TCP 443 از نخستین بسته به پروتکل خودش سخن می‌گوید. ClientHello یک میدان نسخه، یک مقدار تصادفی و فهرستی از افزونه‌ها دارد، و دستگاهی که چند صد بایت بخواند می‌تواند تفاوت را بدون رمزگشایی هیچ چیز تشخیص دهد. ارضا کردن شماره پورت ارزان است، و آنچه پالایه واقعاً بررسی می‌کند شکل پروتکل است. قواعد معمولاً به تفکیک پروتکل هم نوشته می‌شوند، پس سیاستی که TLS را بازرسی می‌کند درباره UDP چیزی نمی‌گوید.

پیشکار شفافی که بر یک نشست معتبر TLS پافشاری می‌کند، پیوند را هنگام برپاسازی می‌اندازد، اغلب پس از کامل شدن دست‌دادن TCP. این جزئیات بعداً مهم می‌شود، چون یعنی گزارش کارخواه پس از برپا شدن سوکت متوقف می‌شود.

پوشاندن جریان دو نقطه شکست می‌سازد

پوشش TLS مانند stunnel شکل مورد انتظار را بازمی‌گرداند: کارخواه به شنونده محلی وصل می‌شود، پوشش یک نشست واقعی TLS به سرور روی 443 باز می‌کند، و پوشش دومی روی سرور بایت‌های رمزگشایی‌شده را به سرویس VPN می‌فرستد. نشست بیرونی اکنون مانند هر پیوند HTTPS دیگری دیده می‌شود. سرویس VPN روی سرور باید فقط روی loopback گوش دهد، چون هیچ چیز بیرون پوشش نیازی به رسیدن به آن ندارد.

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

مسیر به سوی پوشش همان تله است

به‌محض بالا آمدن تونل، مسیر پیش‌فرض به درون آن اشاره می‌کند، و نشست بیرونی TLS مسیری می‌خواهد که به تونلی که آن را حمل می‌کند وارد نشود. کارخواه معمولی VPN نشانی‌ای را که شماره می‌گیرد محافظت می‌کند؛ کارخواه پوشیده loopback خودش را شماره می‌گیرد، پس نشانی مقصد پوشش برای آن محافظت ناپیداست.

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

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

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

پیش از هر تغییر، زمان‌بندی را بخوانید

نشستی که هر بار پس از همان بازه می‌میرد امضای یک سیاست است نه شکست رمزنگاری، و محدودیت‌های جریان بلندمدت دقیقاً همین الگو را می‌سازند. پیوندی که بی‌درنگ پس از دست‌دادن بازنشانی می‌شود به پیشکاری اشاره دارد که زنجیره گواهی را نپسندیده است.

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

رفتار مشاهده‌شده را بنویسید: نشست چقدر دوام آورد، سوکت باز شد یا نه، پوشش دست‌دادنی ثبت کرد یا نه. هر یک از این‌ها آزمون بعدی را تنگ‌تر می‌کند.

هر بار یک متغیر را بیازمایید

نخست UDP را بررسی کنید، چون بعضی شبکه‌ها آن را کاملاً می‌اندازند و شکست UDP درباره 443 چیزی نمی‌گوید. سپس TCP 443 را بدون پوشش امتحان کنید، و بعد پوشش را روی 443. در هر گام گزارش کارخواه را بخوانید و به‌محض تغییر رفتار متوقف شوید.

در هر تلاش یک عنصر را عوض کنید. پورت تازه، پوشش تازه و رمز تازه در یک دور شما را ناتوان می‌گذارد از گفتن اینکه کدام یک از سه تا مهم بود.