UFW به‌محض بالا آمدن تونل، سرور DNS وی‌پی‌ان را رها می‌کند
سیاست منع پیش‌فرض UFW رابط تونل را هم می‌پوشاند. ترافیک را بر اساس جهت مرتب کنید، حل‌کننده تزریق‌شده را روی tun0 مجاز کنید و سپس مسیر بیرونی را باز کنید.
نام‌ها همان لحظه‌ای که VPN وصل می‌شود از حل شدن بازمی‌ایستند، در حالی که پینگ به یک نشانی عمومی هنوز پاسخ می‌دهد و وضعیت فایروال چیزی که اشتباه به نظر برسد نشان نمی‌دهد. در سیاست هیچ چیز عوض نشده است؛ آنچه عوض شده این است که رابط تازه‌ای ظاهر شده و منع پیش‌فرض از نخستین بسته آن را پوشش می‌دهد. UFW بر اساس جهت و رابط تصمیم می‌گیرد، بنابراین قاعده‌ای که برای پیوند بی‌سیم نوشته شده درباره ترافیکی که از تونل بیرون می‌رود چیزی نمی‌گوید. تعمیر، مشتی قاعده باریک است که به ترتیبی مشخص اعمال می‌شوند.
نشانه فقط پس از بالا آمدن تونل پدیدار می‌شود
سیاست منع پیش‌فرض دقیقاً همان کاری را می‌کند که به آن گفته شده است: هر چیز بدون قاعده منطبق رد می‌شود، روی هر رابطی که وجود دارد. هنگام نوشتن قواعد تونل وجود نداشت، پس هیچ‌یک از آن‌ها نمی‌تواند آن را بگیرد، و منعی که همیشه آن‌جا بود اکنون بر حل نام‌ها اعمال می‌شود. ترافیک مستقیم به یک نشانی صریح هنوز می‌تواند کار کند وقتی اجازه گسترده‌تری آن را بپوشاند، و به همین دلیل پینگ به یک حل‌کننده عمومی موفق می‌شود در حالی که جست‌وجوی نام شکست می‌خورد. شکاف، قاعده‌ای برای رابطی است که سیاست هرگز ندیده است.
این همچنین توضیح می‌دهد چرا خرابی کاملاً برمی‌گردد: تونل را پایین بیاورید و نام‌ها دوباره حل می‌شوند، چون پرس‌وجو به رابطی بازمی‌گردد که قاعده دارد. سیاستی که تنها وقتی تونل بالاست شکست می‌خورد مشکل DNS نیست، و تنظیم خود حل‌کننده در اینجا بیشترین وقت را هدر می‌دهد. پیش از خواندن پیکربندی حل‌کننده، فهرست رابط‌ها را بخوانید.
سه جهت، سه مجموعه قاعده متفاوت
یک نشست قواعدی را در بیش از یک جهت لمس می‌کند، و تونل به تقریباً همه آن‌ها یک رابط دوم اضافه می‌کند. مرتب کردن ترافیک نخست بر اساس جهت و رابط، بقیه را مکانیکی می‌کند، چون هر ردیف زیر به قاعده خودش در جای خودش نیاز دارد. مثال‌ها از tun0 و استخری از 10.8.0.0/24 استفاده می‌کنند، پس نام‌ها و بازه‌ها را با آنچه از خروجی خود کارخواه می‌آید عوض کنید.
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
دو ردیف اغلب اشتباه گرفته می‌شوند چون هر دو از تونل حرف می‌زنند. قاعده حل‌کننده ترافیکی را مجاز می‌کند که کارخواه به تونل می‌فرستد، در حالی که قاعده SSH ترافیکی را مجاز می‌کند که سرور از آن‌جا می‌گیرد؛ آن‌ها روی ماشین‌های متفاوت زندگی می‌کنند و مستقل شکست می‌خورند. ردیفی که بیشتر از همه فراموش می‌شود دومی است، چون کارخواه تا زمانی که ترافیکش به نشانی عمومی سرور مجاز نشود اصلاً نمی‌تواند تونل بسازد. از بالا به پایین کار کنید و هر شکست یک علت محتمل دارد.
حل‌کننده تزریق‌شده به قاعده خودش نیاز دارد
اینکه تونل DNS را حمل می‌کند به آنچه سرور می‌فرستد بستگی دارد. سروری که گزینه حل‌کننده را تزریق می‌کند نشانی خصوصی را در پیکربندی کارخواه نصب می‌کند، و آن نشانی فقط از راه تونل مسیریابی‌پذیر است. اگر سرور چیزی تزریق نکند، کارخواه همان حل‌کننده‌ای را که داشت نگه می‌دارد و قواعد زیر چیزی برای مجاز کردن ندارند. پیش از نوشتن هر چیز، وضعیت تزریق‌شده و نتیجه پرس‌وجوی کنونی را بررسی کنید:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedخروجی وضعیت حل‌کننده در حال استفاده و پیوندی را که به آن بسته شده نام می‌برد، و جست‌وجوی مسیر پشت آن نشان می‌دهد کدام رابط پرس‌وجویی به آن نشانی را حمل می‌کند. وقتی حل‌کننده روی پیوند دیگری است، مشکل پیش‌تر از فایروال است و هیچ قاعده‌ای کمکی نمی‌کند. وقتی هر دو درباره تونل توافق دارند، دو قاعده لازم است، چون UDP بیشتر پرس‌وجوها را حمل می‌کند و TCP وقتی پاسخ کوتاه می‌شود کار را می‌گیرد. هر دو مقدار را ثبت کنید، چون همان‌هایی هستند که قواعد نامشان را می‌برند:
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'مسیر بیرونی را پیش از درونی باز کنید
کارخواه باید پیش از آن‌که تونلی وجود داشته باشد به نشانی عمومی سرور برسد، پس قاعده آن روی پیوند فیزیکی می‌نشیند و باید نخست سر جایش باشد. سیاستی که حل‌کننده را مجاز می‌کند اما سرور را فراموش می‌کند کارخواه را کاملاً ناتوان از ساختن تونل رها می‌کند، و این نشانه معمولاً به گردن یک kill switch می‌افتد. سپس خدماتی را که واقعاً از راه تونل می‌خواستید مجاز کنید، هر بار یک قاعده باریک، به‌جای باز کردن یک‌جای رابط. قواعد باریک همان دلیلی هستند که منع می‌تواند سر جایش بماند.
sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'ترتیب هنگام آزمایش مهم است، چون قاعده نخست همان چیزی است که اصلاً اجازه بالا آمدن تونل را می‌دهد. آن را اضافه کنید، وصل شوید و پیش از افزودن قاعده سرویس مطمئن شوید تونل بالاست، چون انجام هر دو با هم یعنی شکست هیچ چیزی درباره اینکه کدام نیمه غلط است نمی‌گوید. نشانی مستندات بالا را با نقطه‌ای که کارخواه برای استفاده از آن پیکربندی شده عوض کنید.
سمت کارخواه را با قطع کردن عمدی اتصال تمام کنید. منع باید هنوز ترافیکی را که عمداً کنار گذاشتید رد کند، چون حل‌کننده‌ای که وقتی تونل بالاست پاسخ می‌دهد تنها نیمی از سیاستی را پوشش می‌دهد که در شک به منع حکم می‌کند.
کارخواهی که وصل می‌شود هنوز پذیرفته نشده است
سرور جهت خودش را برای سنجیدن دارد، و کارخواهی که دست‌دادن را کامل می‌کند تا زمانی که سرور او را نپذیرد باز هم به چیزی که روی سرور اجرا می‌شود نمی‌رسد. قاعده شنونده عمومی فقط اجازه وجود تونل را می‌دهد؛ ترافیک تونل را داخل نمی‌آورد. روی سرور این دو قاعده به‌علاوه یک بررسی است که سرویس واقعاً گوش می‌دهد:
sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'استخر در قاعده باید برابر بازه‌ای باشد که سرور تخصیص می‌دهد، و شماره تونل باید با آنچه سرور ساخته مطابق باشد، چون قاعده برای رابطی متفاوت از نبودِ قاعده قابل تشخیص نیست. limit برای درگاه مدیریتی عمدی است، چون اتصال‌های تکراری را محدود می‌کند به‌جای پذیرش بی‌حد آن‌ها. بررسی شنونده درگاه بسته را از بسته افتاده جدا می‌کند، که از دید کارخواه یکسان به نظر می‌رسند. قواعد شماره‌دار هم تمام تصویر نیستند: قواعد before در UFW و هر خط nftables که دستی نوشته شده زودتر منطبق می‌شوند و هنوز می‌توانند بسته‌ای را رد کنند که فهرست ظاهراً مجاز می‌داند.