Pi prieigos taškas su Pi-hole ir VPN: kiekvienai tarnybai priskirkite savo užduotį

Telefonas prisijungia prie Pi prieigos taško, gauna adresą, o puslapis vis tiek neatsidaro. Pi paleidžia prieigos taško pagalbininką, Pi-hole ir VPN klientą, ir kiekvienas mano valdąs dalį kelio. Dauguma tokių surinkimų nepavyksta ne dėl sugedusio komponento, o dėl to, kad du komponentai atlieka tą patį darbą. Prieš ką nors derindami, kiekvienai funkcijai paskirkite vieną savininką.

Kiekvienai funkcijai paskirkite vieną savininką

Čia svarbios keturios funkcijos, ir kiekvienai reikia tiksliai vieno savininko. Žemiau esančioje lentelėje nurodyta funkcija, tinkamas savininkas ir tai, kas sugenda, kai į ją pretenduoja dvi tarnybos.

Persidengimas paprastai ateina po vieną paketą. Prieigos taško pagalbininkas įdiegia savo dnsmasq egzempliorių, Pi-hole nori 53 prievado, o VPN klientas prideda maršrutus. Kiekvienas žingsnis atskirai atrodo pagrįstas, o kartu jie sukuria mašiną, kurioje antroji paleista tarnyba tyliai pakeičia pirmosios elgesį.

Užsirašykite savininkus prieš ką nors kita įjungdami. Trumpa lentelė surinkimo pastabose neleis vėlesnei instaliacijai perimti funkcijos, kuri jau turėjo savininką.

Pasirinkite vieną diapazoną ir laikykite jį atokiau nuo tunelio

Pasirinkite prieigos taško diapazoną, Pi adresą jame, DHCP telkinį ir resolverį, kurį gauna klientai. Laikykite tą diapazoną atskirai nuo aukštesniojo LAN ir nuo VPN tunelio diapazono, nes persidengiantys potinkliai maršrutizavimo problemą paverčia adresų vertimo projektu. Su tuneliu persidengiantis diapazonas padaro Pi atsitiktiniu maršrutizatoriumi tarp dviejų vienodų prefiksų. Įrašykite diapazoną ir telkinį į prieigos taško konfigūraciją, o ne palikite juos numatytajai reikšmei.

Jei prieigos tašką valdo bendrasis NetworkManager režimas, prieš pridėdami DHCP serverį patikrinkite faktinį ryšį. Bendrasis režimas paleidžia savo pagalbininkus ir įjungia persiuntimą, todėl jis jau yra tos sąsajos adresų plano savininkas. Antro serverio pridėjimas vien todėl, kad jis prieinamas, sukuria konkuruojančius pasiūlymus, o ne rezervaciją.

Dėl IPv6 nuspręskite sąmoningai. Maršrutizatoriaus skelbimai ir DHCPv6 daugelyje konfigūracijų ateina iš kito pagalbininko nei DHCPv4, o palikus IPv6 įjungtą, kai VPN politika apima tik IPv4, klientai gauna kelią, aplenkiančią tunelį. Arba suplanuokite IPv6 pusę, arba išjunkite ją prieigos taško sąsajoje su rašytine priežastimi.

Kas iš tikrųjų atsako 53 prievadu

Prieš keisdami konfigūraciją, išvardykite kiekvieną procesą, kuris klausosi 53 prievado. Pi, kuriame veikia vietinis resolver stub, Pi-hole ir bendrinimo pagalbininkas, klausytojų sąrašas yra vienintelis patikimas žemėlapis, kas atsako į užklausas:

sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip route

Pi-hole sąsajų vadovas aiškina, kad priėmimo režimas, apribotas viena sąsaja, vis tiek gali naudoti wildcard lizdą ir atmesti atvykstančius kitur. Tai nėra tas pats, kas susieti tik pasirinktas sąsajas, o būtent tokia tvarka numatyta, kai mašiną turi dalytis kita DNS tarnyba.

Du procesai paprastai negali susieti to paties adreso ir prievado, nors SO_REUSEPORT gali padaryti bendrą susiejimą sėkmingą; net tada wildcard klausytojas gali perimti atvykstančius, skirtus siauresnei tarnybai. Pasirinkite dokumentuotą režimą norimam vaidmeniui ir iš naujo paleiskite tarnybas numatyta tvarka.

Laikykite Pi-hole administravimo puslapį už prieigos taško tinklo. Klientams reikia resolverio, o ne žiniatinklio sąsajos ar API, galinčio pakeisti resolverio konfigūraciją.

Dvi DNS atšakos, kiekvienai po vieną politiką

Kliento užklausa keliauja iš telefono į Pi, o atskira užklausa keliauja iš Pi į jo aukštesnįjį resolverį. Maršrutizavimo taisyklė, atitinkanti persiunčiamą prieigos taško srautą, antrajai atšakai automatiškai netaikoma, nes Pi tą srautą generuoja vietiškai. Jei VPN turi perduoti DNS, vietiniam keliui reikia savo politikos.

Saugokitės ciklo. Pi-hole aukštesniojo resolverio nukreipimas į adresą, kurį aptarnauja pats Pi, tiesiogiai ar per prievado persiuntimą, sukuria užklausas, kurios sukasi, kol baigiasi laikas. Duokite jam tikrą aukštesnįjį resolverį arba sąlyginį forwarderį domenams, kuriems negali atsakyti.

Nuspręskite, kas nutinka, kai tunelis nukrenta. Grįžimas prie vietinio resolverio palaiko naršymą, bet gali nutekinti vardus už VPN ribų; blokavimas išlaiko politiką nepažeistą ir sutrikimą paverčia matoma klaida. Abu pasirinkimai yra apginami, tačiau juos reikia pasirinkti, o ne paveldėti iš numatytosios reikšmės.

Įrodykite kelią ir elgesį sutrikimo metu

Testuokite sluoksniais: klientas gauna adresą, klientas išsprendžia vardą per Pi, Pi išsprendžia per numatytą aukštesnįjį resolverį, o programa užbaigia užklausą. Sėkmingas ping nieko nesako apie DNS, o sėkminga paieška nieko nesako apie persiuntimą.

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

Tada sustabdykite tunelį ir pakartokite. Numatytas elgesys turėtų pasirodyti per kelias sekundes, o ne po rankinio Pi-hole ar prieigos taško tarnybos paleidimo iš naujo. Sutrikimo metu patikrinkite kliento resolverio nustatymą, nes antrinis viešas resolveris ir toliau atsakys, net kai politika tikėjosi klaidos.

Laikykite vieną savininką persiuntimui ir NAT ir patikrinkite jį iš kliento, o ne iš paties Pi. Užklausa, kuri sėkmingai palieka Pi, vis tiek gali būti atmesta grįžtant, o klientas yra vienintelė vieta, kur matomas visas kelias.