Прекидач 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 има именовани изузетак, укључивање је дошло после дозвола, и повлачење тунела убија обичан саобраћај без трајног убијања клијента.