Аварійний вимикач 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 є названий виняток, увімкнення відбулося після дозволів, а витягування тунелю вбиває звичайний трафік, не вбиваючи клієнт назавжди.