Pi-hotspot Pi-holen ja VPN:n kanssa: anna jokaiselle palvelulle tehtävä

Puhelin liittyy Pi:n hotspotiin, saa osoitteen, ja sivu epäonnistuu silti. Pi:llä pyörivät hotspot-apuri, Pi-hole ja VPN-asiakas, ja jokainen uskoo omistavansa osan reitistä. Useimmat näistä kokoonpanoista epäonnistuvat, ei siksi että komponentti on rikki, vaan siksi, että kaksi komponenttia tekee saman työn. Määritä jokaiselle toiminnolle yksi omistaja ennen kuin säädät mitään niistä.

Määritä jokaiselle toiminnolle yksi omistaja

Tässä on tärkeää neljä toimintoa, ja jokainen tarvitsee täsmälleen yhden omistajan. Alla oleva taulukko nimeää toiminnon, toimivan omistajan ja sen, mikä menee pieleen, kun kaksi palvelua vaatii sitä.

Päällekkäisyys saapuu yleensä yksi paketti kerrallaan. Hotspot-apuri asentaa oman dnsmasq-instanssinsa, Pi-hole haluaa portin 53 ja VPN-asiakas lisää reittejä. Jokainen askel näyttää yksinään järkevältä, ja yhdessä ne tuottavat koneen, jossa toisena käynnistyvä palvelu muuttaa hiljaa ensimmäisen käytöstä.

Kirjoita omistajat muistiin ennen kuin otat mitään muuta käyttöön. Lyhyt taulukko kokoonpanomuistiinpanoissa estää myöhempää asennusta ottamasta haltuunsa toimintoa, jolla oli jo omistaja.

Valitse yksi alue ja pidä se kaukana tunnelista

Valitse hotspotin alue, Pi:n osoite siinä, DHCP-varanto ja resolver, jonka asiakkaat saavat. Pidä tämä alue erillään yläpuolisesta LAN-verkosta ja VPN-tunnelin alueesta, koska päällekkäiset aliverkot muuttavat reititysongelman osoitteenkäännösprojektiksi. Tunnelin kanssa päällekkäinen alue tekee Pi:stä vahingossa reitittimen kahden samanlaisen etuliitteen välille. Kirjoita alue ja varanto hotspotin kokoonpanoon sen sijaan, että jättäisit ne oletusarvon varaan.

Jos hotspot kuuluu NetworkManagerin jaettuun tilaan, tutki tehollinen yhteys ennen DHCP-palvelimen lisäämistä. Jaettu tila käynnistää omat apurinsa ja ottaa välityksen käyttöön, joten se on jo kyseisen liitännän osoitesuunnitelman omistaja. Toisen palvelimen lisääminen siksi, että se on saatavilla, luo kilpailevia tarjouksia redundanssin sijaan.

Päätä IPv6:sta tietoisesti. Reitittimen ilmoitukset ja DHCPv6 tulevat monissa kokoonpanoissa eri apurilta kuin DHCPv4, ja jos IPv6 jätetään päälle samalla kun VPN-käytäntö kattaa vain IPv4:n, asiakkaat saavat reitin, joka ohittaa tunnelin. Joko suunnittele IPv6-puoli tai poista se käytöstä hotspot-liitännässä kirjallisen syyn kanssa.

Kuka itse asiassa vastaa portilla 53

Listaa jokainen prosessi, joka kuuntelee porttia 53, ennen kuin muutat kokoonpanoa. Pi:llä, jolla pyörivät paikallinen resolver-stub, Pi-hole ja jakamisapuri, kuuntelijoiden lista on ainoa luotettava kartta siitä, kuka vastaa kyselyihin:

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

Pi-holen liitäntäopas selittää, että yhteen liitäntään rajattu vastaanottotila voi silti käyttää jokeripistoketta ja hylätä muualle saapuvia. Tämä ei ole sama kuin vain valittujen liitäntöjen sitominen, ja juuri se järjestely on tarkoitettu, kun toisen DNS-palvelun on jaettava kone.

Kaksi prosessia ei yleensä voi sitoa samaa osoitetta ja porttia, vaikka SO_REUSEPORT voi saada jaetun sidonnan onnistumaan; silloinkaan jokerikuuntelija voi ottaa kapeammalle palvelulle tarkoitettuja saapuvia. Valitse haluamallesi roolille dokumentoitu tila ja käynnistä palvelut uudelleen aiotussa järjestyksessä.

Pidä Pi-holen hallintasivu poissa hotspot-verkosta. Asiakkaat tarvitsevat resolverin, eivät verkkoliittymää tai API:a, joka voi muuttaa resolverin kokoonpanoa.

Kaksi DNS-jalkaa, kummallekin oma käytäntö

Asiakaskysely matkaa puhelimesta Pi:lle, ja erillinen kysely matkaa Pi:ltä sen yläpuoliselle resolverille. Reitityssääntö, joka täsmää välitettyyn hotspot-liikenteeseen, ei automaattisesti päde toiseen jalkaan, koska Pi tuottaa tämän liikenteen paikallisesti. Jos VPN:n on kuljetettava DNS, paikallinen reitti tarvitsee oman käytäntönsä.

Varo silmukkaa. Pi-holen yläpuolisen resolverin osoittaminen osoitteeseen, jota Pi itse palvelee, suoraan tai portin välityksellä, tuottaa kyselyitä, jotka kiertävät kunnes ne vanhenevat. Anna sille todellinen yläpuolinen resolver tai ehdollinen välittäjä verkkotunnuksille, joihin se ei voi vastata.

Päätä, mitä tapahtuu, kun tunneli putoaa. Paikalliseen resolveriin palaaminen pitää selailun henkitoreissaan mutta voi vuotaa nimiä VPN:n ulkopuolelle; estäminen pitää käytännön ehjänä ja tekee katkoksesta näkyvän virheen. Kumpikin valinta on puolustettavissa, mutta se on valittava eikä perittävä oletusarvosta.

Todista reitti ja katkoksen käyttäytyminen

Testaa kerroksittain: asiakas saa osoitteen, asiakas selvittää nimen Pi:n kautta, Pi selvittää aiottua yläpuolista resolveria käyttäen, ja sovellus saa pyynnön valmiiksi. Onnistunut ping ei kerro mitään DNS:stä, eikä onnistunut haku kerro mitään välityksestä.

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

Pysäytä sitten tunneli ja toista. Aiotun käyttäytymisen pitäisi näkyä muutamassa sekunnissa, ei Pi-holen tai hotspot-palvelun manuaalisen uudelleenkäynnistyksen jälkeen. Tarkista asiakkaan resolver-asetus katkoksen aikana, koska toissijainen julkinen resolver jatkaa vastaamista, vaikka käytäntö odotti epäonnistumista.

Pidä yksi omistaja välitykselle ja NAT:lle ja tarkista se asiakkaalta, ei Pi:ltä itseltään. Pyyntö, joka lähtee Pi:ltä onnistuneesti, voidaan silti pudottaa paluumatkalla, ja asiakas on ainoa paikka, jossa koko reitti on näkyvissä.