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 дазваляе трафік, які сервер адтуль атрымлівае; яны жывуць на розных машынах і правальваюцца незалежна. Радок, які забываюць найчасцей, — другі, бо кліент увогуле не можа ўсталяваць тунэль, пакуль яго трафік да публічнага адраса сервера не будзе дазволены. Працуйце зверху ўніз, і кожны збой мае адну верагодную прычыну.
Рэзалвер, які прыйшоў з push, патрабуе ўласнага правіла
Ці нясе тунэль 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 свядома для адміністратыўнага порта, бо ён стрымлівае паўторныя злучэнні замест таго, каб прымаць іх без абмежавання. Праверка слухача аддзяляе закрыты порт ад адкінутага пакета, якія з боку кліента выглядаюць аднолькава. Пранумараваныя правілы таксама не ўся карціна: правілы UFW before і любыя напісаныя ўручную радкі nftables супадаюць раней і ўсё яшчэ могуць адхіліць пакет, які спіс нібыта дазваляе.