Ohjaa OpenVPN-asiakkaat toisella isännällä olevalle Pi-hole-resolverille

Pi-hole-osoitteen laittaminen OpenVPN-profiiliin ei luo polkua siihen, myönnä oikeutta kysellä sitä eikä takaa, että asiakas käyttää sitä. Kun Pi-hole on erillisellä LAN-koneella, neljän asian on täsmättävä: reitti asiakkaasta, edelleenlähetys yhdyskäytävältä, paluupolku pooliin ja vastaanottokäytäntö itse Pi-holessa. Jokainen vika näyttää lokissa erilaiselta. Niiden läpikäynti tässä järjestyksessä on nopeampaa kuin viimeisen korjaaminen ensin. Tavallinen oikotie, rekursion avaaminen kaikille lähteille, vaihtaa pienen ongelman pysyvään.

Mitä pushattu DNS-asetus tekee ja mitä ei

Palvelin mainostaa resolveria alla olevalla direktiivillä olettaen, että 192.168.50.53 on Pi-hole-isäntä. Asiakas vastaanottaa asetuksen ja, alustastaan ja resolveri-integraatiostaan riippuen , soveltaa sitä tunnelirajapintaan tai jättää sen huomiotta paikallisen stubin hyväksi. Reittirivi on yhtä tärkeä kuin DNS-rivi, sillä resolveri, johon asiakas ei pääse, ei ole resolveri lainkaan. Mikään tästä ei näy palvelimen puolelta.

server 10.90.0.0 255.255.255.0
push "dhcp-option DNS 192.168.50.53"
push "route 192.168.50.0 255.255.255.0"

Asetuksen vastaanottaminen ei ole sama kuin sen käyttäminen. Linux-asiakas, jolla on resolverinhallinta, voi hyväksyä pushatun palvelimen ja lähettää sille vain tietyt verkkotunnukset; asiakas, joka hallitsee DNS:ää itse, voi korvata asetuksen kokonaan. Pushatut reitit ovat myös rajoitettuja joillakin alustoilla, mikä jättää resolverin tavoittamattomaksi, vaikka asetus hyväksyttiin. Tarkista asiakkaalta, mikä palvelin vastaa, älä palvelimelta, mitä lähetettiin.

Asetus ei myöskään kerro mitään palvelimen puolesta. DNS-liikenteen on silti kuljettava asiakkaalta yhdyskäytävälle ja yhdyskäytävältä Pi-holelle ennen kuin mikään asetus merkitsee mitään. Puuttuva reitti ja hylätty kysely näyttävät asiakkaalta samalta, joten vahvista ensin edelleenlähetys yhdyskäytävällä.

Paluupolku Pi-holesta pooliin

Jos asiakkaan lähdeosoite säilytetään, Pi-hole vastaa VPN-poolin sisäiseen osoitteeseen. Sen oma reititystaulu ei todennäköisesti tiedä poolista mitään, joten vastaus menee sen oletusyhdyskäytävälle ja katoaa. Kyselyloki näyttää pyynnön ilman vastaavaa vastausta, mikä on helppo tulkita palomuuriongelmaksi.

Anna LAN-reitittimelle staattinen reitti pooliin OpenVPN-yhdyskäytävän ollessa seuraava hyppy, tai käännä lähde yhdyskäytävällä ennen edelleenlähetystä Pi-holelle. Ensimmäinen pitää kunkin asiakkaan osoitteet näkyvinä Pi-holen kyselylokissa. Toinen poistaa paluureitin vaatimuksen mutta saa jokaisen kyselyn näyttämään yhdyskäytävältä tulleelta. Kumpikaan ei ole väärin; ne vastaavat eri kysymyksiin.

Jos asiakaskohtainen raportointi tai käytäntö on tärkeää, staattinen reitti on parempi vaihtokauppa. Jos LAN on jonkun muun hallinnassa eikä reittiä ole saatavilla, käännös on pragmaattinen vaihtoehto, ja asiakkaan identiteetin menetys on kirjattava. Kirjaa, kumman valitsit, sillä jokainen myöhempi lokikysymys riippuu siitä.

Pi-holen kuuntelutila reititetyille asiakkaille

