AdGuard Home Inajibu Wateja wa WireGuard Kutoka Anwani Yako ya LAN

Kituo kiko juu, kizuizi cha moto kinaruhusu bandari 53, AdGuard Home inafanya kazi, na majina bado hayaonekani kwa mteja wa WireGuard. Ombi kawaida huwasili na jibu kawaida hutoka, kwa hivyo kuhesabu pakiti kwenye suluhu kinaonekana kuwa kikiwa pazuri na huduma inaonekana kuwa hatia. Kinachoshindikana ni anwani ya chanzo kwenye jibu hilo: hutoka kutoka anwani ya ndani ambayo mteja kamwe hakuuliza, na suluhu ya stub ya mteja inailipua. Orodha moja katika usanidi wa AdGuard Home inamua hili, na chaguo la kawaida kwa kawaida linaacha uamuzi kwenye kiini cha mfumo.

Ombi huwasili, jibu hutoka kutoka mahali pengine

Mteja aliyesanidiwa na 10.6.0.1 kama mradi wake anatuma swali la UDP kwa 10.6.0.1 bandari 53. Kikundi hicho kinapita kwenye tundu na kufika kwenye mwenyeji, na AdGuard Home kinajibu. Hata hivyo, kwenye waya, jibu ni pakiti mpya ambayo anwani yake ya asili inachaguliwa na mfumo wa mwenyeji, sio kwa matarajio ya mteja.

Wakati mradi wa mteja ni soketi iliyounganishwa, ambayo ndiyo inayotumika na systemd-resolved, dnsmasq na watoa huduma wengi wa stub, inakubali majibu kutoka anwani hasa ile iliyo pelekwa. Jibu lililotoka 192.168.1.10 kwa swali lililotumwa kwenda 10.6.0.1 limekoma kabla ya uchambuzi wowote kutokea. Mradi unalog taarifa ya jibu lililofaulu, mteja analog timer ya muda, na wote wanasema ukweli.

Kwa hivyo kihesabu hakilieni na mteja pia si mwongo. Ushahidi unaohitajika upo katika sehemu tatu, kwa mpangilio huu: anwani ambayo msikilizaji amefungwa nayo, njia ambayo kernel ingetumia kurudi kwa mteja, na anwani ya chanzo kwenye kifurushi halisi cha jibu.

Jinsi kernel inavyobadilisha chanzo cha jibu

Soketi ya UDP iliyofungwa kwenye0.0.0.0haina anwani yake ya chanzo, kwa hivyo kila jibu linalotoka linachochea utafutaji wa njia kwa lengo. Kisha kernel huchukua chanzo kutoka kwenye njia hiyo: anwani iliyobebwa na njia, au anwani kuu ya kiolesura kinachotoka. Hakuna chochote kuhusu anwani ya lengo la upyaji kinachohifadhiwa.

Kwa mwenyeji mmoja wa kifaa hiki haioniwi, kwa sababu kuna jibu moja tu linalowezekana. Kwenye mashine inayoshikilia anwani ya LAN, anwani ya WireGuard na anwani ya usimamizi, majibu kadhaa yanayowezekana, na mshindi hutegemea jedwali la usafirishaji kwa wakati huo. Ongeza njia ya ziada, anwani ya pili kwenye kiolesura hicho hicho, uelekezao wa NAT mbele ya suluhisho, au endesha AdGuard ndani ya kontena yenye nafasi yake ya jina, na chanzo kilichochaguliwa kinaweza kutofautiana na kile ambacho mteja aliuliza.

ss -lunp | grep :53inaonyesha ni mchezo gani uko ndani yake. Mkusanyaji kwenye0.0.0.0:53ni kesi ya wildcard; mkusanyaji kwenye10.6.0.1:53tayari ameshashikilia jibu. Kusoma soketi ni haraka kuliko kusoma YAML, na inaakisi kile kinachokimbia kweli badala ya kile kilichohifadhiwa mwisho.

Vitu ambavyo bind_hosts hakika vinadhibiti

AdGuard Home.dns.bind_hostsni orodha ya anwani za ndani zinazotumika na msikilizaji wa DNS. Chaguo-msingi kilichopelekwa ni jokeri, ambalo linamaanisha kubariki kwa kila anwani ya ndani na kumruhusu kernel kuchagua chanzo kwa kila jibu. Kubadilisha jokeri na anwani ambayo wateja hufuata inabadilisha socket, na pamoja na hiyo anwani ya chanzo kwa kila jibu.

