UFW скидає DNS-сервер VPN, щойно піднімається тунель
Політика заборони за замовчуванням у UFW охоплює й інтерфейс тунелю. Упорядкуйте трафік за напрямком, дозвольте проштовхнутий резолвер на tun0 і потім відкрийте зовнішній шлях.
Імена перестають розв'язуватися в той момент, коли підключається VPN, хоча ping до публічної адреси ще відповідає, а стан брандмауера не показує нічого, що виглядало б неправильно. У політиці нічого не змінилося; змінилося те, що з'явився новий інтерфейс, і заборона за замовчуванням покриває його з першого пакета. UFW вирішує за напрямком та інтерфейсом, тому правило, написане для бездротового з'єднання, нічого не каже про трафік, що виходить із тунелю. Виправлення — це жменя вузьких правил, застосованих у певному порядку.
Симптом з'являється лише після того, як тунель піднято
Політика заборони за замовчуванням робить рівно те, що їй сказано: усе без відповідного правила відхиляється, на кожному наявному інтерфейсі. Тунеля не було, коли писалися правила, тому жодне з них не може його впіймати, і заборона, яка була завжди, тепер стосується розв'язування імен. Прямий трафік до буквальної адреси ще може працювати, якщо його покриває ширший дозвіл, і саме тому ping до публічного резолвера вдається, а пошук імені — ні. Прогалина — це правило для інтерфейсу, якого політика ніколи не бачила.
Це також пояснює, чому збій чисто обертається назад: приберіть тунель, і імена знову розв'язуються, бо запит повертається на інтерфейс, який має правила. Політика, яка збоїть лише при піднятому тунелі, — не проблема 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 збігаються раніше й усе ще можуть відхилити пакет, який список нібито дозволяє.