OpenVPN و HTTPS روی پورت 443: شنونده از آن کیست؟
TCP و UDP 443 دو سوکت جداگانه‌اند. اشتراک یک شنونده TCP نیاز به یک مالک دارد، و اشتراک پورت OpenVPN ترتیبی محدود است، نه ترفند پروکسی.
دو سرویس می‌توانند هر دو روی پورت 443 پاسخ دهند بدون آنکه هرگز رقابت کنند، زیرا شنونده بر اساس ترکیب انتقال، نشانی و پورت تعیین می‌شود، نه فقط بر اساس شماره. یک وب‌سرور و OpenVPN را روی یک ماشین بگذارید، و تنها پرسشی که شایسته پاسخ اول است این است که هر فرایند کدام سوکت را از هسته می‌خواهد. آن فهرست را پیش از ویرایش پیکربندی بنویسید، و بیشتر خطاهای «نشانی در حال استفاده است» خودشان را توضیح می‌دهند. هر چیز پس از فهرست، انتخابی است میان شنونده UDP، سوکت TCP مشترک، یا یک بخش جلویی که بر اساس پروتکل مسیریابی می‌کند.
با سوکتی آغاز کنید که هر فرایند می‌خواهد
bind بر پایه همان سه‌گانه موفق یا ناموفق می‌شود، پس دو دیمن تنها زمانی برخورد می‌کنند که هر سه بخش یکی شوند. به همین دلیل یک وب‌سایت روی TCP 443 به‌طور نامحدود در کنار شنونده OpenVPN روی UDP 443 زندگی می‌کند، و به همین دلیل جابه‌جا کردن یکی از آن‌ها به نشانی محلی دوم روی همان میزبان هم بحث را پایان می‌دهد. شنونده‌های زنده را بخوانید، نه فایل‌هایی را که قرار بود آن‌ها را بسازند، چون یک include کهنه یا یک فایل unit فراموش‌شده از ویرایشی که یادتان هست انجام داده‌اید بیشتر عمر می‌کند.
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
ss -lntup را به‌عنوان root اجرا کنید و هر سطری را که از 443 یاد می‌کند بخوانید، از جمله ورودی‌های IPv6. یک شنونده v6 با کارت وحشی معمولاً ترافیک v4 را هم می‌پذیرد، و این‌گونه یک شنونده که فراموشش کرده‌اید پس از تغییر فایلی که فکر می‌کردید مسئول است، پورت را اشغال نگه می‌دارد. اگر نام یک فرایند غافلگیرتان کرد، پیش از دست زدن به هر چیزی خروجی را با ss -lntup 'sport = :443' محدود کنید.
وقتی شبکه اجازه می‌دهد تونل را به UDP ببرید
یک شنونده UDP از برخورد کاملاً دوری می‌کند و معمولاً کوتاه‌ترین تعمیر است، چون هیچ سوکتی مشترک نیست و هیچ محصول اضافه‌ای به مسیر نمی‌پیوندد. اما رایگان نیست. برخی شبکه‌های مشتری UDP 443 را بدون فرستادن reset دور می‌ریزند، بنابراین تونل به‌جای شکست در bind از برپا شدن بازمی‌ماند، و کاربر از کار افتادن VPN را بدون خطایی برای خواندن گزارش می‌کند. شنونده UDP از راه‌اندازی دوبارهٔ لایه وب هم جان سالم به در می‌برد، که روی ماشینی که سایتش مکرراً دوباره منتشر می‌شود اهمیت دارد. از همان شبکه‌ای آزمایش کنید که کاربران در آن نشسته‌اند، چون یک شل روی سرور تنها ثابت می‌کند که سرور به خودش می‌رسد.
انتقال را هم‌زمان در پیکربندی سرور و در نمایهٔ مشتری تغییر دهید. نمایه‌ای که هنوز TCP می‌خواهد در برابر شنونده‌ای که فقط UDP دارد در چرخهٔ اتصال دوباره دور می‌زند، و این تا وقتی دو فایل را مقایسه نکنید مانند یک نقص شبکه دیده می‌شود.
بگذارید فرایند VPN مالک TCP 443 باشد و بقیه را هدایت کنید
Community OpenVPN در حالت سرور TCP نخستین بایت‌های یک اتصال ورودی را می‌خواند و هر چیزی را که پروتکل خودش نیست به یک بک‌اند HTTPS هدایت می‌کند، و دستور port-share برای همین است. بک‌اند یک وب‌سرور معمولی با TLS فعال است که در آن دستور با میزبان و پورت نام‌گذاری می‌شود، نه با URL.
port-share 10.0.0.5 8080
روی ماشینی که سایت نشانی خصوصی دومی دارد، آن خط ترافیک غیر VPN را به 10.0.0.5:8080 می‌فرستد، پس میزبان مجازی HTTPS باید آنجا bind شود و فایروال باید گام محلی را مجاز کند. وب‌سرور باید خودش TLS را پایان دهد، چون بایت‌هایی که می‌رسند همان دست‌دهی اصلی مرورگرند و چیزی در میانه آن‌ها را رمزگشایی نکرده است. دستور را به یک شنونده HTTP ساده نشانه بگیرید و مرورگر خطای متد نامعتبر می‌گیرد، که مانند سایتی خراب خوانده می‌شود نه بک‌اندی بدجا. این دستور فقط در حالت سرور TCP وجود دارد، و شنونده UDP جریانی برای بررسی ندارد.
چون فرایند VPN هر اتصالی را می‌پذیرد، برنامه وب درخواست هدایت‌شده را از یکی از نشانی‌های خود میزبان می‌بیند، نه از بازدیدکننده. هر چیزی که نشانی واقعی مشتری را لازم دارد به پشتیبانی پروتکل PROXY در بک‌اند یا به بخش جلویی که آن را می‌افزاید وابسته است. جابه‌جا کردن بک‌اند به نشانی محلی دیگر نشانی بازدیدکننده را بازنمی‌گرداند؛ فقط این را تغییر می‌دهد که سایت کدام یک از نشانی‌های میزبان را ثبت می‌کند. این محدودیت را پیش از آنکه گزارش تحلیلی پرسش را مطرح کند در یادداشت‌های استقرار بنویسید.
پروکسی معکوس ابزار نادرستی است؛ مسیریاب لایه چهارم نه
پروکسی معکوس HTTP برای خواندن درخواست‌ها TLS را پایان می‌دهد، یعنی نمی‌تواند جریان OpenVPN را دست‌نخورده عبور دهد. مسیریاب لایه چهارم که بر اساس SNI یا بررسی بستهٔ اول هدایت می‌کند می‌تواند جلوی هر دو بایستد، به شرط آنکه نشستی را که VPN به آن وابسته است پایان ندهد. دو دستگاه در یک نمودار شبیه هم به نظر می‌رسند و در سوکت رفتاری کاملاً متفاوت دارند.
Access Server تجاری تنظیمات اشتراک پورت خودش را دارد، و آن‌ها یک‌به‌یک با دستور جامعه منطبق نمی‌شوند. پیش از اقتباس راهنمایی که برای آن یکی نوشته شده، محصول و نسخه را مشخص کنید. تنظیم کپی‌شده‌ای که بی‌صدا نادیده گرفته می‌شود از نبود تنظیم بدتر است، چون فهرست شنونده‌ها پس از آن هنوز باورپذیر به نظر می‌رسد.
وب‌سایت و تونل را به‌عنوان دو مسیر جداگانه آزمایش کنید
سایت را بارگذاری کنید و تونل را وصل کنید، سپس فهرست شنونده‌ها را دوباره بخوانید تا ببینید اکنون کدام فرایند مالک 443 است. صفحه‌ای که بارگذاری می‌شود چیزی دربارهٔ VPN ثابت نمی‌کند، و تونلی که وصل می‌شود چیزی دربارهٔ سایت ثابت نمی‌کند، هرچند هر دو از یک شماره استفاده می‌کنند. سه فرمان زیر به ترتیب سوکت مشترک، مسیر وب و سرویس VPN را بررسی می‌کنند.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
نشانی مشتری را در گزارش دسترسی بک‌اند با همان در گزارش VPN برای همان لحظه مقایسه کنید. اگر سایت هر بازدیدکننده را به‌عنوان خود میزبان ثبت کند، هدایت کار می‌کند و رسیدگی به نشانی نه. اگر هر دو گزارش خاموش بمانند، بخش جلویی هرگز اتصال را تحویل نداده است. در هر حال فهرست شنونده‌ها تعیین می‌کند چه کسی سوکت را می‌پذیرد، و این همان واقعیتی است که باید پیش از تغییر فایل دیگری تأیید شود.
آن نقشهٔ شنونده‌ها را کنار پیکربندی بگذارید تا نفر بعدی که به 443 دست می‌زند بداند کدام فرایند می‌پذیرد و پروتکل دیگر کجا رفته است. مالکیت را پس از تغییر تأیید کنید، نه اینکه به آنچه ویرایش قرار بود انجام دهد اعتماد کنید.