Pi hotspot ar Pi-hole un VPN: piešķiriet katram pakalpojumam savu uzdevumu
Pirms trīs palīgu ieslēgšanas vienā Pi izlemiet, kam pieder DHCP, DNS un pakešu pāradresēšana. Dublēti īpašnieki rada konkurējošas nomāšanas un resolvera cilpas.
Tālrunis pievienojas Pi hotspotam, saņem adresi, un lapa joprojām neielādējas. Pi palaiž hotspota palīgu, Pi-hole un VPN klientu, un katrs no tiem domā, ka pārvalda daļu ceļa. Lielākā daļa šādu montāžu neizdodas nevis salūzuša komponenta dēļ, bet tāpēc, ka divi komponenti dara vienu un to pašu darbu. Pirms jebkura no tiem regulēšanas piešķiriet katrai funkcijai vienu īpašnieku.
Piešķiriet katrai funkcijai vienu īpašnieku
Šeit svarīgas ir četras funkcijas, un katrai vajadzīgs tieši viens īpašnieks. Tabulā zemāk norādīta funkcija, derīgs īpašnieks un tas, kas noiet greizi, kad uz to pretendē divi pakalpojumi.
| 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 |
Pārklāšanās parasti nāk pa vienam paketam. Hotspota palīgs instalē savu dnsmasq eksemplāru, Pi-hole grib portu 53, un VPN klients pievieno maršrutus. Katrs solis atsevišķi šķiet saprātīgs, un kopā tie rada mašīnu, kurā otrais palaistais pakalpojums klusi maina pirmā uzvedību.
Pierakstiet īpašniekus, pirms ieslēdzat ko citu. Īsa tabula montāžas piezīmēs neļauj vēlākai instalācijai pārņemt funkciju, kurai jau bija īpašnieks.
Izvēlieties vienu diapazonu un turiet to tālu no tuneļa
Izvēlieties hotspota diapazonu, Pi adresi tajā, DHCP kopu un resolveri, ko saņem klienti. Turiet šo diapazonu atsevišķi no augšējā LAN un no VPN tuneļa diapazona, jo pārklājošies apakštīkli maršrutēšanas problēmu pārvērš adrešu tulkošanas projektā. Diapazons, kas pārklājas ar tuneli, padara Pi par nejaušu maršrutētāju starp diviem identiskiem prefiksiem. Ierakstiet diapazonu un kopu hotspota konfigurācijā, nevis atstājiet tos noklusējuma vērtībai.
Ja hotspotu pārvalda NetworkManager koplietotais režīms, pirms DHCP servera pievienošanas pārbaudiet faktisko savienojumu. Koplietotais režīms palaiž savus palīgus un ieslēdz pāradresēšanu, tāpēc tas jau ir šīs saskarnes adrešu plāna īpašnieks. Otra servera pievienošana tāpēc, ka tas ir pieejams, rada konkurējošus piedāvājumus, nevis rezervi.
Izlemiet par IPv6 apzināti. Maršrutētāja paziņojumi un DHCPv6 daudzās konfigurācijās nāk no cita palīga nekā DHCPv4, un IPv6 atstāšana ieslēgtu, kamēr VPN politika aptver tikai IPv4, klientiem dod ceļu, kas apiet tuneli. Vai nu izplānojiet IPv6 pusi, vai izslēdziet to hotspota saskarnē ar rakstisku iemeslu.
Kas faktiski atbild uz porta 53
Pirms konfigurācijas maiņas uzskaitiet katru procesu, kas klausās portā 53. Pi, kur darbojas vietējais resolver stub, Pi-hole un koplietošanas palīgs, klausītāju saraksts ir vienīgā uzticamā karte, kas atbild uz vaicājumiem:
sudo ss -lunpt '( sport = :53 )'
ip -4 addr show
ip routePi-hole saskarņu rokasgrāmata skaidro, ka uztveršanas režīms, kas ierobežots ar vienu saskarni, joprojām var izmantot wildcard ligzdu un izmest citur pienākušos. Tas nav tas pats, kas saistīt tikai atlasītās saskarnes, kas ir kārtība, kas paredzēta, kad mašīna jāsadala citam DNS pakalpojumam.
Divi procesi parasti nevar saistīt vienu un to pašu adresi un portu, lai gan SO_REUSEPORT var padarīt koplietotu saistīšanu veiksmīgu; pat tad wildcard klausītājs var pārņemt pienākušos, kas paredzēti šaurākajam pakalpojumam. Izvēlieties dokumentēto režīmu vēlamajai lomai un restartējiet pakalpojumus paredzētajā secībā.
Turiet Pi-hole administrēšanas lapu ārpus hotspota tīkla. Klientiem vajag resolveri, nevis tīmekļa saskarni vai API, kas var mainīt resolvera konfigurāciju.
Divi DNS posmi, katram sava politika
Klienta vaicājums ceļo no tālruņa uz Pi, un atsevišķs vaicājums ceļo no Pi uz tā augšējo resolveri. Maršrutēšanas noteikums, kas atbilst pāradresētajai hotspota plūsmai, otrajam posmam automātiski neattiecas, jo Pi šo plūsmu ģenerē lokāli. Ja VPN ir jāpārvadā DNS, lokālajam ceļam vajadzīga sava politika.
Uzmanieties no cilpas. Pi-hole augšējā resolvera novirzīšana uz adresi, ko apkalpo pats Pi, tieši vai caur porta pāradresāciju, rada vaicājumus, kas griežas, līdz tiem beidzas laiks. Dodiet tam īstu augšējo resolveri vai nosacītu forwarder domēniem, uz kuriem tas nevar atbildēt.
Izlemiet, kas notiek, kad tunelis nokrīt. Atgriešanās pie vietējā resolvera uztur pārlūkošanu dzīvu, bet var noplūdināt vārdus ārpus VPN; bloķēšana saglabā politiku neskartu un pārvērš pārtraukumu redzamā kļūdā. Abas izvēles ir aizstāvamas, taču tās ir jāizvēlas, nevis jāmanto no noklusējuma vērtības.
Pierādiet ceļu un uzvedību pārtraukuma laikā
Testējiet slāņos: klients saņem adresi, klients atrisina vārdu caur Pi, Pi atrisina caur paredzēto augšējo resolveri, un lietotne pabeidz pieprasījumu. Veiksmīgs ping neko nepasaka par DNS, un veiksmīga meklēšana neko nepasaka par pāradresēšanu.
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.1Pēc tam apturiet tuneli un atkārtojiet. Paredzētajai uzvedībai jāparādās dažu sekunžu laikā, nevis pēc Pi-hole vai hotspota pakalpojuma manuālas restartēšanas. Pārtraukuma laikā pārbaudiet klienta resolvera iestatījumu, jo sekundārais publiskais resolveris turpinās atbildēt arī tad, kad politika gaidīja kļūdu.
Turiet vienu īpašnieku pāradresēšanai un NAT un pārbaudiet to no klienta, nevis no paša Pi. Pieprasījums, kas veiksmīgi atstāj Pi, joprojām var tikt atmests atceļā, un klients ir vienīgā vieta, kur redzams viss ceļš.