Pi hotspot s Pi-holeom i VPN-om: dodijelite svakoj usluzi zadatak
Odlučite ko posjeduje DHCP, DNS i prosljeđivanje paketa prije nego što uključite tri pomoćnika na jednom Pi-ju. Dvostruki vlasnici stvaraju konkurentske zakupe adresa i petlje u razrješivaču.
Telefon se pridruži hotspotu Pi-ja, dobije adresu, a stranica i dalje ne radi. Na Pi-ju rade pomoćnik za hotspot, Pi-hole i VPN klijent, i svaki od njih vjeruje da posjeduje dio puta. Većina ovakvih postavki ne pada zato što je komponenta pokvarena, nego zato što dvije komponente rade isti posao. Dodijelite jednog vlasnika po funkciji prije nego što podesite bilo koju od njih.
Dodijelite jednog vlasnika po funkciji
Ovdje su važne četiri funkcije i svakoj treba tačno jedan vlasnik. Tabela ispod navodi funkciju, izvodljivog vlasnika i šta pođe po zlu kada dvije usluge polažu pravo na nju.
| 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 stiže jedan paket po jedan. Pomoćnik za hotspot instalira vlastitu instancu dnsmasqa, Pi-hole traži port 53, a VPN klijent dodaje rute. Svaki korak sam po sebi izgleda razumno, a zajedno stvaraju mašinu u kojoj druga usluga koja se pokrene tiho mijenja ponašanje prve.
Zapišite vlasnike prije nego što uključite bilo šta drugo. Kratka tabela u bilješkama o izradi sprječava da kasnija instalacija preuzme funkciju koja je već imala vlasnika.
Odaberite jedan raspon i držite ga dalje od tunela
Odaberite raspon hotspota, adresu Pi-ja u njemu, DHCP bazen i razrješivač koji klijenti dobijaju. Držite taj raspon odvojeno od uzvodnog LAN-a i od raspona VPN tunela, jer podudarne podmreže pretvaraju problem rutiranja u projekat prevođenja adresa. Raspon koji se preklapa s tunelom čini Pi slučajnim ruterom između dva identična prefiksa. Upišite raspon i bazen u konfiguraciju hotspota umjesto da ih prepustite zadanoj vrijednosti.
Ako hotspotom upravlja zajednički režim NetworkManagera, pregledajte efektivnu vezu prije dodavanja DHCP servera. Zajednički režim pokreće vlastite pomoćnike i omogućava prosljeđivanje, pa je već vlasnik adresnog plana za taj interfejs. Dodavanje drugog servera zato što je dostupan stvara konkurentske ponude, a ne rezervu.
Odlučite o IPv6 svjesno. Najave rutera 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 put koji zaobilazi tunel. Ili isplanirajte stranu IPv6 ili je isključite na interfejsu hotspota uz napisan razlog.
Ko zapravo odgovara na portu 53
Navedite svaki proces koji sluša na portu 53 prije nego što promijenite konfiguraciju. Na Pi-ju na kojem rade lokalni razrješivač-stub, Pi-hole i pomoćnik za dijeljenje, lista slušalaca je jedina pouzdana mapa ko odgovara na upite:
sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip routePi-holeov vodič kroz interfejse objašnjava da režim prijema ograničen na jedan interfejs i dalje može koristiti univerzalni socket i odbaciti dolaske na drugim mjestima. To nije isto kao vezivanje samo za odabrane interfejse, a to je raspored predviđen kada druga DNS usluga mora dijeliti mašinu.
Dva procesa obično ne mogu vezati istu adresu i port, iako SO_REUSEPORT može učiniti da zajedničko vezivanje uspije; čak i tada univerzalni slušalac može preuzeti dolaske namijenjene užoj usluzi. Odaberite dokumentovani režim za ulogu koju želite i ponovo pokrenite usluge u predviđenom redoslijedu.
Držite administrativnu stranicu Pi-holea izvan mreže hotspota. Klijentima treba razrješivač, a ne web interfejs ili API koji može promijeniti konfiguraciju razrješivača.
Dvije DNS noge, po jedno pravilo za svaku
Upit klijenta putuje od telefona do Pi-ja, a poseban upit putuje od Pi-ja do njegovog uzvodnog razrješivača. Pravilo rutiranja koje odgovara proslijeđenom hotspot saobraćaju ne primjenjuje se automatski na drugu nogu, jer Pi taj saobraćaj stvara lokalno. Ako VPN treba da nosi DNS, lokalni put treba vlastito pravilo.
Pazite na petlju. Usmjeravanje Pi-holeovog uzvodnog razrješivača na adresu koju sam Pi poslužuje, direktno ili kroz prosljeđivanje porta, stvara upite koji kruže dok ne isteknu. Dajte mu pravi uzvodni razrješivač ili uslovni prosljeđivač za domene na koje ne može odgovoriti.
Odlučite šta se dogodi kada tunel padne. Vraćanje na lokalni razrješivač održava pregledanje živim, ali može izložiti imena izvan VPN-a; blokiranje čuva pravilo i pretvara prekid u vidljivu grešku. Svaki izbor je odbranjiv, ali mora biti odabran, a ne naslijeđen iz zadane vrijednosti.
Dokažite put i ponašanje pri prekidu
Testirajte po slojevima: klijent dobije adresu, klijent razriješi ime kroz Pi, Pi razriješi kroz predviđeni uzvodni razrješivač, a aplikacija dovrši zahtjev. Uspješan ping ne govori ništa o DNS-u, a uspješna pretraga 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. Predviđeno ponašanje treba da se pojavi u nekoliko sekundi, a ne nakon ručnog ponovnog pokretanja Pi-holea ili usluge hotspota. Provjerite postavku razrješivača klijenta tokom prekida, jer će sekundarni javni razrješivač nastaviti odgovarati čak i kada je pravilo očekivalo neuspjeh.
Držite jednog vlasnika za prosljeđivanje i NAT i provjerite ga s klijenta, a ne sa samog Pi-ja. Zahtjev koji uspješno napusti Pi ipak može biti odbačen na povratnom putu, a klijent je jedino mjesto gdje je cijeli put vidljiv.