Pse Pi-hole v6 i injoron kërkesat DNS nga klientët WireGuard

Pi-hole v6 merr një kërkesë DNS në portën 53 dhe më pas vendos nëse paketës që mbërriti i lejohet të përgjigjet. Në një host WireGuard ky vendim i dytë është zakonisht arsyeja pse një klient merr skadim kohe ndërsa zgjidhësi duket i shëndetshëm nga LAN. Porta është e hapur, FTL po punon, e megjithatë asgjë nuk kthehet nga 10.90.0.1. Tre gjëra ndërveprojnë përpara se të dalë një përgjigje: dns.interface, dns.listeningMode dhe muri i zjarrit përpara të dyjave.

Soketi dëgjues nuk vendos se kush merr përgjigje

FTL hap dëgjues UDP dhe TCP në portën 53. Në konfigurimin e parazgjedhur soketi është shpesh wildcard, prandaj ss -lunp | grep :53 shfaq 0.0.0.0:53 dhe [::]:53 pavarësisht nëse u shërbehet klientëve VPN apo jo. Një soket wildcard e pranon paketën, më pas FTL zbaton rregullat e ndërfaqes dhe të burimit përpara se të përgjigjet. Prandaj "porta po dëgjon" provon shumë pak për një klient tuneli.

Lexoni konfigurimin që po ekzekutohet, jo skedarin që mendoni se është aktiv. pihole-FTL --config dns.interface dhe pihole-FTL --config dns.listeningMode shtypin vlerat efektive, dhe ato mund të ndryshojnë nga skedari i hostit kur një kontejner, variabël mjedisi ose menaxher vendosjeje e zotëron cilësimin. Referenca e konfigurimit të Pi-hole FTL rendit mënyrat dhe cilën prej tyre mbështetet në ndërfaqe.

LOCAL pyet cila nënrjetë, SINGLE pyet cila ndërfaqe

LOCAL, mënyra e parazgjedhur, u përgjigjet kërkesave adresa e burimit të të cilave i përket një nënrrjete të konfiguruar në një nga ndërfaqet e hostit. Një wg0 i thjeshtë me 10.90.0.1/24 e kalon atë test, sepse klienti në 10.90.0.2 ndodhet brenda nënrrjetës së tunelit. Një klient i rrugëzuar në anën tjetër të një partneri, ose një i fshehur pas NAT në një prefiks tjetër, nuk e kalon, edhe pse paketa mbërriti në wg0, dhe asnjë kërkesë nuk shfaqet në regjistër.

SINGLE e ndryshon pyetjen. Pranon kërkesat që mbërrijnë në ndërfaqen e emërtuar në dns.interface, duke përfshirë loopback, dhe injoron nënrrjetën e burimit. Kjo është mënyra që i reziston një topologjie VPN të zinxhiruar ose të rrugëzuar. Vendosni të dy çelësat bashkë, sepse një mënyrë pa ndërfaqe të emërtuar nuk është udhëzim i plotë:

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

BIND e ndryshon soketin, dhe kjo ka një kosto

BIND nuk filtron një soket wildcard; e lidh portën 53 vetëm me adresat që ekzistojnë në ndërfaqen e emërtuar, kështu që kerneli i refuzon paketat që mbërrijnë diku tjetër. Është më i rreptë se SINGLE dhe nuk është sinonim i tij. Kostoja shfaqet në nisje: nëse wg0 nuk është lart kur nis FTL, mund të mos ketë adresë për t'u lidhur, dhe zgjidhësi mund të punojë pa dëgjues derisa ndërfaqja të shfaqet dhe FTL të riniset.

Zgjidhni BIND kur kontrolloni rendin e nisjes, për shembull një njësi systemd e renditur pas ndërfaqes WireGuard, dhe kur dëshironi që kerneli t'i hedhë poshtë paketat e humbura përpara se FTL t'i shohë. Zgjidhni SINGLE kur tuneli vjen dhe shkon, ose kur ndërfaqja krijohet nga një mjet që nis pas FTL.

Muri i zjarrit është porta e dytë

Një mënyrë e saktë FTL dështon gjithsesi nëse muri i zjarrit i hostit e hedh portën 53 në wg0. Lejoni intervalin e burimit të VPN për të dy protokollet dhe mbajeni anën e internetit të mbyllur. Në nftables, me zinxhirin input ekzistues në tabelën inet filter, rregullat duken kështu:

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

Shtoni rregulla IPv6 që përputhen nëse tuneli mbart IPv6, dhe vendosini përpara politikës drop të zinxhirit. Nëse hosti përdor ufw ose firewalld, shprehni të njëjtën përputhje në atë menaxher në vend që të përzieni mjete. Mos e përcillni portën 53 nga ruteri i internetit; klientët duhet të arrijnë adresën VPN të zgjidhësit përmes tunelit.

Dy rrugë mbeten të ndara. Kërkesat e klientëve përfundojnë në FTL. Kërkimet e vetë FTL drejt rrjedhës së sipërme dalin sipas tabelës së rrugëzimit të hostit, e cila mund ta përdorë ose jo tunelin, prandaj një zgjidhës që përgjigjet por nuk kthen asgjë të dobishme është problem i rrjedhës së sipërme. Administrimi web dhe API dëgjojnë në portat e tyre dhe kanë nevojë për kufizimin e tyre.

Verifikoni përgjigjen dhe refuzimin

Nga një klient VPN, pyesni adresën e zgjidhësit në të dy protokollet: dig @10.90.0.1 example.com dhe dig +tcp @10.90.0.1 example.com. Më pas kontrolloni regjistrin e kërkesave në ndërfaqen e administrimit për të konfirmuar se FTL e regjistroi kërkesën. Një skadim kohe në klient pa zë në regjistër tregon murin e zjarrit ose filtrin e ndërfaqes; një zë pa përgjigje tregon zgjidhjen e rrjedhës së sipërme.

Testoni rrugën negative nga një host jashtë VPN. dig @10.90.0.1 example.com duhet të skadojë, dhe ss -lunp në zgjidhës nuk duhet të shfaqë portën 53 të lidhur me një adresë publike. Rinisni shërbimin një herë, më pas rinisni hostin dhe konfirmoni se zgjidhësi ende përgjigjet kur wg0 shfaqet përsëri. Një kërkesë që funksionon vetëm deri në rinisjen tjetër nuk është ndryshim i përfunduar.