کلید قطع UFW اتصال VPN شما را مسدود می‌کند؟ به همتا اجازه دهید

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

چرا یک اجازه روی tun0 در ابتدا با هیچ چیز مطابقت ندارد

tun0 را کلاینت پس از وجود یک نشست می‌سازد. دیتاگرام‌هایی که آن نشست را می‌سازند بسته‌های UDP معمولی هستند که به ارائه‌دهنده در درگاه 1194 فرستاده می‌شوند و با نشانی مبدأ فیزیکی از طریق wlan0 یا eth0 خارج می‌شوند. allow out on tun0 فقط با ترافیکی مطابقت دارد که رابط خروجی آن tun0 است، پس در طول دست‌دادن اصلاً با هیچ چیز مطابقت ندارد.

قرار دهید default deny outgoing را روی آن، و بسته‌های بیرونی پیش از آنکه رابط اصلاً ظاهر شود دور انداخته می‌شوند. کلاینت دوباره تلاش می‌کند، زمان‌سنجی می‌شود و شکست TLS یا دست‌دادن را گزارش می‌دهد، که مردم را به جستجو در گواهی‌ها و MTU می‌فرستد در حالی که دیوار آتش بی‌صدا اتصال را می‌خورد. قاعده‌ای که قرار بود ترافیک شما را مهار کند مانع مهار همان ترافیک می‌شود.

اصلاح رفلکسی نشت را دائمی می‌کند. sudo ufw allow out on wlan0 ، یا برگرداندن پیش‌فرض به اجازه، تونل را بالا می‌آورد و دستگاه را بدون کلید قطع رها می‌کند: بار بعد که تونل بیفتد، همه چیز از طریق آداپتور فیزیکی از سر گرفته می‌شود. یک بعدازظهر را دقیقاً روی همان دو تغییر از دست دادم تا فهمیدم کدام بسته را واقعاً فیلتر می‌کنم.

دو مجموعه بسته به چه چیزی نیاز دارند

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

sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow out to 203.0.113.10 port 443 proto tcp comment 'tcp fallback'

نشانی و درگاه را با آن‌های پروفایل خودتان جایگزین کنید. همتاهای WireGuard معمولاً روی 51820/udp پاسخ می‌دهند؛ پروفایل‌های OpenVPN که از TCP 443 می‌گذرند به جای آن به این درگاه نیاز دارند. جزئیات فرق می‌کند، شکل نه: هر دو قاعده باریک‌اند و با هم تنها مقصدهایی را تعریف می‌کنند که دستگاه وقتی تونل پایین است می‌تواند به آن‌ها برسد.

ترتیب افسانهٔ دوم است. با iptables خام زنجیره را از بالا به پایین می‌خوانید و استدلال می‌کنید کدام قاعده برنده می‌شود. ufw پوشش نازکی دور فهرستی که تایپ کردید نیست؛ قواعد شما را به زنجیره‌های خودش کامپایل می‌کند و نقاط درج را انتخاب می‌کند. ufw status آن‌ها را به ترتیب ufw چاپ می‌کند، نه ترتیب شما. وقتی قاعده‌ای نادیده گرفته‌شده به نظر می‌رسد، مقایسه کنید ufw show added را با مجموعهٔ کامپایل‌شده از iptables -S | grep ufw پیش از بازنویسی هر چیزی.

استثنا باید به عرض یک نشانی بماند

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

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

حل نام سطر خودش را می‌طلبد. جستجو پیش از وجود تونل، از روی رابط فیزیکی انجام می‌شود، پس یک سیاست سختگیرانهٔ رد خروجی می‌تواند کلاینت را ناتوان از یافتن سرور خودش بگذارد. درگاه 53 را به نشانی ریزالور خود اجازه دهید، یا یک بار حل کنید و نشانی را در پروفایل تثبیت کنید. اجازه دادن DNS روی هر رابط یک تصمیم است، نه پیش‌فرض.

سیاست را پیش از آنکه تونل لازم شود بسازید

ufw enable کل سیاست را یک‌جا اعمال می‌کند و زنجیره‌هایش را دوباره بارگذاری می‌کند، و تغییر یک سیاست پیش‌فرض روی دیوار آتش در حال اجرا آن‌ها را نیز دوباره بارگذاری می‌کند. راهنمای ufw هشدار می‌دهد که این می‌تواند اتصال‌های موجود مثل SSH را بیندازد. پس دستورها به این ترتیب می‌آیند، با قاعدهٔ SSH پیش از فعال‌سازی و یک نشست کنسول باز:

sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

ufw reset عمداً بیرون از آن بلوک گذاشته شده است. هر قاعده‌ای را حذف می‌کند و دیوار آتش را غیرفعال می‌کند، و روی میزبان دور، فعال‌سازی بعدی همان چیزی است که نشست شما را می‌اندازد. اگر واقعاً بازنشانی کردید، قاعدهٔ SSH را بیفزایید و پیش از ادامه، راه دومی برای بازگشت از طریق کنسول تأیید کنید.

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

حالت مسدود را آزمایش کنید و لغو را نگه دارید

کلید قطع آزمایش‌نشده یک حدس است. کلاینت را عمداً قطع کنید و سعی کنید صفحه‌ای بارگذاری کنید: باید شکست بخورد. دوباره وصل شوید و باید بدون دست زدن به هیچ قاعده‌ای بازیابی شود. sudo ufw status verbose پیش‌فرض‌ها و وضعیت ثبت را تأیید می‌کند، و ufw status numbered نشان می‌دهد کدام قاعدهٔ آزمایشی را وقتی از هدفش بیشتر عمر کرد حذف کنید.

اسکریپت معکوس را کنار اسکریپت رو به جلو نگه دارید. دستگاهی با رد خروجی و تونل مرده نمی‌تواند تعمیر خودش را دانلود کند، پس لغو باید روی دیسک باشد و از کنسول خواندنی باشد:

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

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