Pi hotspot Pi-hole-lal és VPN-nel: adj minden szolgáltatásnak saját feladatot

Egy telefon csatlakozik a Pi hotspotjához, címet kap, az oldal mégsem tölt be. A Pi hotspot-segédet, Pi-hole-t és VPN-klienst futtat, és mindegyik azt hiszi, hogy az útvonal egy részét birtokolja. Ezek a buildök többnyire nem azért hibásodnak meg, mert egy komponens tönkrement, hanem mert két komponens ugyanazt a feladatot végzi. Rendelj egy tulajdonost funkciónként, mielőtt bármelyiket beállítod.

Rendelj egy tulajdonost funkciónként

Itt négy funkció számít, és mindegyikhez pontosan egy tulajdonos kell. Az alábbi táblázat megnevezi a funkciót, egy működőképes tulajdonost, és azt, hogy mi romlik el, amikor két szolgáltatás igényt tart rá.

Az átfedés általában egyszerre egy csomaggal érkezik. A hotspot-segéd saját dnsmasq-példányt telepít, a Pi-hole az 53-as portot akarja, a VPN-kliens pedig útvonalakat ad hozzá. Minden lépés külön-külön ésszerűnek tűnik, együtt viszont olyan gépet alkotnak, ahol a másodikként induló szolgáltatás csendben megváltoztatja az első viselkedését.

Írd fel a tulajdonosokat, mielőtt bármi mást bekapcsolsz. Egy rövid táblázat a build-jegyzetekben megakadályozza, hogy egy későbbi telepítés átvegyen egy funkciót, amelynek már volt tulajdonosa.

Válassz egy tartományt, és tartsd távol az alagúttól

Válaszd ki a hotspot tartományát, a Pi címét benne, a DHCP-készletet és azt a resolvert, amelyet a kliensek kapnak. Tartsd ezt a tartományt külön a felsőbb LAN-tól és a VPN-alagút tartományától, mert az átfedő alhálózatok egy útválasztási problémát címfordítási projektté alakítanak. Az alagúttal átfedő tartomány véletlen routerré teszi a Pi-t két azonos prefix között. Írd be a tartományt és a készletet a hotspot konfigurációjába, ahelyett hogy alapértékre hagynád őket.

Ha a hotspotot a NetworkManager megosztott módja birtokolja, a DHCP-szerver hozzáadása előtt vizsgáld meg a tényleges kapcsolatot. A megosztott mód saját segédeket indít és bekapcsolja a továbbítást, tehát már ő a címtér tulajdonosa annál az interfésznél. Egy második szerver hozzáadása csak azért, mert elérhető, versengő ajánlatokat hoz létre, nem redundanciát.

Döntsd el az IPv6-ot szándékosan. Az útvonalhirdetések és a DHCPv6 sok beállításban más segédtől érkeznek, mint a DHCPv4, és ha az IPv6 bekapcsolva marad, miközben a VPN-házirend csak az IPv4-et fedi, a kliensek az alagutat megkerülő útvonalat kapnak. Vagy tervezd meg az IPv6 oldalt, vagy kapcsold ki a hotspot interfészen, írásos indoklással.

Ki válaszol valójában az 53-as porton

A konfiguráció módosítása előtt sorolj fel minden folyamatot, amely az 53-as porton figyel. Egy Pi-n, amely helyi resolver-stubot, Pi-hole-t és megosztási segédet futtat, a figyelők listája az egyetlen megbízható térkép arról, ki válaszol a lekérdezésekre:

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

A Pi-hole interfész-útmutatója elmagyarázza, hogy az egyetlen interfészre korlátozott fogadási mód továbbra is használhat wildcard socketet, és máshová érkező csomagokat dobhat el. Ez nem ugyanaz, mint csak a kiválasztott interfészekhez kötni, ami akkor szándékolt elrendezés, amikor egy másik DNS-szolgáltatásnak meg kell osztania a gépet.

Két folyamat általában nem kötheti ugyanazt a címet és portot, bár a SO_REUSEPORT sikeressé tehet egy megosztott kötést; még akkor is elvehet egy wildcard figyelő a szűkebb szolgáltatásnak szánt csomagokat. Válaszd ki a kívánt szerephez dokumentált módot, és indítsd újra a szolgáltatásokat a szándékolt sorrendben.

Tartsd a Pi-hole adminisztrációs oldalát a hotspot hálózatán kívül. A klienseknek resolver kell, nem a webes felület vagy API, amely megváltoztathatja a resolver konfigurációját.

Két DNS-szakasz, mindegyiknek saját házirend

Egy kliens lekérdezése a telefontól a Pi-ig utazik, egy külön lekérdezés pedig a Pi-től a felsőbb resolveréig. Az átirányított hotspot-forgalomra illeszkedő útválasztási szabály nem vonatkozik automatikusan a második szakaszra, mert a Pi azt a forgalmat helyben állítja elő. Ha a VPN-nek DNS-t kell szállítania, a helyi útvonalnak saját házirendre van szüksége.

Figyelj a hurokra. A Pi-hole felsőbb resolverének egy olyan címre irányítása, amelyet maga a Pi szolgál ki, közvetlenül vagy port-forwardon keresztül, olyan lekérdezéseket hoz létre, amelyek addig keringenek, amíg le nem járnak. Adj neki valódi felsőbb resolvert vagy feltételes forwardert azokhoz a domainekhez, amelyekre nem tud válaszolni.

Döntsd el, mi történik, amikor az alagút kiesik. A helyi resolverre való visszaesés életben tartja a böngészést, de kiszivárogtathatja a neveket a VPN-en kívülre; a blokkolás megőrzi a házirendet, és látható hibává teszi a kiesést. Mindkét választás védhető, de választani kell, nem pedig alapértékből örökölni.

Bizonyítsd az útvonalat és a kiesés alatti viselkedést

Rétegenként tesztelj: a kliens címet kap, a kliens felold egy nevet a Pi-n keresztül, a Pi a szándékolt felsőbb resolveren keresztül old fel, és egy alkalmazás befejez egy kérést. A sikeres ping semmit sem mond a DNS-ről, a sikeres keresés pedig semmit sem mond a továbbításról.

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

Aztán állítsd le az alagutat, és ismételd meg. A szándékolt viselkedésnek néhány másodpercen belül meg kell jelennie, nem a Pi-hole vagy a hotspot-szolgáltatás kézi újraindítása után. A kiesés alatt ellenőrizd a kliens resolver-beállítását, mert egy másodlagos nyilvános resolver akkor is válaszol, amikor a házirend hibát várt.

Tartsd egy tulajdonosnál a továbbítást és a NAT-ot, és kliensről ellenőrizd, ne magáról a Pi-ről. Egy kérés, amely sikeresen elhagyja a Pi-t, a visszaúton még eldobható, és a kliens az egyetlen hely, ahol a teljes útvonal látszik.