OpenVPN Access Server در واقع روی کدام پورت‌ها گوش می‌دهد؟
فهرست سوکت‌های یک میزبان Access Server را مرور کنید: شنونده‌های پیش‌فرض را بشناسید، loopback را از پورت‌های منتشرشده جدا کنید و پیش از بستن پورت، فورواردینگ را بررسی کنید.
شما ss -lntup را روی یک میزبان Access Server اجرا می‌کنید و فهرستی دو برابر حد انتظار می‌گیرید. نیمی از ورودی‌ها پورت‌هایی به شکل دیمن هستند که کسی در زمان راه‌اندازی به آن‌ها اشاره نکرده است. واکنش طبیعی بستن هر چیزی است که 443 یا 1194 نیست، و این‌گونه است که مردم پورتال مشتری خودشان را خراب می‌کنند.
Access Server یک شنونده نیست. یک سرویس VPN، یک سرویس وب و یک عضو خوشه است و بسته به شمار دیمن‌های TCP که پیکربندی کرده‌اید می‌تواند پورت‌های اضافی مخصوص دیمن و تغییرمسیرهای فایروال بسازد.
فهرست را به ترتیب مرور کنید: سوکت‌ها را بخوانید، آشناها را نگاشت کنید، بقیه را بر اساس مالک و اتصال دسته‌بندی کنید و سپس بررسی کنید چه چیزی واقعاً آن‌ها را منتشر می‌کند.
با یک فرمان فقط-خواندنی شروع کنید
sudo ss -lntup برای هر سوکت شنوا، پروتکل انتقال، نشانی محلی، پورت و فرایند مالک را به شما می‌دهد. پرچم‌ها مهم‌اند: -l گوش دادن، -n عددی، -t TCP، -u UDP، -p فرایند. بدون root سوکت‌ها را می‌گیرید اما نام فرایندها را نه، و دقیقاً همان ستون برای دسته‌بندی لازم است.
پیش از هر قضاوتی برای هر ردیف چهار فیلد ثبت کنید: پروتکل، نشانی اتصال، پورت و فرمان. نسخه Access Server و شمار دیمن‌های پیکربندی‌شده را کنار این فهرست نگه دارید، چون هر دو انتظار را تغییر می‌دهند.
دو ردیف که یکسان به نظر می‌رسند یکسان نیستند. TCP و UDP روی یک شماره دو سوکت جدا با مواجهه جدا هستند، و 0.0.0.0 و :: دو اتصال جدا برای دو خانواده نشانی جدا هستند. سرویسی که فقط به 127.0.0.1 متصل است از میزبان دیگر مستقیماً در دسترس نیست، هرچند تغییرمسیر محلی هنوز می‌تواند آن را منتشر کند.
شنونده‌هایی که باید بشناسید
این پیش‌فرض‌ها بیشتر استقرارها را پوشش می‌دهند و خط پایه‌ای برای مقایسه به شما می‌دهند. آن‌ها پیش‌فرض‌اند، نه فهرست کامل مجاز.
| Socket | Role to confirm |
|---|---|
| UDP 1194 | OpenVPN UDP tunnel listener |
| TCP 443 | OpenVPN TCP listener, optionally forwarded to the web service |
| TCP 943 | Admin and client web interfaces, and cluster control in Access Server 3.0 and later |
| TCP 945 | Cluster control in older configurations that predate the move to 943 |
هر چیز فراتر از این به توضیح نیاز دارد، نه به فرض. اغلب شنونده‌های فقط-محلی خواهید دید که به اجزایی تعلق دارند که محصول برای خودش نصب می‌کند. آن‌ها را با PID و پیکربندی سرویس تأیید کنید نه با شماره پورتی که به یاد می‌آورید، و پورت ناشناس را فقط به دلیل ناآشنایی خصمانه نپندارید.
سوکت بیرون از جفت آشنا هم به‌طور خودکار باقی‌مانده نیست. وقتی چند دیمن TCP پیکربندی شده باشد، Access Server برای هر دیمن شنونده می‌سازد و ترافیک را به آن‌ها تغییرمسیر می‌دهد، پس شمار و مقادیر پورتشان از آن پیکربندی پیروی می‌کند.
پیش از بستن هر چیزی دسته‌بندی کنید
برای هر ردیف نامطمئن، به سه پرسش به این ترتیب پاسخ دهید.
- مالک و هدف. PID را با یک واحد یا فرایند تطبیق دهید و پیکربندی آن سرویس را بخوانید. اگر نمی‌توانید مالک را نام ببرید، آماده نیستید درباره سوکت تصمیمی بگیرید.
- دامنه اتصال. حلقه برگشتی نسبت به فضای نام محلی است. اتصال wildcard فقط وقتی در دسترس است که مسیریابی، فیلتر میزبان و هر قاعده سطح ابر اجازه دهد، پس نشانی اتصال لازم است اما کافی نیست. IPv4 و IPv6 را دو تصمیم جدا بررسی کنید.
- مسیر منتشرشده. به دنبال فورواردینگ سرویس، تغییرمسیرهای مخصوص دیمن، پروکسی خارجی و سیاست مؤثر فایروال باشید. این همان گامی است که مردم از آن می‌گذرند و همان چیزی است که یک پورت بک‌اند بی‌ضرر به‌نظررسنده را به مسیری اداری و در دسترس تبدیل می‌کند.
همان پرسش از بیرون میزبان متفاوت خوانده می‌شود. پورتی بدون قاعده فایروال میزبان هنوز می‌تواند توسط گروه امنیتی ابری بسته شود، و پورتی با قاعده سهل‌گیرانه میزبان ممکن است دسترسی‌ناپذیر باشد زیرا چیزی به آن مسیریابی نمی‌کند. پیش از نوشتن نتیجه فهرست، هر دو سر را ببینید.
جایی که مسیر منتشرشده با فهرست سوکت‌ها تفاوت دارد
مستندات خود Access Server همان موردی را پوشش می‌دهد که بیشترین سردرگمی را می‌سازد: وقتی چند دیمن TCP اجرا می‌شود، پورت جلویی به پورت‌های مخصوص دیمن فوروارد می‌کند و چیدمان قابل مشاهده دیگر با فهرست سوکت‌ها نمی‌خواند. آموزش فیلترکردن رابط وب آن قواعد و دلیل اینکه فیلتری که فقط برای پورت آشکار نوشته شده است می‌تواند مسیر تغییرمسیریافته را کاملاً از دست بدهد را توضیح می‌دهد.
کنترل خوشه دومین جایی است که نسخه اهمیت دارد. در 3.0 و جدیدتر 943 را به اشتراک می‌گذارد؛ پیکربندی‌های خوشه قدیمی‌تر از 945 استفاده می‌کردند. باز کردن یا بستن یکی از آن‌ها بدون بررسی نسخه، فهرستی مرتب اما نادرست تولید می‌کند.
پس سطح قابل مشاهده از بیرون اجتماع سه چیز است: سوکت‌های شنوا، قواعد فورواردینگ که آن‌ها را دوباره منتشر می‌کنند، و کنترل‌های شبکه پیش از میزبان. هر فهرستی که فقط اولی را ثبت کند ناقص است، و هر تغییری که فقط اولی را در نظر بگیرد یا مسیری را باز می‌گذارد یا سرویسی را قطع می‌کند.
پس از هر تغییر تأیید کنید
تنظیمات شنونده را از طریق مالک پیکربندی پشتیبانی‌شده تغییر دهید و هنگام انجام این کار یک کنسول بازیابی باز نگه دارید. از دست دادن دسترسی اداری به رابط وب روی میزبان دور از طریق VPNی که همین حالا غیرفعال کردید قابل بازیابی نیست.
سپس چهار چیزی را که یک استقرار معمولاً نیاز دارد اعتبارسنجی کنید: یک کلاینت VPN متصل می‌شود، پورتال مشتری بارگذاری می‌شود، دسترسی اداری کار می‌کند و ارتباط خوشه اگر بیش از یک گره اجرا می‌کنید همچنان کار می‌کند. آزمون فقط-VPN راحت قبول می‌شود در حالی که پورتال خراب است.
با نوشتن مسیر مجاز هر سرویس تمام کنید: کدام سوکت، کدام اتصال، کدام قاعده فورواردینگ، کدام کنترل شبکه. همان سند خروجی امنیتی سودمند است. کمینه شمار سوکت‌ها نیست، و بازنشانی انبوهی که شنونده‌هایی را می‌بندد که هیچ‌کس شناسایی‌شان را تمام نکرده نیز نیست.