Pi հոթսփոթ Pi-hole-ով և VPN-ով. յուրաքանչյուր ծառայության տվեք իր աշխատանքը
Որոշեք, թե ով է տիրապետում DHCP-ին, DNS-ին և փաթեթների փոխանցմանը, նախքան մեկ Pi-ի վրա երեք օգնական միացնելը: Կրկնվող տերերը ստեղծում են մրցակցող վարձույթներ և resolver-ի ցիկլեր:
Հեռախոսը միանում է Pi-ի հոթսփոթին, ստանում է հասցե, և էջը դեռ չի բացվում: Pi-ն աշխատեցնում է հոթսփոթի օգնական, Pi-hole և VPN հաճախորդ, և նրանցից յուրաքանչյուրը կարծում է, թե տիրապետում է ուղու մի մասին: Այս հավաքակազմերի մեծ մասը ձախողվում է ոչ թե բաղադրիչի խափանման, այլ այն պատճառով, որ երկու բաղադրիչ կատարում են նույն աշխատանքը: Նշանակեք մեկ տեր յուրաքանչյուր ֆունկցիայի համար, նախքան դրանցից որևէ մեկը կարգավորելը:
Նշանակեք մեկ տեր յուրաքանչյուր ֆունկցիայի համար
Այստեղ կարևոր են չորս ֆունկցիա, և յուրաքանչյուրին անհրաժեշտ է ուղիղ մեկ տեր: Ստորև բերված աղյուսակը նշում է ֆունկցիան, աշխատունակ տերը և այն, ինչ սխալ է գնում, երբ երկու ծառայություն հավակնում են դրան:
| Function | Workable owner | Duplicate-owner symptom |
|---|---|---|
| Client addresses | One DHCP server, such as the hotspot helper | Competing offers and changing leases |
| DNS reception | Pi-hole on port 53 | Bind failure or queries answered by the wrong process |
| Forwarding and NAT | One firewall manager | Double translation and broken return paths |
| VPN routing | One client configuration | Route flapping and traffic escaping outside the tunnel |
Ծածկումը սովորաբար գալիս է մեկ փաթեթով: Հոթսփոթի օգնականը տեղադրում է իր dnsmasq պատճենը, Pi-hole-ը ուզում է 53 պորտը, իսկ VPN հաճախորդը ավելացնում է երթուղիներ: Յուրաքանչյուր քայլ առանձին ողջամիտ է թվում, իսկ միասին նրանք ստեղծում են մեքենա, որտեղ երկրորդ գործարկված ծառայությունը լուռ փոխում է առաջինի վարքը:
Գրի՛ առ տերերին, նախքան ուրիշ բան միացնելը: Կառուցման նշումներում կարճ աղյուսակը թույլ չի տալիս ավելի ուշ տեղադրմանը վերցնել մի ֆունկցիա, որն արդեն տեր ուներ:
Ընտրիր մեկ տիրույթ և հեռու պահիր այն թունելից
Ընտրիր հոթսփոթի տիրույթը, դրա մեջ Pi-ի հասցեն, DHCP լողավազանը և այն resolver-ը, որը ստանում են հաճախորդները: Այդ տիրույթը պահիր առանձին վերին LAN-ից և VPN թունելի տիրույթից, որովհետև համընկնող ենթացանցերը երթուղավորման խնդիրը վերածում են հասցեների թարգմանության նախագծի: Թունելի հետ համընկնող տիրույթը Pi-ն դարձնում է պատահական երթուղիչ երկու նույնական նախածանցերի միջև: Տիրույթն ու լողավազանը գրիր հոթսփոթի կարգավորումներում՝ դրանք լռելյայն արժեքին թողնելու փոխարեն:
Եթե հոթսփոթը պատկանում է NetworkManager-ի ընդհանուր ռեժիմին, DHCP սերվեր ավելացնելուց առաջ ստուգիր փաստացի կապը: Ընդհանուր ռեժիմը գործարկում է իր օգնականները և միացնում փոխանցումը, ուստի արդեն այդ ինտերֆեյսի հասցեային պլանի տերն է: Երկրորդ սերվեր ավելացնելը միայն այն պատճառով, որ այն հասանելի է, ստեղծում է մրցակցող առաջարկներ, ոչ թե պահուստ:
IPv6-ի մասին որոշիր գիտակցաբար: Երթուղիչի հայտարարությունները և DHCPv6-ը շատ կարգավորումներում գալիս են այլ օգնականից, քան DHCPv4-ը, իսկ IPv6-ը միացված թողնելը, մինչ VPN քաղաքականությունը ծածկում է միայն IPv4, հաճախորդներին տալիս է թունելը շրջանցող ուղի: Կամ պլանավորիր IPv6 կողմը, կամ անջատիր այն հոթսփոթի ինտերֆեյսում գրավոր պատճառով:
Ով է իրականում պատասխանում 53 պորտին
Նախքան կարգավորումը փոխելը, թվարկիր 53 պորտը լսող յուրաքանչյուր գործընթաց: Pi-ի վրա, որը աշխատեցնում է տեղական resolver stub, Pi-hole և համօգտագործման օգնական, լսողների ցանկը միակ հուսալի քարտեզն է, թե ով է պատասխանում հարցումներին:
sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip routePi-hole-ի ինտերֆեյսների ուղեցույցը բացատրում է, որ մեկ ինտերֆեյսով սահմանափակված ընդունման ռեժիմը դեռ կարող է օգտագործել wildcard սոքեթ և դեն նետել այլ տեղ հասածները: Սա նույնը չէ, ինչ միայն ընտրված ինտերֆեյսներին կապվելը, որն այն դասավորությունն է, երբ մեքենան պետք է կիսի մեկ այլ DNS ծառայություն:
Երկու գործընթաց սովորաբար չեն կարող կապվել նույն հասցեին ու պորտին, թեև SO_REUSEPORT-ը կարող է համատեղ կապը հաջող դարձնել. նույնիսկ այդ դեպքում wildcard լսողը կարող է վերցնել ավելի նեղ ծառայությանը հասցված ժամանումները: Ընտրիր ցանկալի դերի համար փաստաթղթավորված ռեժիմը և վերագործարկիր ծառայությունները նախատեսված հերթականությամբ:
Pi-hole-ի կառավարման էջը պահիր հոթսփոթի ցանցից դուրս: Հաճախորդներին պետք է resolver, ոչ թե վեբ ինտերֆեյս կամ API, որը կարող է փոխել resolver-ի կարգավորումը:
Երկու DNS ոտք, յուրաքանչյուրին մեկ քաղաքականություն
Հաճախորդի հարցումը գնում է հեռախոսից Pi, իսկ առանձին հարցում՝ Pi-ից նրա վերին resolver: Փոխանցված հոթսփոթի թրաֆիկին համապատասխանող երթուղավորման կանոնը ինքնաբերաբար չի կիրառվում երկրորդ ոտքի վրա, որովհետև Pi-ն այդ թրաֆիկը ստեղծում է տեղական: Եթե VPN-ը պետք է կրի DNS, տեղական ուղուն պետք է իր քաղաքականությունը:
Ուշադիր եղիր ցիկլի նկատմամբ: Pi-hole-ի վերին resolver-ը Pi-ի իսկ սպասարկած հասցեին ուղղելը՝ ուղղակիորեն կամ պորտի փոխանցմամբ, ստեղծում է հարցումներ, որոնք պտտվում են մինչև ժամկետը լրանա: Տվեք նրան իրական վերին resolver կամ պայմանական forwarder այն տիրույթների համար, որոնց չի կարող պատասխանել:
Որոշիր, թե ինչ է լինում, երբ թունելը ընկնում է: Տեղական resolver-ին վերադառնալը պահում է զննարկումը կենդանի, բայց կարող է անունները արտահոսել VPN-ից դուրս. արգելափակելը պահում է քաղաքականությունը անփոփոխ և ընդհատումը դարձնում տեսանելի սխալ: Երկու ընտրություններն էլ պաշտպանելի են, բայց դրանք պետք է ընտրվեն, ոչ թե ժառանգվեն լռելյայն արժեքից:
Ապացուցիր ուղին և վարքը ընդհատման ժամանակ
Փորձարկիր շերտերով. հաճախորդը ստանում է հասցե, հաճախորդը լուծում է անունը Pi-ի միջոցով, Pi-ն լուծում է նախատեսված վերին resolver-ով, և հավելվածը ավարտում է հարցումը: Հաջող ping-ը ոչինչ չի ասում DNS-ի մասին, իսկ հաջող որոնումը ոչինչ չի ասում փոխանցման մասին:
dig @192.168.70.1 example.com
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
ip -4 route get 1.1.1.1Ապա կանգնեցրու թունելը և կրկնիր: Նախատեսված վարքը պետք է հայտնվի մի քանի վայրկյանում, ոչ թե Pi-hole-ի կամ հոթսփոթի ծառայության ձեռքով վերագործարկումից հետո: Ընդհատման ընթացքում ստուգիր հաճախորդի resolver-ի պարամետրը, որովհետև երկրորդական հանրային resolver-ը կշարունակի պատասխանել նույնիսկ այն ժամանակ, երբ քաղաքականությունը սխալ էր սպասում:
Փոխանցման և NAT-ի համար պահիր մեկ տեր և ստուգիր այն հաճախորդից, ոչ թե հենց Pi-ից: Հարցումը, որը հաջողությամբ լքում է Pi-ն, դեռ կարող է դեն նետվել վերադարձի ճանապարհին, և հաճախորդը միակ տեղն է, որտեղ երևում է ամբողջ ուղին: