Ինչու է Pi-hole v6-ը անտեսում WireGuard-ի հաճախորդների DNS հարցումները

Pi-hole v6-ը DNS հարցում է ստանում 53 պորտում և հետո որոշում, թե արդյոք ժամանած փաթեթին թույլատրվում է պատասխանել։ WireGuard հոսթում այդ երկրորդ որոշումը սովորաբար այն պատճառն է, թե ինչու հաճախորդը ստանում է ժամանակի սպառում, մինչ լուծիչը LAN-ից առողջ է երևում։ Պորտը բաց է, FTL-ը աշխատում է, բայց և այնպես 10.90.0.1-ից ոչինչ չի վերադառնում։ Երեք բան փոխազդում են, նախքան պատասխանը դուրս կգա՝ dns.interface, dns.listeningMode և դրանց առջևի հրակայուն պատը։

Լսող սոքեթը չի որոշում, թե ով է ստանում պատասխան

FTL-ը բացում է UDP և TCP լսորդներ 53 պորտում։ Կանխադրված կարգավորումներում սոքեթը հաճախ wildcard է, այնպես որ ss -lunp | grep :53 ցույց է տալիս 0.0.0.0:53 և [::]:53 հասցեները՝ անկախ նրանից, սպասարկվու՞մ են VPN հաճախորդները, թե ոչ։ Wildcard սոքեթը ընդունում է փաթեթը, ապա FTL-ը կիրառում է իր ինտերֆեյսի և աղբյուրի կանոնները՝ նախքան պատասխանելը։ Այդ պատճառով «պորտը լսում է» արտահայտությունը շատ քիչ բան է ապացուցում թունելի հաճախորդի մասին։

Կարդացեք աշխատող կարգավորումը, այլ ոչ այն ֆայլը, որը կարծում եք ակտիվ է։ pihole-FTL --config dns.interface և pihole-FTL --config dns.listeningMode տպում են իրական արժեքները, և դրանք կարող են տարբերվել հոսթի ֆայլից, երբ պարամետրը պատկանում է կոնտեյների, միջավայրի փոփոխականին կամ տեղակայման կառավարչին։ Pi-hole FTL-ի կարգավորման ուղեցույցը թվարկում է ռեժիմները և թե որն է հիմնված ինտերֆեյսի վրա։

LOCAL-ը հարցնում է ո՞ր ենթացանցը, SINGLE-ը՝ ո՞ր ինտերֆեյսը

LOCAL-ը, որը կանխադրված է, պատասխանում է հարցումներին, որոնց աղբյուրի հասցեն պատկանում է հոսթի ինտերֆեյսներից մեկում կարգավորված ենթացանցին։ Պարզ wg0-ն 10.90.0.1/24-ով անցնում է այդ ստուգումը, քանի որ 10.90.0.2-ի հաճախորդը գտնվում է թունելի ենթացանցի ներսում։ Երգընկերոջ մյուս կողմում երթուղավորված հաճախորդը, կամ այլ նախածանցում NAT-ի հետևում թաքնված հաճախորդը, այն չի անցնում, թեև փաթեթը հասել է wg0, և մատյանում հարցում չի երևում։

SINGLE-ը փոխում է հարցը։ Այն ընդունում է հարցումներ, որոնք հասնում են dns.interface-ում անվանված ինտերֆեյսին՝ ներառյալ loopback-ը, և անտեսում է աղբյուրի ենթացանցը։ Սա այն ռեժիմն է, որը դիմանում է շղթայված կամ երթուղավորված VPN տոպոլոգիային։ Սահմանեք երկու բանալիները միասին, որովհետև անվանված ինտերֆեյս չունեցող ռեժիմը ամբողջական հրահանգ չէ՝

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

BIND-ը փոխում է սոքեթը, և դա գին ունի

