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

Зашто 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 пакет инсталира на приоритету нула. Редослед hook-ова чини правило делотворним; исто правило у ланцу који долази после VPN ланца само је украс.

Сам број ознаке није преносив. Узмите вредност коју инсталирана VPN правила прихватају за сопствени саобраћај, прочитајте је из живог скупа правила и употребите ту. Погрешна ознака даје правило које се чисто учитава, поклапа са сваким упитом и ништа не пушта.

Држите рупу ширине порта 53

Како је написано, ово дозвољава DNS из libvirt подмреже ка хосту преко TCP или UDP порта 53 и ништа друго. Не пушта госте на интернет изван тунела и не пушта хосту да отвара везе према гостима. Ако госту касније затреба друга хостова услуга, додајте засебно правило које именује тај одредишни порт уместо да ово олабавите.

Будите искрени о томе шта мењате. Гост који може да дохвати резолвер може и да тунелира произвољне податке кроз DNS упите, а ово изузеће је намерна пукотина у VPN граници, а не тврдња да је локална мрежа поуздана. Ограничавање извора на 192.168.122.0/24 држи пукотину подаље од сваке друге локалне подмреже, а бројање упита са тог извора је јефтино ако вам је претња важна.

Нека преживи рестарт и докажите обе половине

Правило откуцано у шкољци нестаје при следећем подизању, а правило учитано након што VPN интерфејс већ пропушта саобраћај губи трку на првој вези. Ставите табелу у хостову трајну nftables конфигурацију или у јединицу поређану пре VPN услуге, и проверите редослед уместо да га претпостављате.

Провера тражи три одвојена одговора. Потврдите да је ланац учитан и поређан први, потврдите да conntrack запис показује ознаку у оба смера и потврдите да упит госта враћа адресу. Затим потврдите другу половину: обичан веб саобраћај госта ка јавном хосту и даље не пролази док је тунел спуштен или блокира. Ако DNS ради, а све остало цури, ваше правило је шире од горњег.

Ако упити и даље не пролазе након што је ознака постављена, обуздајте порив да проширите извор. Проверите камо dnsmasq прослеђује, показује ли резолвер госта на 192.168.122.1 или на јавну адресу коју је неко укуцао, и долази ли упит уопште до хоста. Означавање пропушта пакет и ништа друго, па лош надређени сервер или покварена виртуелна мрежа остају покварени колико год правила додали.

Повезани чланци