Popravite DNS gosta libvirt koji blokira VPN firewall zasnovan na oznakama

VPN firewall zasnovan na oznakama odbacuje DNS gosta prije nego što ga vidi lanac filtera. Jedno pravilo s mangle prioritetom označava upit i odgovor, bez otvaranja vaše lokalne mreže.

Gosti na podrazumijevanoj libvirt mreži savršeno razrješavaju imena sve dok se WireGuard sučelje ne podigne, a tada svaki upit zapne na istom mjestu. dnsmasq još uvijek sluša na 192.168.122.1:53, gost još uvijek ima tu adresu kao razrješivač, a upit još uvijek dolazi. Promijenilo se to da hostov vlastiti upstream upit, ili odgovor na njega, sada odbacuje pravilo koje se vrednuje prije bilo kojeg lanca filtera koji biste pomislili urediti. Izlaz je oznaka postavljena dovoljno rano, na vezi koju odgovor nasljeđuje.

Gosti gube DNS u trenutku kad se tunel podigne

Potvrdite oblik prije nego što bilo što promijenite. Spustite tunel, pokrenite dig @192.168.122.1 example.com s gosta i gledajte kako odgovara. Podignite tunel, ponovite i gledajte kako istekne. Taj par rezultata u jednom koraku isključuje pokvarenu libvirt mrežu, pogrešnu adresu razrješivača i mrtav dnsmasq.

Zatim pogledajte hostovu stranu. Ako dnsmasq bilježi upit i njegovo upstream prosljeđivanje, paket je stigao i kvar je na izlazu. Ako dnsmasq nikad ništa ne zabilježi, upit gosta se odbacuje na ulazu i iznimka pripada drugom hooku, a ne onom koji ovaj članak označava.

Zašto accept pravilo u kasnijem lancu nikad ne opali

VPN firewall zasnovan na oznakama odlučuje gledajući oznaku paketa ili oznaku veze, a ne vašu izvornu adresu. Sve što stigne na fizičko sučelje bez očekivane oznake biva odbijeno, a to odbijanje događa se u skupu pravila koji posjeduje test oznake. ip saddr 192.168.122.0/24 accept linija dodana u bilo koji kasniji lanac jednostavno se nikad ne razmatra za taj paket, zato očito pravilo izgleda ispravno i ništa ne mijenja.

Proširivanje dok nešto ne proradi druga je zamka. Prihvaćanje cijele libvirt podmreže na hostovoj ulaznoj stazi otvara svaku hostovu uslugu gostima, kad je stvarna potreba jedan port.

Mehanizam koji usko izuzeće čini mogućim je praćenje veza. Kad postavite ct mark na paket, vrijednost se pohranjuje na conntrack zapisu, a ne samo na paketu, pa je svaki paket te veze poslije nosi, uključujući odgovor s hosta natrag gostu. To je cijeli trik: označite zahtjev jednom i povratna staza je već označena.

Označite upit prije nego što ga VPN tablica vidi

Stavite izuzeće u vlastitu tablicu kako bi ga kasniji čitatelj našao bez parsiranja VPN pravila:

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 je negativna, što ovaj lanac stavlja ispred običnih lanaca filtera koje VPN paket instalira na prioritetu nula. Redoslijed hookova čini pravilo djelotvornim; isto pravilo u lancu koji dolazi nakon VPN lanca samo je ukras.

Sam broj oznake nije prenosiv. Uzmite vrijednost koju instalirana VPN pravila prihvaćaju za vlastiti promet, pročitajte je iz živog skupa pravila i upotrijebite tu. Pogrešna oznaka daje pravilo koje se čisto učitava, poklapa sa svakim upitom i ništa ne pušta.

Držite rupu širine porta 53

Kako je napisano, ovo dopušta DNS iz libvirt podmreže prema hostu preko TCP ili UDP porta 53 i ništa drugo. Ne pušta goste na internet izvan tunela i ne pušta hostu da otvara veze prema gostima. Ako gostu kasnije zatreba druga hostova usluga, dodajte zasebno pravilo koje imenuje taj odredišni port umjesto da ovo olabavite.

Budite iskreni o tome što mijenjate. Gost koji može dohvatiti razrješivač može i tunelirati proizvoljne podatke kroz DNS upite, a ovo izuzeće je namjerna pukotina u VPN granici, a ne tvrdnja da je lokalna mreža pouzdana. Ograničavanje izvora na 192.168.122.0/24 drži pukotinu podalje od svake druge lokalne podmreže, a brojanje upita s tog izvora je jeftino ako vam je prijetnja važna.

Neka preživi restart i dokažite obje polovice

Pravilo otipkano u ljusci nestaje pri sljedećem podizanju, a pravilo učitano nakon što VPN sučelje već propušta promet gubi utrku na prvoj vezi. Stavite tablicu u hostovu trajnu nftables konfiguraciju ili u jedinicu poredanu prije VPN usluge, i provjerite redoslijed umjesto da ga pretpostavljate.

Provjera traži tri odvojena odgovora. Potvrdite da je lanac učitan i poredan prvi, potvrdite da conntrack zapis pokazuje oznaku u oba smjera i potvrdite da upit gosta vraća adresu. Zatim potvrdite drugu polovicu: običan web promet gosta prema javnom hostu još uvijek ne prolazi dok je tunel spušten ili blokira. Ako DNS radi, a sve ostalo curi, vaše pravilo je šire od gornjega.

Ako upiti još uvijek ne prolaze nakon što je oznaka postavljena, oduprite se porivu da proširite izvor. Provjerite kamo dnsmasq prosljeđuje, pokazuje li razrješivač gosta na 192.168.122.1 ili na javnu adresu koju je netko upisao, i dolazi li upit uopće do hosta. Označavanje propušta paket i ništa drugo, pa loš upstream ili pokvarena virtualna mreža ostaju pokvareni koliko god pravila dodali.

Povezani članci