Labot libvirt viesa DNS, ko bloķē uz atzīmēm balstīts VPN ugunsmūris

Noklusējuma libvirt tīkla viesi vārdus izšķir nevainojami, līdz tiek pacelta WireGuard saskarne, un tad katra meklēšana iestieg tajā pašā vietā. dnsmasq joprojām klausās 192.168.122.1:53, viesim joprojām ir šī adrese kā atrisinātājs, un vaicājums joprojām pienāk. Mainījies ir tas, ka paša resursdatora augšupstraumes vaicājumu vai atbildi uz to tagad izmet noteikums, kas tiek novērtēts pirms jebkuras filtru ķēdes, ko jūs iedomātos rediģēt. Izeja ir atzīme, kas piemērota pietiekami agri, savienojumam, ko atbilde manto.

Viesi zaudē DNS brīdī, kad tiek pacelts tunelis

Pirms kaut ko mainīt, pārliecinieties par formu. Nolaidiet tuneli, palaidiet dig @192.168.122.1 example.com no viesa un vērojiet, kā tas atbild. Paceliet tuneli, atkārtojiet un vērojiet, kā tam beidzas laiks. Šis rezultātu pāris vienā solī izslēdz bojātu libvirt tīklu, nepareizu atrisinātāja adresi un mirušu dnsmasq.

Pēc tam paskatieties uz resursdatora pusi. Ja dnsmasq reģistrē vaicājumu un tā pārsūtīšanu augšup, pakete ir ieradusies un kļūme ir izejā. Ja dnsmasq neko nereģistrē, viesa vaicājums tiek izmests ieejā un izņēmums pieder citam āķim nekā tam, kuru atzīmē šis raksts.

Kāpēc accept noteikums vēlākā ķēdē nekad neiedarbojas

Uz atzīmēm balstīts VPN ugunsmūris izlemj, skatoties paketes atzīmi vai savienojuma atzīmi, nevis jūsu avota adresi. Viss, kas bez gaidītās atzīmes ierodas fiziskajā saskarnē, tiek noraidīts, un šī noraidīšana notiek noteikumu kopā, kam pieder atzīmes tests. Vēlākai ķēdei pievienotā ip saddr 192.168.122.0/24 accept rinda šai paketei vienkārši nekad netiek izskatīta, tāpēc acīmredzamais noteikums šķiet pareizs un neko nemaina.

Tā paplašināšana, līdz kaut kas strādā, ir otrais slazds. Visas libvirt apakštīkla pieņemšana resursdatora ievades ceļā atver visus resursdatora pakalpojumus viesiem, lai gan faktiskā vajadzība ir viens ports.

Mehānisms, kas ļauj šauru izņēmumu, ir savienojumu izsekošana. Kad paketei iestatāt ct mark, vērtība tiek saglabāta conntrack ierakstā, nevis tikai paketē, tāpēc katra šī savienojuma pakete pēc tam to nes, tostarp atbilde no resursdatora atpakaļ viesim. Tas ir viss triks: atzīmējiet pieprasījumu vienreiz, un atgriešanās ceļš jau ir atzīmēts.

Atzīmējiet vaicājumu, pirms to ierauga VPN tabula

Ievietojiet izņēmumu savā tabulā, lai vēlāks lasītājs to atrastu, neanalizējot VPN noteikumus:

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 ir negatīvs, kas šo ķēdi novieto pirms parastajām filtru ķēdēm, ko VPN pakotne instalē ar nulles prioritāti. Tieši āķu secība padara noteikumu efektīvu; tas pats noteikums ķēdē, kas tiek sakārtota pēc VPN ķēdes, ir tikai dekorācija.

Pats atzīmes numurs nav pārnesams. Paņemiet vērtību, ko instalētie VPN noteikumi pieņem savam pašu trafikam, nolasiet to no dzīvās noteikumu kopas un izmantojiet. Nepareiza atzīme rada noteikumu, kas ielādējas tīri, atbilst katram vaicājumam un neko neielaiž.

Turiet caurumu 53. porta platumā

Kā rakstīts, tas ļauj DNS no libvirt apakštīkla uz resursdatoru pa TCP vai UDP 53. portu un neko citu. Tas neļauj viesiem sasniegt internetu ārpus tuneļa, un tas neļauj resursdatoram atvērt savienojumus pret viesiem. Ja viesim vēlāk vajadzīgs cits resursdatora pakalpojums, pievienojiet atsevišķu noteikumu, kas nosauc to galamērķa portu, nevis atbrīvojiet šo.

Esiet godīgi par to, ko maināt. Viesis, kas var sasniegt atrisinātāju, var arī tunelēt patvaļīgus datus caur DNS vaicājumiem, un šis izņēmums ir apzināta sprauga VPN robežā, nevis apgalvojums, ka vietējais tīkls ir uzticams. Avota ierobežošana līdz 192.168.122.0/24 tur spraugu prom no katra cita vietējā apakštīkla, un vaicājumu skaitīšana pret šo avotu ir lēta, ja drauds jums ir svarīgs.

Padariet to noturīgu pret pārstartēšanu un pierādiet abas puses

Noteikums, kas ierakstīts čaulas uzvednē, pazūd nākamajā palaišanā, un noteikums, kas ielādēts pēc tam, kad VPN saskarne jau laiž cauri trafiku, zaudē sacensību pirmajā savienojumā. Ielieciet tabulu resursdatora pastāvīgajā nftables konfigurācijā vai unit, kas sakārtota pirms VPN pakalpojuma, un pārbaudiet kārtību, nevis pieņemiet to.

Pārbaudei vajadzīgas trīs atsevišķas atbildes. Apstipriniet, ka ķēde ir ielādēta un sakārtota pirmā, apstipriniet, ka conntrack ieraksts rāda atzīmi abos virzienos, un apstipriniet, ka viesa meklēšana atgriež adresi. Pēc tam apstipriniet otru pusi: parastā viesa tīmekļa trafiks uz publisku resursdatoru joprojām neizdodas, kamēr tunelis ir nosēdināts vai bloķē. Ja DNS strādā un viss pārējais noplūst, jūsu noteikums ir plašāks par augstāk minēto.

Ja meklēšana joprojām neizdodas pēc tam, kad atzīme ir vietā, pretojieties vēlmei paplašināt avotu. Pārbaudiet, uz kurieni dnsmasq pārsūta, vai viesa atrisinātājs norāda uz 192.168.122.1 vai uz publisku adresi, ko kāds ievadījis, un vai vaicājums vispār sasniedz resursdatoru. Atzīmēšana ielaiž paketi un neko citu, tāpēc slikta augšupstraume vai bojāts virtuālais tīkls paliek bojāts, lai cik noteikumu jūs pievienotu.