Hotspot Pi s Pi-hole in VPN: vsaki storitvi dodelite svojo nalogo
Odločite, kdo ima DHCP, DNS in posredovanje paketov, preden na enem Pi omogočite tri pomočnike. Podvojeni lastniki ustvarjajo konkurenčne lease in zanke v resolverju.
Telefon se pridruži hotspotu Pi, dobi naslov, stran pa še vedno ne deluje. Pi poganja pomočnika za hotspot, Pi-hole in odjemalca VPN, vsak od njih pa misli, da ima del poti. Večina teh postavitev ne odpove zato, ker bi bila komponenta pokvarjena, ampak zato, ker dve komponenti opravljata isto delo. Vsaki funkciji dodelite enega lastnika, preden katero koli od njih nastavite.
Vsaki funkciji dodelite enega lastnika
Tu štejejo štiri funkcije in vsaka potrebuje natanko enega lastnika. Spodnja tabela navaja funkcijo, izvedljivega lastnika in kaj gre narobe, ko jo zahtevata dve storitvi.
| 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 |
Prekrivanje običajno prihaja en paket naenkrat. Pomočnik za hotspot namesti svojo instanco dnsmasq, Pi-hole želi vrata 53, odjemalec VPN pa doda poti. Vsak korak je sam po sebi videti smiseln, skupaj pa ustvarijo stroj, v katerem druga zagnana storitev tiho spremeni vedenje prve.
Lastnike zapišite, preden omogočite karkoli drugega. Kratka tabela v zapiskih o postavitvi prepreči, da bi poznejša namestitev prevzela funkcijo, ki je že imela lastnika.
Izberite en obseg in ga držite stran od tunela
Izberite obseg hotspota, naslov Pi v njem, nabor DHCP in resolver, ki ga prejmejo odjemalci. Ta obseg držite ločen od nadrejenega LAN in od obsega tunela VPN, ker prekrivajoče se podmreže spremenijo težavo usmerjanja v projekt prevajanja naslovov. Obseg, ki se prekriva s tunelom, naredi Pi naključni usmerjevalnik med dvema enakima predponama. Obseg in nabor zapišite v konfiguracijo hotspota, namesto da ju prepustite privzeti vrednosti.
Če hotspot ima v lasti skupni način NetworkManagerja, pred dodajanjem strežnika DHCP preglejte dejansko povezavo. Skupni način zažene svoje pomočnike in omogoči posredovanje, zato je že lastnik načrta naslovov za ta vmesnik. Dodajanje drugega strežnika, ker je na voljo, ustvari konkurenčne ponudbe namesto redundanse.
O IPv6 odločite namerno. Objave usmerjevalnika in DHCPv6 v mnogih postavitvah prihajajo od drugega pomočnika kot DHCPv4, puščanje IPv6 vklopljenega, medtem ko pravilnik VPN pokriva le IPv4, pa odjemalcem da pot, ki obide tunel. Bodisi načrtujte stran IPv6 bodisi jo na vmesniku hotspota onemogočite s pisnim razlogom.
Kdo v resnici odgovarja na vratih 53
Preden spremenite konfiguracijo, naštejte vsak proces, ki posluša na vratih 53. Na Pi, ki poganja lokalni resolver stub, Pi-hole in pomočnika za skupno rabo, je seznam poslušalcev edini zanesljiv zemljevid, kdo odgovarja na poizvedbe:
sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip routeVodnik po vmesnikih Pi-hole razlaga, da lahko način sprejemanja, omejen na en vmesnik, še vedno uporablja wildcard socket in zavrača prihode drugje. To ni isto kot vezava le na izbrane vmesnike, kar je ureditev, namenjena takrat, ko mora stroj deliti druga storitev DNS.
Dva procesa običajno ne moreta vezati istega naslova in vrat, čeprav lahko SO_REUSEPORT povzroči, da skupna vezava uspe; tudi takrat lahko wildcard poslušalec prevzame prihode, namenjene ožji storitvi. Izberite dokumentirani način za vlogo, ki jo želite, in znova zaženite storitve v predvidenem vrstnem redu.
Administracijsko stran Pi-hole držite zunaj omrežja hotspota. Odjemalci potrebujejo resolver, ne spletnega vmesnika ali API-ja, ki lahko spremeni konfiguracijo resolverja.
Dve veji DNS, vsaka s svojim pravilnikom
Poizvedba odjemalca potuje s telefona na Pi, ločena poizvedba pa s Pi na njegov nadrejeni resolver. Pravilo usmerjanja, ki ustreza posredovanemu prometu hotspota, se ne uporabi samodejno za drugo vejo, ker Pi ta promet ustvari lokalno. Če naj VPN prenaša DNS, potrebuje lokalna pot svoj pravilnik.
Pazite na zanko. Usmerjanje nadrejenega resolverja Pi-hole na naslov, ki ga streže sam Pi, neposredno ali prek port-forwarda, ustvari poizvedbe, ki krožijo, dokler ne poteče čas. Dajte mu pravi nadrejeni resolver ali pogojni forwarder za domene, na katere ne more odgovoriti.
Odločite, kaj se zgodi, ko tunel pade. Vrnitev na lokalni resolver ohrani brskanje živo, lahko pa razkrije imena zunaj VPN; blokiranje ohrani pravilnik nedotaknjen in izpad spremeni v vidno napako. Obe izbiri sta zagovorljivi, vendar ju je treba izbrati, ne pa podedovati iz privzete vrednosti.
Dokažite pot in vedenje ob izpadu
Testirajte po plasteh: odjemalec dobi naslov, odjemalec razreši ime prek Pi, Pi razreši prek predvidenega nadrejenega resolverja in aplikacija zaključi zahtevo. Uspešen ping ne pove nič o DNS, uspešno iskanje pa ne pove nič o posredovanju.
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.1Nato tunel ustavite in ponovite. Predvideno vedenje bi se moralo pojaviti v nekaj sekundah, ne po ročnem ponovnem zagonu Pi-hole ali storitve hotspota. Med izpadom preverite nastavitev resolverja pri odjemalcu, ker bo sekundarni javni resolver še naprej odgovarjal, tudi ko je pravilnik pričakoval napako.
Ohranite enega lastnika za posredovanje in NAT ter ga preverite z odjemalca, ne s Pi samega. Zahteva, ki uspešno zapusti Pi, je lahko na poti nazaj še vedno zavržena, odjemalec pa je edino mesto, kjer je vidna cela pot.