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