Orodha inaweza kuchukua maingizo zaidi ya moja, jambo ambalo ni muhimu kwa suluhisho linalohudumia mitandao miwili. Kuweka10.6.0.1na192.168.1.10kunatoa sockets mbili zilizowekwa, na utafutaji unaoikaribia moja yoyote unajibiwa kutoka anwani iliyofikilia. Hii ndilo tabia ambayo watu wengi huchukuliza jokeri tayari linatoa.

YAML ni rahisi, na anwani iliyo ndani yake ndiyo wateja wako wa tundu waliambiwa kuitumia, sio anwani kuu ya mwenyeji:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Kwa nini ufungaji mbili wa suluhisho moja hazikubaliani

Iliotengwa na programu-jalishi, katika muktadha huu, ina maana kwamba suluhisho hilo limewekwa na linadhibitiwa na kifurushi kingine: kifurushi cha programu ya router, kifurushi cha NAS, au kiambatisho cha otomatiki ya nyumba. Kifurushi hicho kwa kawaida hufanya nakala yake yenyewe ya YAML ya AdGuard Home na kuanzisha upya mchakato kwa ratiba yake mwenyewe, wakati toleo huru ni binary au kontena ya muuzaji unayojitayarisha mwenyewe. Kwa njia yoyote, unatazama michakato miwili huru yenye faili za usanidi tofauti na chaguzi za bind tofauti, hata wakati zote zinakagua orodha ya juu na orodha za kichujio sawa. Moja linaweza kufunga anwani maalum ya bomba wakati lingine linapokea wildcard, na interface ya wavuti inaonekana sawa kutoka pande zote mbili.

Ndivyo maana "kifumbuzi kilekile kilienda kabla ya uhamishaji" hakuthibitishi chochote kuhusu ufungaji wa sasa. Angalia soketi, kisha angalia faili la usanidi ambalo mchakato unaoendesha kweli uliloipakia. Nakala iliyochakaa kwenye saraka nyingine ni sababu ya kawaida ambayo marekebisho hayaonekani yanaathiri.

Iiweke, kisha jaribu kutoka upande wa tuneli

Badilishabind_hostskwa anwani ya tuneli, anzisha upya huduma, na thibitisha soketi imehamia:ss -lunp | grep :53sasa inapaswa kuonyesha10.6.0.1:53na hakuna kipengele cha wildcard. Ikiwa bado inaonyesha0.0.0.0,mchakato unaoendesha haukisomi faili uliyoyahariri.

Kisha jaribu kutoka kwa mteja, kwa sababu upande huo peke yake ndio unaohesabiwa. Utafiti ukiwa nadig @10.6.0.1 example.comunatumia njia ambayo mtumiaji anaitumia, na kumbukizi kwenye mwenyeji kwatcpdump -ni wg0 udp port 53inaonyesha anwani ya chanzo ya jibu kwenye waya. Linganisha na anwani iliyoko kwenye mpangilio wa mtafsiri wa mteja; wanapolingana, muda wa kungojea haubaki kuwa siri.

ip route get 10.6.0.2inaelezea upungufu wowote uliobaki, kwa sababu inaonyesha kiolesura na chanzo ambacho mwenyeji angesitumia kurudisha kwa mteja. Ikiwa matokeo hayo yataleta jina la kiolesura cha LAN, mabadiliko ya bind si suluhisho kamili na jedwali la upangaji ni kitu kinachofuata kusoma.

Yanayoshindwa kurekebishwa na mpangilio wa bind

Kuweka msikilizaji maalum hakutengenezi orodha ya ufikaji ambayo inapuuzia subnet ya tuneli, kanuni ya ukuta wa moto inayoruhusu swali lakini si jibu, au njia iliyokosekana kurudisha kwenye hifadhi ya WireGuard. Hivyo hukosa mapema au baadaye kuliko anwani ya chanzo, na kila moja ina mmiliki tofauti.

Pia haibadilishini wapi mtafsiri anavyotuma mbele, iwe ulinzi wa kuunganisha upya unakata jibu la faragha kwa jina la faragha, au jinsi mteja anavyotumia maeneo yake ya utafutaji. Hizo ni udhibiti tofauti. Badilisha anwani ya kuunganisha wakati chanzo cha jibu kiko vibaya, na badilisha kitu kingine wakati siyo.