Pi hotspot s Pi-holeom i VPN-om: dodijelite svakoj usluzi vlastiti posao
Odlučite tko posjeduje DHCP, DNS i prosljeđivanje paketa prije nego što uključite tri pomoćnika na jednom Pi. Dvostruki vlasnici stvaraju konkurentne leaseove i petlje u resolveru.
Telefon se pridružuje hotspotu Pi, dobiva adresu, a stranica još uvijek ne uspijeva. Pi pokreće pomoćnika za hotspot, Pi-hole i VPN klijent, a svaki od njih misli da posjeduje dio putanje. Većina ovih postavki ne pada zato što je komponenta pokvarena, nego zato što dvije komponente rade isti posao. Dodijelite jednog vlasnika po funkciji prije nego što bilo što od toga podesite.
Dodijelite jednog vlasnika po funkciji
Ovdje su važne četiri funkcije i svakoj treba točno jedan vlasnik. Tablica u nastavku navodi funkciju, izvedivog vlasnika i što pođe po zlu kada je polažu dvije usluge.
| 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 |
Preklapanje obično dolazi jedan paket po jedan. Pomoćnik za hotspot instalira vlastitu instancu dnsmasq, Pi-hole želi port 53, a VPN klijent dodaje rute. Svaki korak izgleda razumno sam za sebe, a zajedno daju stroj u kojem druga usluga koja se pokrene tiho mijenja ponašanje prve.
Zapišite vlasnike prije nego što uključite bilo što drugo. Kratka tablica u bilješkama o izgradnji sprječava da kasnija instalacija preuzme funkciju koja je već imala vlasnika.
Odaberite jedan raspon i držite ga podalje od tunela
Odaberite raspon hotspota, adresu Pi u njemu, DHCP pool i resolver koji klijenti dobivaju. Držite taj raspon odvojen od uzvodnog LAN-a i od raspona VPN tunela, jer preklapajuće podmreže pretvaraju problem usmjeravanja u projekt prevođenja adresa. Raspon koji se preklapa s tunelom čini Pi slučajnim usmjerivačem između dva identična prefiksa. Upišite raspon i pool u konfiguraciju hotspota umjesto da ih prepustite zadanoj vrijednosti.
Ako dijeljeni način rada NetworkManagera posjeduje hotspot, pregledajte stvarnu vezu prije dodavanja DHCP poslužitelja. Dijeljeni način rada pokreće vlastite pomoćnike i uključuje prosljeđivanje, pa je već vlasnik plana adresa za to sučelje. Dodavanje drugog poslužitelja zato što je dostupan stvara konkurentne ponude umjesto redundancije.
Odluku o IPv6 donesite namjerno. Najave usmjerivača i DHCPv6 u mnogim postavkama dolaze od drugog pomoćnika nego DHCPv4, a ostavljanje IPv6 uključenog dok VPN pravilo pokriva samo IPv4 daje klijentima putanju koja zaobilazi tunel. Ili isplanirajte IPv6 stranu ili je onemogućite na sučelju hotspota s napisanim razlogom.
Tko zapravo odgovara na portu 53
Navedite svaki proces koji sluša na portu 53 prije nego što promijenite konfiguraciju. Na Pi koji pokreće lokalni resolver stub, Pi-hole i pomoćnika za dijeljenje, popis slušatelja jedina je pouzdana karta tko odgovara na upite:
sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip routeVodič kroz sučelja Pi-holea objašnjava da način primanja ograničen na jedno sučelje i dalje može koristiti wildcard socket i odbacivati dolaske drugdje. To nije isto kao vezanje samo odabranih sučelja, što je raspored namijenjen kada druga DNS usluga mora dijeliti stroj.
Dva procesa obično ne mogu vezati istu adresu i port, iako SO_REUSEPORT može učiniti da dijeljeno vezanje uspije; čak i tada, wildcard slušatelj može preuzeti dolaske namijenjene užoj usluzi. Odaberite dokumentirani način za ulogu koju želite i ponovno pokrenite usluge željenim redoslijedom.
Držite administracijsku stranicu Pi-holea izvan hotspot mreže. Klijentima treba resolver, a ne web sučelje ili API koji može promijeniti konfiguraciju resolvera.
Dvije DNS dionice, svaka sa svojim pravilom
Upit klijenta putuje s telefona na Pi, a zaseban upit putuje s Pi na njegov uzvodni resolver. Pravilo usmjeravanja koje odgovara proslijeđenom prometu hotspota ne primjenjuje se automatski na drugu dionicu, jer Pi taj promet generira lokalno. Ako VPN treba prenositi DNS, lokalna putanja treba vlastito pravilo.
Pazite na petlju. Usmjeravanje Pi-holeovog uzvodnog resolvera na adresu koju poslužuje sam Pi, izravno ili preko port-forwarda, stvara upite koji kruže dok ne isteknu. Dajte mu pravi uzvodni resolver ili uvjetni forwarder za domene na koje ne može odgovoriti.
Odlučite što se događa kada tunel padne. Vraćanje na lokalni resolver održava pregledavanje živim, ali može procuriti imena izvan VPN-a; blokiranje održava pravilo netaknutim i pretvara ispad u vidljivu pogrešku. Oba izbora su obranjiva, ali moraju se odabrati, a ne naslijediti iz zadane vrijednosti.
Dokažite putanju i ponašanje pri ispadu
Testirajte po slojevima: klijent dobiva adresu, klijent razrješava ime preko Pi, Pi razrješava preko željenog uzvodnog resolvera, a aplikacija dovršava zahtjev. Uspješan ping ne govori ništa o DNS-u, a uspješno razrješavanje ne govori ništa o prosljeđivanju.
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.1Zatim zaustavite tunel i ponovite. Željeno ponašanje trebalo bi se pojaviti u nekoliko sekundi, a ne nakon ručnog ponovnog pokretanja Pi-holea ili usluge hotspota. Provjerite postavku resolvera na klijentu tijekom ispada, jer će sekundarni javni resolver nastaviti odgovarati čak i kada je pravilo očekivalo pogrešku.
Zadržite jednog vlasnika za prosljeđivanje i NAT i provjerite ga s klijenta, a ne s Pi samog. Zahtjev koji uspješno napusti Pi još uvijek može biti odbačen na povratku, a klijent je jedino mjesto gdje je cijela putanja vidljiva.