Pi-hotspot met Pi-hole en VPN: gee elke diens 'n taak

’n Foon sluit by die Pi se hotspot aan, kry ’n adres, en die bladsy faal steeds. Die Pi laat 'n hotspot-helper, Pi-hole en 'n VPN-kliënt loop, en elkeen glo hy besit 'n deel van die pad. Die meeste van hierdie bouwerke faal nie omdat 'n komponent stukkend is nie, maar omdat twee komponente dieselfde werk doen. Wys een eienaar per funksie toe voordat jy enige van hulle instel.

Wys een eienaar per funksie toe

Vier funksies is hier belangrik, en elkeen kort presies een eienaar. Die tabel hieronder noem die funksie, 'n werkbare eienaar en wat verkeerd loop wanneer twee dienste dit opeis.

Die oorvleueling kom gewoonlik een pakket op 'n slag. Die hotspot-helper installeer sy eie dnsmasq-instansie, Pi-hole wil poort 53 hê, en die VPN-kliënt voeg roetes by. Elke stap lyk op sy eie redelik, en saam lewer hulle 'n masjien waar die tweede diens wat begin, die eerste se gedrag stilweg verander.

Skryf die eienaars neer voordat jy enigiets anders aktiveer. 'n Kort tabel in die bounotas verhoed dat 'n latere installasie 'n funksie oorneem wat reeds 'n eienaar gehad het.

Kies een reeks en hou dit weg van die tonnel

Kies die hotspot-reeks, die Pi se adres daarop, die DHCP-poel en die resolver wat die kliënte ontvang. Hou daardie reeks apart van die opstroom-LAN en van die VPN-tonnelreeks, want oorvleuelende subnetwerke maak 'n roeteringsprobleem 'n adresvertalingsprojek. 'n Reeks wat die tonnel oorvleuel, maak die Pi 'n toevallige router tussen twee identiese voorvoegsels. Skryf die reeks en poel in die hotspot-konfigurasie in eerder as om dit aan 'n verstek toe te laat.

As NetworkManager se gedeelde modus die hotspot besit, ondersoek die effektiewe verbinding voordat jy 'n DHCP-bediener byvoeg. Gedeelde modus begin sy eie helpers en aktiveer deurstiuring, so dit is reeds die adresplan-eienaar vir daardie koppelvlak. Om 'n tweede bediener by te voeg omdat dit beskikbaar is, skep mededingende aanbiedinge eerder as oortolligheid.

Besluit doelbewus oor IPv6. Routeraankondigings en DHCPv6 kom in baie opstellings van 'n ander helper as DHCPv4, en om IPv6 aan te laat terwyl die VPN-beleid net IPv4 dek, gee kliënte 'n pad wat die tonnel omseil. Beplan die IPv6-kant of skakel dit op die hotspot-koppelvlak af met 'n geskrewe rede.

Wie antwoord werklik op poort 53

Lys elke proses wat op poort 53 luister voordat jy 'n konfigurasie verander. Op 'n Pi waarop 'n plaaslike resolver-stub, Pi-hole en 'n deel-helper loop, is die luisteraarlys die enigste betroubare kaart van wie navrae beantwoord:

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

Pi-hole se koppelvlakgids verduidelik dat 'n ontvangmodus wat tot een koppelvlak beperk is, steeds 'n wildcard-sok kan gebruik en aankomste elders verwerp. Dit is nie dieselfde as om slegs geselekteerde koppelvlakke te bind nie, wat die reëling is wat bedoel is wanneer 'n ander DNS-diens die masjien moet deel.

Twee prosesse kan gewoonlik nie dieselfde adres en poort bind nie, al kan SO_REUSEPORT 'n gedeelde binding laat slaag; selfs dan kan 'n wildcard-luisteraar aankomste neem wat vir die nouer diens bedoel is. Kies die gedokumenteerde modus vir die rol wat jy wil hê en herbegin die dienste in die bedoelde volgorde.

Hou Pi-hole se administratiewe bladsy van die hotspot-netwerk af. Kliënte het 'n resolver nodig, nie die webkoppelvlak of API wat die resolver se konfigurasie kan verander nie.

Twee DNS-bene, een beleid elk

'n Kliëntnavraag reis van die foon na die Pi, en 'n aparte navraag reis van die Pi na sy opstroom-resolver. 'n Roeteringsreël wat by deurgestuurde hotspot-verkeer pas, geld nie outomaties vir die tweede been nie, want die Pi genereer daardie verkeer plaaslik. As die VPN DNS moet dra, het die plaaslike pad sy eie beleid nodig.

Pas op vir 'n lus. Om Pi-hole se opstroom te wys na 'n adres wat die Pi self bedien, direk of deur 'n poortdeurstuur, lewer navrae wat sirkel totdat hulle tyd uitloop. Gee dit 'n regte opstroom of 'n voorwaardelike deurstuurder vir die domeine wat dit nie kan beantwoord nie.

Besluit wat gebeur wanneer die tonnel val. Om na die plaaslike resolver terug te val, hou die blaai aan die gang maar kan name buite die VPN lek; om te blokkeer hou die beleid ongeskonde en maak die onderbreking 'n sigbare fout. Enige keuse is verdedigbaar, maar dit moet gekies word eerder as om van 'n verstek geërf te word.

Bewys die pad en die onderbrekingsgedrag

Toets in lae: die kliënt kry 'n adres, die kliënt los 'n naam deur die Pi op, die Pi los op deur die bedoelde opstroom, en 'n toepassing voltooi 'n versoek. 'n Suksesvolle ping sê niks oor DNS nie, en 'n suksesvolle opsoeking sê niks oor deurstiuring nie.

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

Stop dan die tonnel en herhaal. Die bedoelde gedrag moet binne 'n paar sekondes verskyn, nie ná 'n handmatige herbegin van Pi-hole of die hotspot-diens nie. Kontroleer die kliënt se resolver-instelling tydens die onderbreking, want 'n sekondêre openbare resolver sal aanhou antwoord selfs wanneer die beleid mislukking verwag het.

Hou een eienaar vir deurstiuring en NAT en verifieer dit vanaf 'n kliënt, nie vanaf die Pi self nie. 'n Versoek wat die Pi suksesvol verlaat, kan steeds op die terugpad laat val word, en die kliënt is die enigste plek waar die hele pad sigbaar is.