Kāpēc Pi-hole v6 ignorē WireGuard klientu DNS vaicājumus

Pi-hole v6 saņem DNS vaicājumu 53. portā un pēc tam izlemj, vai ienākušajai paketei drīkst atbildēt. WireGuard saimniekā šis otrais lēmums parasti ir iemesls, kāpēc klients saņem taimautu, kamēr atrisinātājs no LAN izskatās vesels. Ports ir atvērts, FTL darbojas, un tomēr nekas neatgriežas no 10.90.0.1. Trīs lietas mijiedarbojas, pirms atbilde iziet: dns.interface, dns.listeningMode un ugunsmūris abu priekšā.

Klausīšanās ligzda nenosaka, kas saņem atbildi

FTL atver UDP un TCP klausītājus 53. portā. Noklusējuma konfigurācijā ligzda bieži ir wildcard, tāpēc ss -lunp | grep :53 rāda 0.0.0.0:53 un [::]:53 neatkarīgi no tā, vai VPN klienti tiek apkalpoti. Wildcard ligzda pieņem paketi, pēc tam FTL pirms atbildes piemēro savus saskarnes un avota noteikumus. Tāpēc frāze „ports klausās“ ļoti maz pierāda par tuneļa klientu.

Lasiet darbojošos konfigurāciju, nevis failu, ko uzskatāt par aktīvu. pihole-FTL --config dns.interface un pihole-FTL --config dns.listeningMode izdrukā faktiskās vērtības, un tās var atšķirties no saimniekdatora faila, ja iestatījumu pārvalda konteiners, vides mainīgais vai izvietošanas pārvaldnieks. Pi-hole FTL konfigurācijas uzziņa uzskaita režīmus un to, kurš no tiem balstās uz saskarni.

LOCAL jautā, kurš apakštīkls, SINGLE jautā, kura saskarne

LOCAL, noklusējuma režīms, atbild uz vaicājumiem, kuru avota adrese pieder apakštīklam, kas konfigurēts vienā no saimniekdatora saskarnēm. Vienkāršs wg0 ar 10.90.0.1/24 iztur šo pārbaudi, jo klients 10.90.0.2 atrodas tuneļa apakštīklā. Maršrutēts klients otrpus partnerim, vai citā prefiksā aiz NAT paslēpts klients, to neiztur, lai gan pakete ieradās uz wg0, un žurnālā neparādās neviens vaicājums.

SINGLE maina jautājumu. Tas pieņem vaicājumus, kas ierodas saskarnē, kas nosaukta dns.interface, ieskaitot loopback, un ignorē avota apakštīklu. Šis ir režīms, kas iztur ķēdes vai maršrutētu VPN topoloģiju. Iestatiet abas atslēgas kopā, jo režīms bez nosauktas saskarnes nav pilnīga instrukcija:

sudo pihole-FTL --config dns.interface "wg0"
sudo pihole-FTL --config dns.listeningMode "SINGLE"

BIND maina ligzdu, un tam ir sava cena

BIND nefiltrē wildcard ligzdu; tas saista 53. portu tikai ar adresēm, kas pastāv nosauktajā saskarnē, tāpēc kodols noraida paketes, kas ierodas citur. Tas ir stingrāks par SINGLE un nav tā sinonīms. Cena parādās palaišanas laikā: ja wg0 nav augšā, kad FTL startē, var nebūt adreses, ar ko saistīt, un atrisinātājs var darboties bez klausītāja, līdz saskarne parādās un FTL restartējas.

Izvēlieties BIND, kad kontrolējat palaišanas secību, piemēram, systemd vienību, kas sakārtota pēc WireGuard saskarnes, un kad vēlaties, lai kodols izmet novaldītās paketes pirms FTL tās ierauga. Izvēlieties SINGLE, kad tunelis nāk un iet, vai kad saskarni izveido rīks, kas startē pēc FTL.

Ugunsmūris ir otrie vārti

Pareizs FTL režīms tomēr neizdodas, ja saimniekdatora ugunsmūris izmet 53. portu uz wg0. Atļaujiet VPN avota diapazonu abiem protokoliem un turiet interneta pusi aizvērtu. nftables, ar esošo input ķēdi tabulā inet filter, noteikumi izskatās šādi:

sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 udp dport 53 accept
sudo nft add rule inet filter input iifname "wg0" ip saddr 10.90.0.0/24 tcp dport 53 accept

Pievienojiet atbilstošus IPv6 noteikumus, ja tunelis pārvadā IPv6, un ievietojiet tos pirms ķēdes drop politikas. Ja saimniekdators izmanto ufw vai firewalld, izsakiet to pašu atbilstību tajā pārvaldniekā, nevis jauciet rīkus. Nepārsūtiet 53. portu no interneta maršrutētāja; klientiem jāsasniedz atrisinātāja VPN adrese caur tuneli.

Divi ceļi paliek atsevišķi. Klientu vaicājumi beidzas FTL. Paša FTL augšupvērstie meklējumi iziet saskaņā ar saimniekdatora maršrutēšanas tabulu, kas var izmantot tuneli vai ne, tāpēc atrisinātājs, kas atbild, bet neko noderīgu neatgriež, ir augšupvērsta problēma. Tīmekļa administrācija un API klausās savos portos, un tiem vajadzīgs savs ierobežojums.

Pārbaudiet atbildi un atteikumu

No VPN klienta vaicājiet atrisinātāja adresi abos protokolos: dig @10.90.0.1 example.com un dig +tcp @10.90.0.1 example.com. Pēc tam pārbaudiet vaicājumu žurnālu administrācijas saskarnē, lai apstiprinātu, ka FTL vaicājumu ierakstīja. Klienta taimauts bez ieraksta žurnālā norāda uz ugunsmūri vai saskarnes filtru; ieraksts bez atbildes norāda uz augšupvērstu atrisināšanu.

Pārbaudiet negatīvo ceļu no saimniekdatora ārpus VPN. dig @10.90.0.1 example.com vajadzētu beigties ar taimautu, un ss -lunp atrisinātājā nevajadzētu rādīt 53. portu saistītu ar publisku adresi. Vienreiz restartējiet pakalpojumu, pēc tam pārstartējiet saimniekdatoru un apstipriniet, ka atrisinātājs joprojām atbild, kad wg0 atkal parādās. Vaicājums, kas darbojas tikai līdz nākamajai pārstartēšanai, nav pabeigta izmaiņa.