Выпраўленне DNS гасцей libvirt, заблакаванага VPN-файрволам на аснове адзнак

VPN-файрвол на аснове адзнак скідвае DNS гасцей раней, чым яго ўбачыць любы ланцуг фільтрацыі. Адно правіла з прыярытэтам mangle пазначае запыт і адказ на яго, не адкрываючы вашу лакальную сетку.

Госці ў стандартнай сетцы libvirt выдатна развязваюць імёны, пакуль не паднімаецца інтэрфейс WireGuard, і тады кожны пошук затынаецца ў адным і тым жа месцы. dnsmasq па-ранейшаму слухае на 192.168.122.1:53, госць па-ранейшаму выкарыстоўвае гэты адрас як рэзалвер, і запыт па-ранейшаму прыходзіць. Змянілася тое, што ўласны запыт хоста да вышэйшага сервера, або адказ на яго, цяпер скідваецца правілам, якое ацэньваецца раней за любы ланцуг фільтрацыі, які вы б меркавалі правіць. Выхад — адзнака, якая ставіцца дастаткова рана, на злучэнні, якое атрымлівае адказ у спадчыну.

Госці губляюць DNS у момант падняцця тунеля

Пераканайцеся ў форме, перш чым нешта змяняць. Апусціце тунель, запусціце dig @192.168.122.1 example.com з госця і паглядзіце, як ён адказвае. Падніміце тунель, паўтарыце і паглядзіце, як сканчаецца час чакання. Гэтая пара вынікаў за адзін крок выключае зламаную сетку libvirt, няправільны адрас рэзалвера і мёртвы dnsmasq.

Затым паглядзіце на бок хоста. Калі dnsmasq запісвае запыт і яго перанакіраванне ўверх, пакет дайшоў, і збой на выхадзе. Калі dnsmasq не запісвае нічога, запыт госця скідваецца на ўваходзе, і выключэнне належыць да іншага хука, чым той, які пазначае гэты артыкул.

Чаму правіла accept у пазнейшым ланцугу ніколі не спрацоўвае

VPN-файрвол на аснове адзнак вырашае, гледзячы на адзнаку пакета або адзнаку злучэння, а не на ваш адрас крыніцы. Усё, што прыходзіць на фізічны інтэрфейс без чаканай адзнакі, адхіляецца, і гэта адхіленне адбываецца ў наборы правіл, які валодае праверкай адзнакі. Радок ip saddr 192.168.122.0/24 accept, дададзены ў нейкі пазнейшы ланцуг, проста ніколі не разглядаецца для гэтага пакета, таму відавочнае правіла выглядае правільным і нічога не змяняе.

Пашырэнне, пакуль нешта не заработае, — другая пастка. Прыняцце ўсяго подсеткі libvirt у шляху ўводу хоста адкрывае ўсе службы хоста для гасцей, тады як рэальная патрэба — адзін порт.

Механізм, які робіць вузкае выключэнне магчымым, — гэта адсочванне злучэнняў. Калі вы ўсталёўваеце ct mark на пакет, значэнне захоўваецца ў запісе conntrack, а не толькі ў пакеце, таму кожны пакет у гэтым злучэнні носіць яго далей, уключаючы адказ ад хоста назад да госця. Гэта ўся хітрасць: пазначце запыт адзін раз, і шлях вяртання ўжо пазначаны.

Пазначце запыт раней, чым яго ўбачыць табліца VPN

Змясціце выключэнне ў асобную табліцу, каб пазнейшы чытач мог знайсці яго, не разбіраючы правілы VPN:

table inet allowedLocal {
  chain guest_dns {
    type filter hook input priority mangle; policy accept;
    ip saddr 192.168.122.0/24 meta l4proto { tcp, udp } \
      th dport 53 ct mark set 0x00000f41
  }
}

priority mangle адмоўны, што ставіць гэты ланцуг перад звычайнымі ланцугамі фільтрацыі, якія пакет VPN усталёўвае з прыярытэтам нуль. Менавіта парадак хукаў робіць правіла дзейсным; тое ж правіла ў ланцугу, які сартуецца пасля ланцуга VPN, — гэта ўпрыгожванне.

Само лік адзнакі не пераноснае. Вазьміце значэнне, якое ўсталяваныя правілы VPN прымаюць для свайго трафіку, счытайце яго з жывога набору правіл і выкарыстайце. Няправільная адзнака стварае правіла, якое чыста загружаецца, супадае з кожным запытам і нічога не дапушчае.

Трымайце дзірку шырынёй у порт 53

Як напісана, гэта дазваляе DNS з подсеткі libvirt да хоста праз TCP або UDP порт 53 і нічога больш. Гэта не дазваляе гасцям дасягаць інтэрнэту па-за тунелем і не дазваляе хосту адкрываць злучэнні да гасцей. Калі госцю пазней спатрэбіцца іншая служба хоста, дадайце асобнае правіла, якое называе гэты порт прызначэння, замест таго каб паслабляць гэтае.

Будзьце сумленныя адносна таго, чым вы гандлюеце. Госць, які можа дасягнуць рэзалвера, можа таксама тунеляваць адвольныя даныя праз DNS-запыты, і гэта выключэнне — наўмысная праломіна ў мяжы VPN, а не сцвярджэнне, што лакальная сетка давераная. Абмежаванне крыніцы да 192.168.122.0/24 трымае праломіну па-за любой іншай лакальнай подсеткай, і падлік запытаў ад гэтай крыніцы каштуе танна, калі пагроза для вас важная.

Зрабіце так, каб яно перажыло перазагрузку, і дакажыце абедзве паловы

Правіла, набранае ў запоўненні абалонкі, знікае пры наступнай загрузцы, а правіла, загружанае пасля таго, як інтэрфейс VPN ужо прапускае трафік, прайграе гонку на першым злучэнні. Змесціце табліцу ў пастаянную канфігурацыю nftables хоста або ў unit, замоўлены перад службай VPN, і праверце парадак замест таго каб меркаваць яго.

Праверка патрабуе трох асобных адказаў. Пацвердзіце, што ланцуг загружаны і ідзе першым, пацвердзіце, што запіс conntrack паказвае адзнаку ў абодвух кірунках, і пацвердзіце, што пошук госця вяртае адрас. Затым пацвердзіце другую палову: звычайны вэб-трафік госця да публічнага хоста па-ранейшаму не праходзіць, пакуль тунель апушчаны або блакуе. Калі DNS працуе, а ўсё астатняе выцякае, ваша правіла шырэйшае за прыведзенае вышэй.

Калі пошук па-ранейшаму не ўдаецца пасля ўсталёўкі адзнакі, супраціўляйцеся жаданню пашырыць крыніцу. Праверце, куды перанакіроўвае dnsmasq, ці паказвае рэзалвер госця на 192.168.122.1 ці на публічны адрас, які хтосьці ўвёў, і ці дасягае запыт хоста наогул. Адзнака дапушчае пакет і нічога больш, таму дрэнны вышэйшы сервер або зламаная віртуальная сетка застаюцца зламанымі, колькі б правілаў вы ні дадалі.

Падобныя артыкулы