UFW می‌گوید پروفایلی هم‌خوان با OpenSSH پیدا نمی‌کند و جست‌وجوی علت مستقیماً به سرور SSH می‌رسد. این جهت اشتباهی است: پیام درباره یک تعریف نام‌دار فایروال است و چیزی درباره نصب، اجرا یا گوش دادن sshd نمی‌گوید. پروفایل برنامه UFW فهرستی از پورت‌ها و پروتکل‌ها با یک برچسب است. خواندن تعریف یک فرمان می‌خواهد و معمولاً پژوهش را پایان می‌دهد.

گام 1: نام‌هایی را که UFW واقعاً می‌شناسد فهرست کنید

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

ufw app list
ufw app info OpenSSH

فهرست در نصب پیش‌فرض کوتاه است و نام‌ها نام بسته نیستند. ممکن است پروفایلی به نام OpenSSH نباشد در حالی که بسته openssh-server نصب است، و برعکسش هم ممکن است. دقیقاً همان نامی را به کار ببرید که فهرست چاپ می‌کند؛ نام پروفایل VPN یا یک راه‌انداز میزکار با املای مشابه پروفایل برنامه UFW نیست. اگر نامی که می‌خواهید نیست، همان یافته است و گام بعدی نگاه کردن به این است که چه چیزی باید آن را تأمین کند.

گام 2: تعریف را بخوانید، نه برچسب را

پروفایل یک فایل به سبک INI زیر /etc/ufw/applications.d است، با نام، عنوان، توضیح و یک فیلد پورت‌ها. فیلد پورت‌ها می‌تواند چند پورت و انتقال را فهرست کند، پس برچسب کمتر از تعریف به شما می‌گوید. راهنمای UFW این فیلدها و عملیات به‌روزرسانی برنامه‌ها را مستند می‌کند. فایل را بخوانید، به‌جای آنکه فرض کنید نام یعنی یک پورت آشنا.

cat /etc/ufw/applications.d/openssh-server
ufw app info OpenSSH

تعریفی که 22/tcp دارد، پورت TCP شماره 22 را توصیف می‌کند و بس. ثابت نمی‌کند که سرویس‌دهنده این ماشین آنجا گوش می‌دهد و پورت دومی را که بعداً اضافه کردید پوشش نمی‌دهد. اگر سرویس‌دهنده جای دیگری اجرا می‌شود، پروفایل مجوز اشتباه است حتی اگر نامش با محصول بخواند. پیش از مجاز کردن هر یک از این دو، شنونده را با تعریف مقایسه کنید.

ss -ltnp 'sport = :22'

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

گام 3: پروفایل را از سرویس در حال اجرا جدا کنید

مجاز کردن یک پروفایل نام‌دار سرویس را نصب، اجرا یا پیکربندی نمی‌کند، و سرویس در حال اجرا برای دسترس‌پذیر بودن به پروفایل بسته‌بندی‌شده نیاز ندارد. این‌ها تصمیم‌های جدایی هستند که ابزارهای متفاوتی مالک آن‌اند: مدیر بسته، مدیر سرویس و فایروال. یکی دانستن آن‌ها همان روشی است که مردم یک سرور ناخواسته نصب می‌کنند تا نامی نمادین پدیدار شود.

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

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

گام 4: پیش از بارگذاری دوباره فایروال راهی برای بازگشت نگه دارید

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

ufw status verbose
ufw allow 22/tcp
ufw app update OpenSSH

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

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

مقالات مرتبط