Popravite DNS gosta u libvirtu koji blokira VPN vatrozid zasnovan na oznakama

Gosti na podrazumijevanoj libvirt mreži savršeno razrješavaju imena sve dok se WireGuard interfejs ne podigne, a tada svaka pretraga zapne na istom mjestu. dnsmasq još uvijek sluša na 192.168.122.1:53, gost još uvijek ima tu adresu kao svoj razrješivač, a upit još uvijek stiže. Ono što se promijenilo jeste da se vlastiti upstream upit hosta, ili odgovor na njega, sada odbacuje pravilom koje se ocjenjuje prije bilo kojeg lanca filtera koji biste pomislili urediti. Izlaz je oznaka primijenjena dovoljno rano, na konekciji koju odgovor nasljeđuje.

Gosti gube DNS u trenutku kada se tunel podigne

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

Zatim pogledajte na strani hosta. Ako dnsmasq bilježi upit i njegovo upstream prosljeđivanje, paket je stigao i kvar je na izlazu. Ako dnsmasq ne bilježi ništa, upit gosta se odbacuje na ulazu i izuzetak pripada drugom hooku od onog koji ovaj članak označava.

Zašto accept pravilo u kasnijem lancu nikada ne reaguje

VPN vatrozid zasnovan na oznakama odlučuje gledajući oznaku paketa ili oznaku konekcije, a ne vašu izvornu adresu. Sve što stigne na fizički interfejs bez očekivane oznake biva odbijeno, a to odbijanje se događa u skupu pravila koji posjeduje test oznake. Linija ip saddr 192.168.122.0/24 accept dodana u neki kasniji lanac jednostavno se nikada ne razmatra za taj paket, zbog čega se očigledno pravilo čini ispravnim i ne mijenja ništa.

Proširivanje dok nešto ne proradi druga je zamka. Prihvatanje cijele libvirt podmreže na ulaznoj putanji hosta otvara svaku uslugu hosta gostima, dok je stvarna potreba jedan port.

Mehanizam koji usko izuzeće čini mogućim jeste praćenje konekcija. Kada postavite ct mark na paket, vrijednost se čuva u conntrack zapisu, a ne samo u paketu, pa je svaki paket u toj konekciji nakon toga nosi, uključujući odgovor s hosta natrag gostu. To je cijeli trik: označite zahtjev jednom i povratna putanja je već označena.

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

Stavite izuzeće u vlastitu tabelu da ga kasniji čitalac može naći bez raščlanjivanja 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 negativan, što ovaj lanac stavlja ispred običnih lanaca filtera koje VPN paket instalira na prioritetu nula. Redoslijed hookova je ono što pravilo čini djelotvornim; isto pravilo u lancu koji se sortira poslije VPN lanca je ukras.

Sam broj oznake nije prenosiv. Uzmite vrijednost koju instalirana VPN pravila prihvataju za vlastiti saobraćaj, pročitajte je iz živog skupa pravila i upotrijebite. Pogrešna oznaka stvara pravilo koje se čisto učitava, poklapa sa svakim upitom i ne propušta niš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 više. Ne dopušta gostima da dosegnu internet izvan tunela i ne dopušta hostu da otvara konekcije prema gostima. Ako gostu kasnije treba druga usluga hosta, dodajte zasebno pravilo koje imenuje taj odredišni port umjesto da opuštate ovo.

Budite iskreni o tome šta mijenjate. Gost koji može dosegnuti razrješivač može i tunelirati proizvoljne podatke kroz DNS upite, a ovo izuzeće je namjerna praznina u VPN granici, a ne izjava da je lokalna mreža pouzdana. Ograničavanje izvora na 192.168.122.0/24 drži prazninu podalje od svake druge lokalne podmreže, a brojanje upita prema tom izvoru je jeftino ako vam je prijetnja važna.

Neka preživi restart i dokažite obje polovine

Pravilo otkucano u shell promptu nestaje pri sljedećem podizanju, a pravilo učitano nakon što VPN interfejs već propušta saobraćaj gubi trku na prvoj konekciji. Stavite tabelu u trajnu nftables konfiguraciju hosta ili u unit poredan prije VPN usluge i provjerite redoslijed umjesto da ga pretpostavljate.

Provjera zahtijeva tri odvojena odgovora. Potvrdite da je lanac učitan i poredan prvi, potvrdite da conntrack zapis pokazuje oznaku u oba smjera i potvrdite da pretraga gosta vraća adresu. Zatim potvrdite drugu polovinu: običan web saobraćaj gosta prema javnom hostu i dalje ne uspijeva dok je tunel spušten ili blokira. Ako DNS radi a sve ostalo curi, vaše pravilo je šire od gornjeg.

Ako pretrage i dalje ne uspijevaju nakon što je oznaka na mjestu, oduprite se porivu da proširite izvor. Provjerite na šta dnsmasq prosljeđuje, pokazuje li razrješivač gosta na 192.168.122.1 ili na javnu adresu koju je neko otkucao i stiže li upit uopće do hosta. Označavanje propušta paket i ništa drugo, pa loš upstream ili pokvarena virtuelna mreža ostaju pokvareni bez obzira na to koliko pravila dodate.