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

مدیر و بک‌اند را پیدا کنید

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

بک‌اند به اندازه جبهه اهمیت دارد. نصب firewalld می‌تواند بسته به نسخه و پیکربندی nftables یا بک‌اند قدیمی iptables را هدایت کند، و هر دو خروجی بررسی متفاوتی تولید می‌کنند. پیش از مقایسه سیستم خود با هر راهنما، توزیع، نسخه و بک‌اند را در تیکت بنویسید.

جهت و رابط را تطبیق دهید

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

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

مالکان قواعد را هماهنگ نگه دارید

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

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

رفع را بدون از دست دادن قفل بررسی کنید

وضعیت اعمال‌شده را با مدیری که مالک آن است بررسی کنید، با دستورهایی که با بک‌اند ثبت‌شده شما مطابقت دارند. فهرست زیر فرض می‌کند firewalld مسئول است؛ به جای اجرای همه، معادل nftables یا ufw را جایگزین کنید. مخلوط کردن ابزارها در یک نشست همان چیزی است که ماشین را با دو مجموعه قواعد متناقض رها می‌کند.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=trusted --list-all
sudo nft list ruleset | head -40

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

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

مقالات مرتبط