Ištaisyti libvirt svečio DNS, kurį blokuoja žymėmis pagrįsta VPN užkarda

Numatytojo libvirt tinklo svečiai vardus išsprendžia nepriekaištingai, kol nepakyla WireGuard sąsaja, ir tada kiekviena paieška sustoja toje pačioje vietoje. dnsmasq vis dar klausosi 192.168.122.1:53, svečias vis dar naudoja šį adresą kaip resolverį, ir užklausa vis dar ateina. Pasikeitė tai, kad pati pagrindinio kompiuterio viršutinė užklausa arba atsakymas į ją dabar metamas taisyklės, kuri vertinama prieš bet kurią filtravimo grandinę, kurią ketintumėte redaguoti. Išeitis yra žymė, pritaikyta pakankamai anksti, jungtyje, kurią atsakymas paveldi.

Svečiai praranda DNS tuo metu, kai pakyla tunelis

Prieš ką nors keisdami patvirtinkite formą. Nuleiskite tunelį, paleiskite dig @192.168.122.1 example.com iš svečio ir pamatykite, kad jis atsako. Pakelkite tunelį, pakartokite ir pamatykite, kad baigiasi laikas. Ši rezultatų pora vienu žingsniu atmeta sugedusį libvirt tinklą, neteisingą resolverio adresą ir negyvą dnsmasq.

Tada pažiūrėkite į pagrindinio kompiuterio pusę. Jei dnsmasq registruoja užklausą ir jos perdavimą į viršų, paketas atėjo, o gedimas yra išėjime. Jei dnsmasq nieko neregistruoja, svečio užklausa metama įėjime, o išimtis priklauso kitam kabliui nei tam, kurį žymi šis straipsnis.

Kodėl accept taisyklė vėlesnėje grandinėje niekada nesuveikia

Žymėmis pagrįsta VPN užkarda sprendžia žiūrėdama į paketo žymę arba jungties žymę, o ne į jūsų šaltinio adresą. Viskas, kas atvyksta į fizinę sąsają be laukiamos žymės, atmetama, ir tas atmetimas įvyksta taisyklių rinkinyje, kuriam priklauso žymės testas. Vėlesnei grandinei pridėta ip saddr 192.168.122.0/24 accept eilutė tam paketui tiesiog niekada nenagrinėjama, todėl akivaizdi taisyklė atrodo teisinga ir nieko nekeičia.

Plėsti ją, kol kažkas veiks, yra antrasis spąstas. Priimant visą libvirt potinklį pagrindinio kompiuterio įvesties kelyje, svečiams atveriamos visos pagrindinio kompiuterio paslaugos, nors tikrasis poreikis yra vienas prievadas.

Mechanizmas, leidžiantis siaurą išimtį, yra jungčių sekimas. Kai paketui nustatote ct mark, reikšmė saugoma conntrack įraše, o ne tik pakete, todėl kiekvienas tos jungties paketas vėliau ją neša, įskaitant atsakymą iš pagrindinio kompiuterio atgal svečiui. Tai ir yra visas triukas: pažymėkite užklausą vieną kartą, ir grįžimo kelias jau pažymėtas.

Pažymėkite užklausą anksčiau, nei ją pamatys VPN lentelė

Įdėkite išimtį į savo lentelę, kad vėlesnis skaitytojas ją rastų nenagrinėdamas VPN taisyklių:

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 yra neigiamas, o tai pastato šią grandinę prieš įprastas filtravimo grandines, kurias VPN paketas įdiegia nulinio prioriteto. Būtent kablių tvarka daro taisyklę veiksmingą; ta pati taisyklė grandinėje, kuri rikiuojasi po VPN grandinės, yra tik dekoracija.

Pati žymės numeris nėra perkeliama. Paimkite reikšmę, kurią įdiegtos VPN taisyklės priima savo pačių srautui, perskaitykite ją iš gyvo taisyklių rinkinio ir naudokite. Neteisinga žymė sukuria taisyklę, kuri įkeliama švariai, atitinka kiekvieną užklausą ir nieko nepraleidžia.

Laikykite skylę 53 prievado pločio

Kaip parašyta, tai leidžia DNS iš libvirt potinklio į pagrindinį kompiuterį per TCP arba UDP 53 prievadą ir nieko daugiau. Tai neleidžia svečiams pasiekti interneto už tunelio ribų ir neleidžia pagrindiniam kompiuteriui atidaryti jungčių link svečių. Jei svečiui vėliau prireiks kitos pagrindinio kompiuterio paslaugos, pridėkite atskirą taisyklę, įvardijančią tą paskirties prievadą, o ne atlaisvinkite šią.

Būkite sąžiningi dėl to, ką keičiate. Svečias, galintis pasiekti resolverį, taip pat gali tuneliuoti savavališkus duomenis per DNS užklausas, ir ši išimtis yra sąmoninga spraga VPN riboje, o ne teiginys, kad vietinis tinklas yra patikimas. Šaltinio apribojimas iki 192.168.122.0/24 laiko spragą toli nuo kiekvieno kito vietinio potinklio, o užklausų skaičiavimas prieš tą šaltinį yra pigus, jei grėsmė jums svarbi.

Padarykite, kad ji išgyventų perkrovimą, ir įrodykite abi puses

Taisyklė, įvesta komandinės eilutės užuominyje, išnyksta kitą kartą paleidus, o taisyklė, įkelta po to, kai VPN sąsaja jau praleidžia srautą, pralaimi lenktynes pirmoje jungtyje. Įdėkite lentelę į nuolatinę pagrindinio kompiuterio nftables konfigūraciją arba į unit, išdėstytą prieš VPN paslaugą, ir patikrinkite tvarką, o ne manykite ją.

Patikrinimui reikia trijų atskirų atsakymų. Patvirtinkite, kad grandinė įkelta ir išdėstyta pirma, patvirtinkite, kad conntrack įrašas rodo žymę abiem kryptimis, ir patvirtinkite, kad svečio paieška grąžina adresą. Tada patvirtinkite kitą pusę: įprastas svečio žiniatinklio srautas į viešą pagrindinį kompiuterį vis tiek nepavyksta, kol tunelis nuleistas arba blokuoja. Jei DNS veikia, o visa kita nuteka, jūsų taisyklė platesnė už aukščiau pateiktąją.

Jei paieškos vis tiek nepavyksta po to, kai žymė įdėta, atsispirkite norui išplėsti šaltinį. Patikrinkite, kur dnsmasq persiunčia, ar svečio resolveris nukreiptas į 192.168.122.1, ar į viešą adresą, kurį kažkas įvedė, ir ar užklausa apskritai pasiekia pagrindinį kompiuterį. Žymėjimas praleidžia paketą ir nieko daugiau, todėl blogas viršutinis srautas ar sugedęs virtualus tinklas lieka sugedę, kad ir kiek taisyklių pridėtumėte.