Pi-hotspot kun Pi-hole kaj VPN: atribuu al ĉiu servo taskon

Telefono aliĝas al la hotspot de la Pi, ricevas adreson, kaj la paĝo ankoraŭ fiaskas. La Pi rulas hotspot-helpan programon, Pi-hole kaj VPN-klienton, kaj ĉiu konsideras sin posedanto de parto de la vojo. Plej multaj el tiuj konstruoj fiaskas ne ĉar komponento estas rompita, sed ĉar du komponentoj faras la saman laboron. Atribuu unu posedanton por ĉiu funkcio antaŭ ol agordi iun ajn el ili.

Atribuu unu posedanton por ĉiu funkcio

Kvar funkcioj gravas ĉi tie, kaj ĉiu bezonas precize unu posedanton. La suba tabelo nomas la funkcion, uzeblan posedanton kaj tion, kio misfunkcias kiam du servoj postulas ĝin.

La koincido kutime alvenas unu paketon samtempe. La hotspot-helpilo instalas sian propran dnsmasq-instancon, Pi-hole volas pordon 53, kaj la VPN-kliento aldonas itinerojn. Ĉiu paŝo aspektas prudenta sole, kaj kune ili produktas maŝinon, en kiu la dua servo, kiu ekfunkcias, kviete ŝanĝas la konduton de la unua.

Skribu la posedantojn antaŭ ol ŝalti ion ajn alian. Mallonga tabelo en la konstruaj notoj malhelpas al posta instalado transpreni funkcion, kiu jam havis posedanton.

Elektu unu gamon kaj tenu ĝin for de la tunelo

Elektu la hotspot-gamon, la adreson de la Pi en ĝi, la DHCP-basenon kaj la solvilon, kiun ricevas la klientoj. Tenu tiun gamon aparte de la supra LAN kaj de la VPN-tunela gamo, ĉar koincidantaj subretoj igas itineran problemon projekto pri adres-tradukado. Gamo, kiu koincidas kun la tunelo, igas la Pi hazarda enkursigilo inter du identaj prefiksoj. Skribu la gamon kaj la basenon en la hotspot-agordon anstataŭ lasi ilin al apriora valoro.

Se la komuna reĝimo de NetworkManager posedas la hotspoton, kontrolu la efektivan konekton antaŭ ol aldoni DHCP-servilon. La komuna reĝimo lanĉas proprajn helpilojn kaj ebligas plusendadon, do ĝi jam estas la posedanto de la adresa plano por tiu interfaco. Aldoni duan servilon ĉar ĝi disponeblas kreas konkurantajn ofertojn anstataŭ rezervon.

Decidu pri IPv6 konscie. Enkursigilaj anoncoj kaj DHCPv6 en multaj agordoj venas de alia helpilo ol DHCPv4, kaj lasi IPv6 ŝaltita dum la VPN-politiko kovras nur IPv4 donas al klientoj vojon, kiu preterpasas la tunnelon. Aŭ planu la IPv6-flankon, aŭ malŝaltu ĝin sur la hotspot-interfaco kun skriba kialo.

Kiu efektive respondas sur pordo 53

Listigu ĉiun procezon, kiu aŭskultas sur pordo 53, antaŭ ol ŝanĝi agordon. Sur Pi, kiu rulas lokan solvilo-stub, Pi-hole kaj kunhavigan helpilon, la aŭskultanta listo estas la sola fidinda mapo de tio, kiu respondas al petoj:

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

La interfaca gvidilo de Pi-hole klarigas, ke akcepta reĝimo limigita al unu interfaco ankoraŭ povas uzi sovaĝkartan ingon kaj forĵeti alvenojn aliloke. Tio ne samas kiel ligi nur elektitajn interfacojn, kio estas la aranĝo celata kiam alia DNS-servo devas kunhavigi la maŝinon.

Du procezoj kutime ne povas ligi la saman adreson kaj pordon, kvankam SO_REUSEPORT povas igi komunan ligon sukcesi; eĉ tiam sovaĝkarta aŭskultanto povas preni alvenojn destinitajn por la pli mallarĝa servo. Elektu la dokumentitan reĝimon por la rolo, kiun vi volas, kaj restartigu la servojn en la celita ordo.

Tenu la administran paĝon de Pi-hole ekster la hotspot-reto. Klientoj bezonas solvilon, ne la retan interfacon aŭ API-on, kiu povas ŝanĝi la agordon de la solvilo.

Du DNS-kruroj, unu politiko ĉiu

Klienta peto vojaĝas de la telefono al la Pi, kaj aparta peto vojaĝas de la Pi al sia supra solvilo. Itinera regulo, kiu kongruas kun plusendita hotspot-trafiko, ne aŭtomate aplikiĝas al la dua kruro, ĉar la Pi generas tiun trafikon loke. Se la VPN devas porti DNS, la loka vojo bezonas sian propran politikon.

Atentu buklon. Montri la supran solvilon de Pi-hole al adreso, kiun la Pi mem servas, rekte aŭ per pordplusendo, produktas petojn, kiuj cirkulas ĝis ili tempas. Donu al ĝi realan supran solvilon aŭ kondiĉan plusendilon por la domajnoj, kiujn ĝi ne povas respondi.

Decidu, kio okazas kiam la tunelo falas. Reiri al la loka solvilo tenas retumadon viva sed povas liki nomojn ekster la VPN; blokado konservas la politikon sendifekta kaj igas la haltiĝon videbla eraro. Ambaŭ elektoj estas defendeblaj, sed ĝi devas esti elektita anstataŭ heredita de apriora valoro.

Pruvu la vojon kaj la konduton ĉe haltiĝo

Testu laŭ tavoloj: la kliento ricevas adreson, la kliento solvas nomon tra la Pi, la Pi solvas tra la celita supra solvilo, kaj aplikaĵo kompletigas peton. Sukcesa ping diras nenion pri DNS, kaj sukcesa serĉo diras nenion pri plusendado.

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

Poste haltigu la tunnelon kaj ripetu. La celita konduto devus aperi ene de kelkaj sekundoj, ne post permana restartigo de Pi-hole aŭ de la hotspot-servo. Kontrolu la solvilo-agordon de la kliento dum la haltiĝo, ĉar sekundara publika solvilo daŭre respondos eĉ kiam la politiko atendis malsukceson.

Tenu unu posedanton por plusendado kaj NAT kaj kontrolu ĝin el kliento, ne el la Pi mem. Peto, kiu sukcese forlasas la Pi, tamen povas esti forĵetita sur la revena vojo, kaj la kliento estas la sola loko, kie la tuta vojo videblas.