BIND-ը չի զտում wildcard սոքեթը․ այն 53 պորտը կապում է միայն անվանված ինտերֆեյսում գոյություն ունեցող հասցեներին, ուստի միջուկը մերժում է այլ տեղ հասնող փաթեթները։ Այն ավելի խիստ է, քան SINGLE-ը, և դրա հոմանիշը չէ։ Գինը ի հայտ է գալիս գործարկման պահին․ եթե wg0-ն բարձրացված չէ, երբ FTL-ը սկսում է, գուցե կապելու հասցե չլինի, և լուծիչը կարող է աշխատել առանց լսորդի, մինչև ինտերֆեյսը հայտնվի և FTL-ը վերագործարկվի։

Ընտրեք BIND, երբ վերահսկում եք գործարկման հաջորդականությունը, օրինակ՝ WireGuard ինտերֆեյսից հետո դասավորված systemd միավոր, և երբ ցանկանում եք, որ միջուկը դեն նետի մոլորված փաթեթները՝ մինչև FTL-ը կտեսնի դրանք։ Ընտրեք SINGLE, երբ թունելը գալիս ու գնում է, կամ երբ ինտերֆեյսը ստեղծում է գործիք, որը սկսում է FTL-ից հետո։

Հրակայուն պատը երկրորդ դարպասն է

Ճիշտ FTL ռեժիմը դեռ ձախողվում է, եթե հոսթի հրակայուն պատը դեն է նետում 53 պորտը wg0-ի վրա։ Թույլատրեք VPN աղբյուրի տիրույթը երկու արձանագրությունների համար և ինտերնետի կողմը փակ պահեք։ nftables-ում, inet filter աղյուսակի գոյություն ունեցող input շղթայով, կանոնները այսպիսի տեսք ունեն՝

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

Ավելացրեք համապատասխան IPv6 կանոններ, եթե թունելը կրում է IPv6, և դրեք դրանք շղթայի drop քաղաքականությունից առաջ։ Եթե հոսթը օգտագործում է ufw կամ firewalld, նույն համընկնումն արտահայտեք այդ կառավարչում՝ գործիքները խառնելու փոխարեն։ Մի՛ փոխանցեք 53 պորտը ինտերնետի երթուղիչից․ հաճախորդները պետք է լուծիչի VPN հասցեին հասնեն թունելով։

Երկու ուղի մնում են առանձին։ Հաճախորդների հարցումներն ավարտվում են FTL-ում։ FTL-ի սեփական վերին հոսքի որոնումները դուրս են գալիս ըստ հոսթի երթուղավորման աղյուսակի, որը կարող է օգտագործել թունելը կամ չօգտագործել, ուստի լուծիչը, որը պատասխանում է, բայց ոչ մի օգտակար բան չի վերադարձնում, վերին հոսքի խնդիր է։ Վեբ վահանակը և API-ն լսում են իրենց սեփական պորտերում և կարիք ունեն իրենց սեփական սահմանափակմանը։

Ստուգեք պատասխանը և մերժումը

VPN հաճախորդից հարցրեք լուծիչի հասցեն երկու արձանագրություններով՝ dig @10.90.0.1 example.com և dig +tcp @10.90.0.1 example.com։ Այնուհետև ստուգեք հարցումների մատյանը կառավարման ինտերֆեյսում՝ համոզվելու, որ FTL-ը գրանցել է հարցումը։ Հաճախորդի ժամանակի սպառումը՝ առանց մատյանի գրառման, մատնանշում է հրակայուն պատը կամ ինտերֆեյսի զտիչը․ գրառումը՝ առանց պատասխանի, մատնանշում է վերին հոսքի լուծումը։

Փորձարկեք բացասական ուղին VPN-ից դուրս գտնվող հոսթից։ dig @10.90.0.1 example.com պետք է ժամանակը սպառվի, և ss -lunp-ը լուծիչում չպետք է ցույց տա 53 պորտը՝ կապված հանրային հասցեի հետ։ Մեկ անգամ վերագործարկեք ծառայությունը, ապա վերագործարկեք հոսթը և հաստատեք, որ լուծիչը դեռ պատասխանում է, երբ wg0-ն նորից հայտնվում է։ Հարցումը, որն աշխատում է միայն մինչև հաջորդ վերագործարկումը, ավարտված փոփոխություն չէ։