Перамыкач 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 мае названае выключэнне, уключэнне адбылося пасля дазволаў, а выцягванне тунеля забівае звычайны трафік, не забіваючы кліент назаўсёды.