Rajapintojen kuuntelukäyttäytymisen pudotusvalikko DNS-asetusten sivulla päättää, mille lähteille Pi-hole vastaa. Sen tiukin vaihtoehto hyväksyy vain suoraan liitettyjen verkkojen asiakkaat; vaihtoehto, joka sallii laitteet enintään yhden hypyn päässä, laajentaa sen viereisen reitittimen takana oleviin aliverkkoihin, ja juuri sellaiselta reititetty VPN-asiakas näyttää. Paketti saapuu kyllä LAN-rajapinnalle, mutta sen lähdeosoite kuuluu toiseen aliverkkoon. Se on käytäntöperusteinen hylkäys eikä reititysvika, ja ero on merkityksellinen lokeja lukiessa.

Pi-holen kuunteluopas erottaa paikallisesti liitetyt lähteet reititetyistä alkuperistä, eikä saapumisrajapinta ole kriteeri. Valitse tila, joka sallii VPN-poolin sallimatta koko internetiä, ja yhdistä se palomuurisääntöön, joka hyväksyy DNS:n vain poolista.

Rekursion avaaminen kaikille alkuperille ensimmäisen kyselyn toimimiseksi on väärä korjaus. Se muuttaa yksityisen resolverin avoimeksi, ja korjaus on rajattu oikeus eikä globaali.

Sovita vastaus kyselylokiin

Kysy asiakkaalta, tarkista sitten palvelin ja vertaa kahta. Systemd-resolved-asiakkaalla alla olevat komennot kertovat, mikä resolveri tuotti vastauksen ja mitkä palvelimet on määritetty linkeittäin. Käytä nimeä, jonka vain Pi-hole tuntee, sillä suora kysely Pi-holen osoitteeseen todistaa tavoitettavuuden, ei kokoonpanon.

resolvectl query intranet.example.lan
resolvectl dns

Odotettu vastaus nimeää 192.168.50.53 palvelimeksi ja palauttaa osoitteen, jonka vain kyseinen resolveri tuntisi. Katso sitten Pi-holen omaa näkymää: pihole -t seuraa kyselylokia reaaliajassa, ja jokainen rivi kantaa lähdeosoitteen. Jos lähde on asiakkaan tunneliosoite, poolin reitti on ehjä. Jos se on yhdyskäytävän LAN-osoite, lähdekäännös on käytössä eikä asiakkaan oma osoite tule koskaan näkyviin.

Jos lokissa ei näy mitään, kysely ei koskaan saavuttanut Pi-holea ja seuraavaksi on tarkistettava yhdyskäytävän edelleenlähetys. Jos kysely näkyy eikä vastausta tule, paluupolku on ongelma eli edellinen osio. Vian jakaminen näin estää reititysvirheen luulemisen palomuurisäännöksi.

Tarkista yhdyskäytävän edelleenlähetyssääntö

Yhdyskäytävän on edelleenlähetettävä asiakkaan DNS-paketit kohti Pi-holea, ja sääntö, joka sen tekee, kannattaa lukea olettamisen sijaan. Alla olevat komennot listaavat porttiin 53 koskevat säännöt laskureineen, nftables-isännällä ja iptables-isännällä. Sääntö, joka on olemassa mutta näyttää nolla osumaa, on merkki siitä, että liikennettä pudotetaan ennen kuin se käännettäisiin.

sudo nft list ruleset | grep -A3 'dport 53'
sudo iptables -t nat -L POSTROUTING -n -v | grep 53

Lue laskurit, älä vain sääntöjä. Sääntö, joka ei koskaan osu, tarkoittaa, että paketti lähtee toisen rajapinnan kautta tai asiakas ei koskaan lähettänyt sitä. Sääntö, joka osuu jokaiseen kyselyyn, tarkoittaa, että edelleenlähetys toimii ja ongelma on kauempana polulla.

Mitä työkalua isäntä käyttääkin, pidä tarkistus suppeana: pool lähteenä, portti 53 kohteena ja Pi-hole ainoana sallittuna kohteena. Laaja edelleenlähetyssääntö, joka sallii myös portin 80, on toinen ongelma odottamassa tapahtumista.