Kwa nini Pi-hole v6 hupuuza maombi ya DNS kutoka kwa wateja wa WireGuard

Pi-hole v6 hupokea ombi la DNS kwenye bandari 53 kisha huamua kama pakiti iliyofika inaruhusiwa kujibiwa. Kwenye mwenyeji wa WireGuard uamuzi huo wa pili ndio kawaida huwa sababu mteja anapata muda kuisha huku kisisuluhishi kikionekana kizima kutoka LAN. Bandari iko wazi, FTL inaendesha, lakini hakuna kinachorudi kutoka 10.90.0.1. Mambo matatu huingiliana kabla jibu halijatoka: dns.interface, dns.listeningMode na ngome ya moto mbele ya yote mawili.

Soketi inayosikiliza haiamui nani anapata jibu

FTL hufungua visikilizaji vya UDP na TCP kwenye bandari 53. Katika usanidi wa kawaida soketi huwa wildcard, kwa hiyo ss -lunp | grep :53 huonyesha 0.0.0.0:53 na [::]:53 bila kujali kama wateja wa VPN wanahudumiwa au la. Soketi ya wildcard hukubali pakiti, kisha FTL hutumia kanuni zake za kiolesura na chanzo kabla ya kujibu. Ndiyo sababu "bandari inasikiliza" haithibitishi mengi kuhusu mteja wa handaki.

Soma usanidi unaoendesha badala ya faili unayodhani inatumika. pihole-FTL --config dns.interface na pihole-FTL --config dns.listeningMode huchapisha thamani halisi, na zinaweza kutofautiana na faili ya mwenyeji wakati kontena, kigeu cha mazingira au msimamizi wa usambazaji anamiliki mpangilio huo. Rejea ya usanidi wa Pi-hole FTL huorodhesha hali na ipi kati yao inategemea kiolesura.

LOCAL huuliza subeti ipi, SINGLE huuliza kiolesura kipi

LOCAL, hali ya kawaida, hujibu maombi ambayo anwani yake ya chanzo ni ya subeti iliyosanidiwa kwenye kimoja cha violesura vya mwenyeji. wg0 rahisi yenye 10.90.0.1/24 hupita jaribio hilo, kwa sababu mteja aliye 10.90.0.2 yuko ndani ya subeti ya handaki. Mteja aliyeelekezwa upande wa pili wa mwenza, au aliyejificha nyuma ya NAT katika kiambishi kingine, haipiti, ingawa pakiti ilifika kwenye wg0, na hakuna ombi linaloonekana kwenye kumbukumbu.

SINGLE hubadilisha swali. Hukubali maombi yanayofika kwenye kiolesura kilichotajwa katika dns.interface, pamoja na loopback, na hupuuza subeti ya chanzo. Hii ndiyo hali inayostahimili topolojia ya VPN iliyofungwa mnyororo au iliyoelekezwa. Weka funguo zote mbili pamoja, kwa sababu hali bila kiolesura kilichotajwa si maelekezo kamili:

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

BIND hubadilisha soketi, na hilo lina gharama

BIND haichuji soketi ya wildcard; hufunga bandari 53 kwa anwani zilizopo kwenye kiolesura kilichotajwa pekee, kwa hiyo kerneli hukataa pakiti zinazofika mahali pengine. Ni kali zaidi kuliko SINGLE na si kisawe chake. Gharama inaonekana wakati wa kuwasha: kama wg0 haipo juu FTL inapoanza, huenda hakuna anwani ya kufunga, na kisisuluhishi kinaweza kufanya kazi bila kisisikilizaji hadi kiolesura kionekane na FTL ianzishwe upya.

Chagua BIND unapodhibiti mpangilio wa kuanza, kwa mfano kitengo cha systemd kilichopangwa baada ya kiolesura cha WireGuard, na unapotaka kerneli itupe pakiti zilizopotea kabla FTL haijaona. Chagua SINGLE handaki linapokuja na kwenda, au kiolesura kinapoundwa na chombo kinachoanza baada ya FTL.

Ngome ya moto ni lango la pili

Hali sahihi ya FTL bado inashindikana ikiwa ngome ya moto ya mwenyeji inatupa bandari 53 kwenye wg0. Ruhusu safu ya chanzo ya VPN kwa itifaki zote mbili na uweke upande wa intaneti umefungwa. Katika nftables, pamoja na mnyororo wa input uliopo kwenye jedwali la inet filter, kanuni zinaonekana hivi:

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

Ongeza kanuni zinazolingana za IPv6 ikiwa handaki linabeba IPv6, na uziweke kabla ya sera ya drop ya mnyororo. Ikiwa mwenyeji anatumia ufw au firewalld, eleza ulinganifu huo huo katika msimamizi huyo badala ya kuchanganya zana. Usisambaze bandari 53 kutoka kipanga njia cha intaneti; wateja wanapaswa kufikia anwani ya VPN ya kisisuluhishi kupitia handaki.

Njia mbili zinabaki tofauti. Maombi ya wateja yanaishia FTL. Utafutaji wa FTL wenyewe wa juu hutoka kulingana na jedwali la uelekezaji la mwenyeji, ambalo linaweza kutumia handaki au lisitumie, kwa hiyo kisisuluhishi kinachojibu lakini hakirudishi kitu cha maana ni tatizo la juu. Usimamizi wa wavuti na API husikiliza kwenye bandari zao na huhitaji kizuizi chao.

Thibitisha jibu na kukataliwa

Kutoka kwa mteja wa VPN, uliza anwani ya kisisuluhishi kwa itifaki zote mbili: dig @10.90.0.1 example.com na dig +tcp @10.90.0.1 example.com. Kisha angalia kumbukumbu ya maombi kwenye kiolesura cha usimamizi ili kuthibitisha FTL ilirekodi ombi. Muda kuisha kwa mteja bila ingizo la kumbukumbu huonyesha ngome ya moto au kichujio cha kiolesura; ingizo bila jibu huonyesha utatuzi wa juu.

Jaribu njia hasi kutoka kwa mwenyeji aliye nje ya VPN. dig @10.90.0.1 example.com inapaswa muda kuisha, na ss -lunp kwenye kisisuluhishi haipaswi kuonyesha bandari 53 imefungwa kwa anwani ya umma. Anzisha upya huduma mara moja, kisha anzisha upya mwenyeji na uthibitisha kisisuluhishi bado kinajibu baada ya wg0 kuonekana tena. Ombi linalofanya kazi hadi kuwasha upya kunakofuata tu si mabadiliko yaliyokamilika.