Miksi dnsmasq-kyselyt karkaavat VPN:n ulkopuolelle DNS-uudelleenohjauksen jälkeen

Lähiverkon asiakas tavoittaa VPN:nsä oikein, ja silti sen DNS-kyselyt näkyvät väärällä ylävirran linkillä. Se ei ole vuoto tavanomaisessa mielessä; se on sitä, mitä tapahtuu, kun reititin lakkaa välittämästä kyselyä ja vastaa siihen itse. Sieppaus kirjoittaa kohteen uudelleen paikalliseksi pistokkeeksi, ja sitten resolveri avaa toisen, siihen liittymättömän keskustelun omalla lähdeosoitteellaan ja omalla reitityspäätöksellään. Asiakkaan vuohon liitetyt merkit kuvaavat ensimmäistä keskustelua eivätkä yhtään mitään toisesta.

Merkki ei matkusta kyselyn mukana

Pakettimerkit elävät conntrack-tietueessa ja lentävän paketin päällä. REDIRECT-sääntö päättää sen lennon: hyötykuorma luovutetaan paikalliselle pistokkeelle ja alkuperäinen tietue on tehnyt tehtävänsä. Se, mikä sen jälkeen lähtee reitittimestä, on resolveriprosessin luoma tuore pistoke, jonka lähteenä on reitittimen oma osoite.

Siksi lähiverkon asiakkaan osoitteeseen sidottu käytäntöreitti ei koskaan vastaa ylävirran kyselyä. Uusi pistoke kuuluu dnsmasqille eikä asiakkaalle, ja ydin arvioi reitin reitittimen omalle liikenteelle. Lähdesäännöt, rajapintasäännöt ja merkkisäännöt näkevät kaikki eri monikon. Oletus merkin välittymisestä on tämän asetelman yleisin virhe, ja se on näkymätön asiakaspuolen kaappauksessa.

Nuo kaksi keskustelua jakavat kuitenkin nimen ja ajoituksen, ja juuri siksi ne näyttävät yhdeltä vuolta, kun silmäilet kaappausta.

Missä välityksestä tulee paikallista ratkaisua

Aloita selvittämällä, ohjataanko portti 53 uudelleen, käännetäänkö se toiselle isännälle vai jätetäänkö se rauhaan, koska kolme tapausta käyttäytyvät eri tavoin. Uudelleenohjaus paikalliseen porttiin lopettaa välityksen, kun taas käännös toiselle koneelle pitää paketin liikkeessä ja asiakkaan monikon merkityksellisenä.

Katso molempia protokollia. UDP:n ja TCP:n kautta tavoitettava resolveri testataan molempien kautta, ja vain UDP:n kattava sääntöjoukko jättää hiljaisen reiän suurille vastauksille. Reitittimen oman konfiguraatiohallinnan tuottamat säännöt lasketaan myös, ja tuotetun tiedoston muokkaaminen häviää yleensä seuraavalle uudelleenlataukselle.

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

Nuo tulosteet vastaavat kolmeen kysymykseen järjestyksessä: mikä kirjoittaa kyselyn uudelleen, mikä ottaa sen vastaan ja mikä prosessi omistaa kuuntelevan pistokkeen. Kun omistaja tiedetään, ylävirran käytännöllä on missä elää.

Anna resolverille oma lähtökäytäntönsä

Verkkotunnuskohtainen ylävirta on puhtain työkalu, kun vain jotkin nimet tarvitsevat tunnelia. dnsmasq hyväksyy verkkotunnukseen rajatun server-rivin, jossa on valinnainen rajapinta tai lähdeosoite, joka ohjaa kyselyn valitusta laitteesta ulos. Juuri se ohjaus saa toisen keskustelun seuraamaan VPN:ää.

server=/corp.example/10.30.0.53@tun_work
log-queries

Yllä oleva verkkotunnus, osoite ja rajapinta ovat paikkamerkkejä omille arvoillesi. Verkkotunnuksen valinta ja lähdön hallinta pysyvät erillisinä päätöksinä: reitin on oltava olemassa, ylävirran resolverin on sallittava lähdeosoite ja palomuurin on sallittava vastaus. Pelkkä rajapintaohjaus ei ole fail-closed, koska kadonnut tunneli voi jättää resolverin putoamaan toiselle polulle. Pidä mahdollinen julkinen varareitti kaukana nimiavaruudesta, jonka on pysyttävä yksityisenä.

Laita rivi reitittimen tukemaan konfiguraation omistajaan eikä tuotettuun tiedostoon, tai seuraava uudelleenlataus pyyhkii korjauksen.

Mitä jaettu välimuisti ei voi säilyttää

Yksi välittäjä yhdellä välimuistilla palvelee jokaista lähiverkon asiakasta, ja se romahduttaa erottelun, jota jotkin verkot tarvitsevat. Jos kahden asiakkaan on ratkaistava sama nimi eri tavoin, jaetulla pistokkeella ei ole keinoa palauttaa, kuka asiakas kysyi. Asiakaskohtaisen käytännön on elettävä erillisissä resolverin instansseissa tai välitysominaisuudessa, joka säilyttää identiteetin.

Välimuistiin tallennettu vastaus ei ole sekään todiste uudesta polusta. Vastaus voi tulla muistista, kun ylävirran reitti pysyy rikki.

Portin 53 säännöt eivät kerro mitään sovelluksista, jotka puhuvat DNS:ää HTTPS:n tai TLS:n yli. Ne kyselyt eivät koskaan saavuta uudelleenohjausta, joten vain porttiin 53 nojaava käytäntö kuvaa liikenteen osajoukon ja se tulisi dokumentoida osajoukkona.

Varmista toinen keskustelu, älä ensimmäistä

Testaa yhdellä hallitsemallasi nimellä ja katso molempia puolia. Asiakaspuolen kaappaus todistaa, että kysely lähti lähiverkosta; vain reitittimen puoli todistaa, minne se meni seuraavaksi.

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

Tyhjennä välimuisti ennen jokaista yritystä, koska lämmin vastaus kätkee rikkinäisen ylävirran. Toista TCP:n yli ja toista sitten tunneli alas kytkettynä nähdäksesi, mitä resolveri tekee, kun sen suosima polku on poissa. Juuri se viimeinen käytös ratkaisee, onko suunnittelu fail-closed vai vain onnekas.