Punt d'accés Pi amb Pi-hole i VPN: assigna una feina a cada servei

Un telèfon s'uneix al punt d'accés del Pi, obté una adreça i la pàgina continua fallant. El Pi executa un auxiliar de punt d'accés, Pi-hole i un client de VPN, i cadascun creu que posseeix una part del camí. La majoria d'aquestes configuracions fallen no perquè un component estigui espatllat, sinó perquè dos components fan la mateixa feina. Assigna un propietari per funció abans d'ajustar-ne cap.

Assigna un propietari per funció

Aquí importen quatre funcions, i cadascuna necessita exactament un propietari. La taula següent indica la funció, un propietari viable i què falla quan dos serveis se la disputen.

La superposició sol arribar un paquet a la vegada. L'auxiliar del punt d'accés instal·la la seva pròpia instància de dnsmasq, Pi-hole vol el port 53 i el client de VPN afegeix rutes. Cada pas sembla raonable per si sol, i junts produeixen una màquina on el segon servei que arrenca canvia en silenci el comportament del primer.

Anota els propietaris abans d'activar res més. Una taula curta a les notes de muntatge evita que una instal·lació posterior assumeixi una funció que ja tenia propietari.

Tria un rang i mantén-lo allunyat del túnel

Tria el rang del punt d'accés, l'adreça del Pi dins d'ell, el conjunt de DHCP i el resolutor que reben els clients. Mantén aquest rang separat de la LAN superior i del rang del túnel VPN, perquè les subxarxes superposades converteixen un problema d'encaminament en un projecte de traducció d'adreces. Un rang que se superposa al túnel fa que el Pi sigui un encaminador accidental entre dos prefixos idèntics. Escriu el rang i el conjunt a la configuració del punt d'accés en lloc de deixar-los a un valor per defecte.

Si el mode compartit del NetworkManager és el propietari del punt d'accés, inspecciona la connexió efectiva abans d'afegir un servidor DHCP. El mode compartit arrenca els seus propis auxiliars i activa l'encaminament, així que ja és el propietari del pla d'adreces d'aquesta interfície. Afegir un segon servidor perquè està disponible crea ofertes en competència en lloc de redundància.

Decideix sobre IPv6 deliberadament. Els anuncis de router i DHCPv6 provenen en moltes configuracions d'un auxiliar diferent del DHCPv4, i deixar IPv6 actiu mentre la política de VPN només cobreix IPv4 dona als clients un camí que evita el túnel. O planifiques el costat IPv6 o el desactives a la interfície del punt d'accés amb una raó escrita.

Qui respon realment al port 53

Llista tots els processos que escolten al port 53 abans de canviar una configuració. En un Pi que executa un stub de resolutor local, Pi-hole i un auxiliar de compartició, la llista d'oients és l'únic mapa fiable de qui respon les consultes:

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

La guia d'interfícies de Pi-hole explica que un mode de recepció limitat a una interfície encara pot fer servir un sòcol comodí i descartar les arribades en altres llocs. Això no és el mateix que enllaçar només les interfícies seleccionades, que és la disposició prevista quan un altre servei DNS ha de compartir la màquina.

Dos processos normalment no poden enllaçar la mateixa adreça i port, tot i que SO_REUSEPORT pot fer que un enllaç compartit tingui èxit; fins i tot llavors, un oient comodí pot prendre les arribades destinades al servei més estret. Tria el mode documentat per al paper que vols i reinicia els serveis en l'ordre previst.

Mantén la pàgina d'administració de Pi-hole fora de la xarxa del punt d'accés. Els clients necessiten un resolutor, no la interfície web o l'API que pot canviar la configuració del resolutor.

Dues potes de DNS, una política per a cadascuna

Una consulta del client viatja del telèfon al Pi, i una consulta separada viatja del Pi al seu resolutor superior. Una regla d'encaminament que coincideix amb el trànsit reenviat del punt d'accés no s'aplica automàticament a la segona pota, perquè el Pi genera aquest trànsit localment. Si el VPN ha de portar el DNS, el camí local necessita la seva pròpia política.

Vigila els bucles. Apuntar el resolutor superior de Pi-hole a una adreça que el mateix Pi serveix, directament o mitjançant un reenviament de port, produeix consultes que donen voltes fins que expiren. Dona-li un resolutor superior real o un reenviador condicional per als dominis que no pot respondre.

Decideix què passa quan cau el túnel. Tornar al resolutor local manté la navegació viva però pot filtrar noms fora del VPN; bloquejar manté la política intacta i converteix la interrupció en un error visible. Qualsevol opció és defensable, però s'ha de triar en lloc d'heretar d'un valor per defecte.

Demostra el camí i el comportament en la interrupció

Prova per capes: el client obté una adreça, el client resol un nom a través del Pi, el Pi resol a través del resolutor superior previst i una aplicació completa una petició. Un ping correcte no diu res sobre DNS, i una consulta correcta no diu res sobre l'encaminament.

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

Després atura el túnel i repeteix. El comportament previst hauria d'aparèixer en uns quants segons, no després de reiniciar manualment Pi-hole o el servei del punt d'accés. Comprova la configuració del resolutor del client durant la interrupció, perquè un resolutor públic secundari continuarà responent fins i tot quan la política esperava un error.

Mantén un sol propietari per a l'encaminament i el NAT i verifica'l des d'un client, no des del mateix Pi. Una petició que surt del Pi amb èxit encara es pot descartar en el camí de tornada, i el client és l'únic lloc on tot el camí és visible.