Pi hotspot Pi-hole'i ja VPN-iga: anna igale teenusele ülesanne
Otsusta, kellele kuuluvad DHCP, DNS ja pakettide edastamine, enne kui lubad ühel Pi-l kolm abilist. Topeltomanikud tekitavad konkureerivaid liise ja resolveri silmuseid.
Telefon liitub Pi hotspotiga, saab aadressi ja leht ikka ei laadi. Pi-l töötavad hotspoti abiline, Pi-hole ja VPN-klient ning igaüks neist arvab, et omab osa teekonnast. Enamik selliseid lahendusi ei ebaõnnestu mitte sellepärast, et komponent on katki, vaid sellepärast, et kaks komponenti teevad sama tööd. Enne nende häälestamist määra igale funktsioonile täpselt üks omanik.
Määra igale funktsioonile üks omanik
Siin on olulised neli funktsiooni ja igaüks vajab täpselt ühte omanikku. Allolev tabel nimetab funktsiooni, toimiva omaniku ja selle, mis läheb valesti, kui kaks teenust seda nõuavad.
| 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 |
Kattumine saabub tavaliselt üks pakett korraga. Hotspoti abiline paigaldab oma dnsmasqi eksemplari, Pi-hole tahab porti 53 ja VPN-klient lisab marsruute. Iga samm tundub eraldi mõistlik, kuid koos loovad need masina, kus teine käivituv teenus muudab vaikselt esimese käitumist.
Kirjuta omanikud üles enne, kui midagi muud lubad. Lühike tabel ehituse märkmetes takistab hilisemal paigaldusel üle võtta funktsiooni, millel oli juba omanik.
Vali üks vahemik ja hoia see tunnelist eemal
Vali hotspoti vahemik, Pi aadress selles, DHCP-vara ja resolver, mille kliendid saavad. Hoia see vahemik ülemisest LAN-ist ja VPN-tunneli vahemikust eraldi, sest kattuvad alamvõrgud muudavad marsruutimisprobleemi aadressitõlke projektiks. Tunneliga kattuv vahemik teeb Pi-st kahe identse prefiksi vahel juhusliku ruuteri. Kirjuta vahemik ja vara hotspoti konfiguratsiooni, selle asemel et jätta need vaikeväärtuse hooleks.
Kui hotspot kuulub NetworkManageri jagatud režiimile, kontrolli tegelikku ühendust enne DHCP-serveri lisamist. Jagatud režiim käivitab oma abilised ja lubab edastamise, seega on see selle liidese aadressiplaani omanik juba praegu. Teise serveri lisamine sellepärast, et see on saadaval, loob konkureerivaid pakkumisi, mitte varundust.
Otsusta IPv6 üle teadlikult. Ruuteri teated ja DHCPv6 tulevad paljudes seadetes teisest abilisest kui DHCPv4, ja kui jätad IPv6 sisse, samal ajal kui VPN-poliitika katab ainult IPv4, saavad kliendid tee, mis möödub tunnelist. Kas planeeri IPv6 pool või lülita see hotspoti liidesel kirjaliku põhjendusega välja.
Kes tegelikult vastab pordil 53
Loetle iga protsess, mis kuulab porti 53, enne konfiguratsiooni muutmist. Pi-l, kus töötavad kohalik resolveri stub, Pi-hole ja jagamise abiline, on kuulajate nimekiri ainus usaldusväärne kaart sellest, kes päringutele vastab:
sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip routePi-hole'i liideste juhend selgitab, et ühe liidesega piiratud vastuvõturežiim võib ikkagi kasutada metamärk-pistikut ja mujale saabuvaid pakette kõrvale heita. See ei ole sama, mis siduda ainult valitud liidesed, mis on kavandatud lahendus, kui teine DNS-teenus peab masinat jagama.
Kaks protsessi ei saa tavaliselt siduda sama aadressi ja porti, kuigi SO_REUSEPORT võib jagatud sidumise õnnestuda; isegi siis võib metamärk-kuulaja võtta kitsama teenuse jaoks mõeldud saabujaid. Vali soovitud rolli jaoks dokumenteeritud režiim ja taaskäivita teenused kavandatud järjekorras.
Hoia Pi-hole'i haldusleht hotspoti võrgust väljas. Klientidel on vaja resolverit, mitte veebiliidest või API-t, mis võib resolveri konfiguratsiooni muuta.
Kaks DNS-jalga, kummagi jaoks oma poliitika
Kliendi päring liigub telefonist Pi-le ja eraldi päring liigub Pi-lt selle ülemisele resolverile. Marsruutimisreegel, mis sobib edastatud hotspoti liiklusega, ei kehti automaatselt teisele jalale, sest Pi genereerib selle liikluse kohapeal. Kui VPN peab DNS-i kandma, vajab kohalik tee oma poliitikat.
Jälgi silmust. Pi-hole'i ülemise resolveri suunamine aadressile, mida Pi ise teenindab, otse või pordiedastuse kaudu, tekitab päringuid, mis ringlevad, kuni aeguvad. Anna sellele tõeline ülemine resolver või tingimuslik edastaja domeenidele, millele see ei suuda vastata.
Otsusta, mis juhtub, kui tunnel katkeb. Kohalikule resolverile naasmine hoiab sirvimise elus, kuid võib lekitada nimesid väljapoole VPN-i; blokeerimine hoiab poliitika puutumatuna ja muudab katkestuse nähtavaks veaks. Mõlemad valikud on kaitstavad, kuid see tuleb valida, mitte pärida vaikeväärtusest.
Tõesta tee ja katkestuse käitumine
Testi kihtide kaupa: klient saab aadressi, klient lahendab nime Pi kaudu, Pi lahendab kavandatud ülemise resolveri kaudu ja rakendus lõpetab päringu. Õnnestunud ping ei ütle midagi DNS-i kohta ja õnnestunud otsing ei ütle midagi edastamise kohta.
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.1Seejärel peata tunnel ja korda. Kavandatud käitumine peaks ilmuma mõne sekundi jooksul, mitte pärast Pi-hole'i või hotspoti teenuse käsitsi taaskäivitamist. Kontrolli katkestuse ajal kliendi resolveri seadet, sest teisene avalik resolver jätkab vastamist ka siis, kui poliitika eeldas ebaõnnestumist.
Hoia üks omanik edastamise ja NAT-i jaoks ning kontrolli seda kliendist, mitte Pi enda pealt. Päring, mis lahkub Pi-lt edukalt, võidakse tagasiteel siiski maha visata, ja klient on ainus koht, kus kogu tee on nähtav.