Käytetäänkö VPN:si DNS:ää todella? Kaappaa portti 53 ja katso

Kysy useimmilta, mitä VPN-asiakas tekee DNS:llä, ja he sanovat sen asettavan resolverin, joten kyselyt kulkevat tunnelin sisällä. Työntö on todellinen; oletus, että siitä tulee kysely, ei ole. Työnnetyn asetuksen ja johdolla olevan paketin välissä on kolme vaihetta, ja jokainen epäonnistuu itsenäisesti tavoilla, jotka kaikki näyttävät rikkinäiseltä DNS-palvelimelta. Siksi vuototestisivu ja toimiva selain voivat olla eri mieltä samasta koneesta samalla hetkellä.

Työnnetty asetus ei ole kysely

Ensimmäinen vaihe on, että palvelin tarjoaa asetuksia, esimerkiksi työnnetyn DNS-asetuksen, joka nimeää tunnelin sisäisen resolverin. Toinen vaihe on, että asiakas soveltaa nämä asetukset rajapintaan. Kolmas vaihe on, että sovellus todella lähettää kyselyn tuohon osoitteeseen. Toisen vaiheen epäonnistuminen jättää asetuksen näkyviin yhteyslokiin, kun taas resolveriluettelo pysyy muuttumattomana, ja kolmannen vaiheen epäonnistuminen jättää täysin oikean resolveriluettelon käyttämättä.

Suurin osa vianetsinnästä sulattaa nuo kolme yhdeksi ja syyttää VPN-palvelinta, joka on yleensä ainoa osapuoli, joka pystyy todistamaan tehneensä osansa. Lue sen sijaan asiakkaan todellinen resolver-tila ja seuraa sitten yhden kyselyn lähtöä. Nuo kaksi havaintoa erottavat kokoonpanon reitityksestä ja politiikasta, ja ne kestävät noin viisi minuuttia. Säilytä kaappaukset, koska seuraava insinööri haluaa ennen ja jälkeen eikä kuvausta niistä.

Tarkista, mitä rajapinta todella pitää

Linuxissa järjestelmän resolver voi olla tavallinen tiedosto, NetworkManager tai systemd-resolved, ja se, mikä niistä omistaa sen, ratkaisee, mihin työnnetty palvelin laskeutuu. Komentorivin OpenVPN-prosessi ei päivitä järjestelmän resolveria itse, joten dokumentoitu integraatio on up/down-skripti tai yhteyshallinta, joka jo osaa soveltaa asetukset. Molempien ajaminen on tehokas tapa luoda kilpailu.

resolvectl status
cat /etc/resolv.conf

Windowsissa luettelo on sovitinkohtainen, joten tunnelisovitin voi pitää sisäiset palvelimet, kun taas fyysinen sovitin säilyttää paikalliset ja voittaa joidenkin nimien kohdalla. Vertaa molempia sovittimia sen sijaan, että luulisit jonkin olevan aktiivinen.

Seuraa yksi kysely koneen ulkopuolelle

Kaappaa molemmat rajapinnat samanaikaisesti ja ratkaise sitten yksi nimi, jonka pitäisi käyttää sisäistä resolveria. Se kaappauspari vastaa siihen, mihin mikään kokoonpanon tuloste ei pysty.

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

Kysely, joka näkyy fyysisellä rajapinnalla eikä koskaan tunnelissa, tarkoittaa, että asiakas valitsi väärän resolverin. Kysely, jota ei näy kummassakaan, tarkoittaa, että sovellus vastasi välimuistista, kysyi loopbackilla kuuntelevalta stubilta tai käytti salattua resolveria, jonka liikenne ei koskaan näy porttina 53. Kaappaa myös vastaukset, älä vain kyselyitä, sillä tunnelin kautta lähtevä kysely, johon tulee vastaus julkisesta osoitteesta, on eri vika kuin se, ettei vastausta tule lainkaan.

Palomuuri, joka hyväksyy vain oman DNS:nsä

Kaupalliset asiakkaat asentavat joskus omia suodatin ketjujaan. Yksi dokumentoitu malli sallii DNS:n asiakkaan omalle resolverille ja hylkää kaiken jäljelle jäävän UDP-liikenteen portilla 53, joka yrittää poistua rajapinnasta, joka ei ole loopback, mukaan lukien liikenne, jonka käyttäjä on tarkoituksella reitittänyt muualle. Daemonin kyselyt katoavat jälkiä jättämättä, mikä luetaan resolverin viaksi eikä suodattimeksi.

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

Jos hylkäyssääntö arvioidaan ennen poikkeustasi, lisättyyn sääntöön ei koskaan päästä, joten lisää se ensimmäiseen kohtaan ja rajaa kohde resolveriin, jota todella tarkoitat.

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

Tuo poikkeus on diagnostinen eikä poliittinen. Jos toimittajan sääntö on tarkoituksellinen, tuettu korjaus on määrittää asiakas sallimaan tuo resolveri ja kirjata päätös, koska lisätty sääntö ei selviä seuraavasta asiakaspäivityksestä.

Miksi vuotosivu todistaa vähemmän kuin näyttää

Mitä vuototestisivu näyttää, on resolveri, joka puhui testin operaattorille, ei se, jolta koneesi kysyi. Paikallinen edelleenlähettäjä, joka rekursioi ulospäin, laittaa oman lähtöosoitteensa sille sivulle, ja salatut kyselyt voivat jättää sivun täysin tyhjäksi. Molemmat tulokset luetaan väärin, toinen vuotona ja toinen takuuna, eikä kumpikaan luenta seuraa havainnosta.

Puolustettava todiste on kaappaus: rajapinta, kohdeosoite, vastaus ja aikaleima. Ota yksi ennen kuin tunneli nousee ja yksi sen jälkeen, ja vertaa niitä seuraavan kerran, kun nimi epäonnistuu. Se pari kertoo myös seuraavalle henkilölle, oliko vika ratkaisussa, reitityksessä vai resolverin omassa käyttöpolitiikassa.