Miksi DNS lakkaa toimimasta, kun OpenVPN muodostaa yhteyden Windowsissa

Ping toimiston resolverille saa yhä vastauksen, kun "OpenVPN" on yhdistänyt, ja silti jokainen nimihaku epäonnistuu. Osoite on tavoitettavissa mutta portti ei, yhdistelmä joka on järkeenkäypä kun tietää, että Windows voi suodattaa DNS:ää sovittimen mukaan. Kun profiilissa on block-outside-dns, tuo suodatin on ensimmäinen epäilty ja reititystaulu on väärä paikka etsiä. Kaksi alla olevaa testiä erottavat kerrokset sekunneissa.

Tavoitettava osoite, kuollut portti

Onnistunut ping todistaa, että isäntä on käynnissä ja polku on olemassa. Se ei kerro mitään luvasta päästä porttiin 53, koska kyseinen suodatin toimii eri kerroksessa ja riippuu sovittimesta. Siksi sama kone voi vastata ICMP:hen ja hylätä jokaisen samaan osoitteeseen lähetetyn kyselyn. Aja molemmat testit samassa istunnossa ennen kuin muutat mitään asetusta.

ping <resolver-ip>
nslookup <name> <resolver-ip>

Pari on diagnoosi. Tavallinen liikenne aliverkkoon jatkuu, kun nimien selvitys kuolee, ja ihmiset päättelevät, että palvelin on rikki tai että DNS:tä ei koskaan työnnetty. Molempien selitysten jäljittäminen on kallista, ja todisteet osoittavat kapeampaan paikkaan. Vahvista pari ennen kuin kosket asetukseen.

Asetus on suodatusalustan sääntö

OpenVPN:n viite kuvaa block-outside-dns:n Windows Filtering Platformin rajoituksena, joka estää sovelluksia saavuttamasta DNS:ää tunnelin ulkopuolisilla sovittimilla. Se kattaa TCP- ja UDP-portin 53. Koska suodatin elää WFP:ssä eikä tavallisessa palomuurisääntöjen luettelossa, sallivan säännön lisääminen muualle ei välttämättä muuta tulosta. Siksi tavallinen neuvo sallia DNS epäonnistuu edelleen.

Asetus voi tulla tuodusta profiilista tai palvelimelta, ja tiedosto, jota viimeksi muokkasit, "ei todista sitä, mitä asiakas latasi". Lue voimassa oleva kokoonpano ja yhteysloki yhdessä. Asetus on myös Windows-kohtainen, ja sen pitäminen siirrettävänä tuottaa neuvoja, jotka eivät päde.

Etsi asiakasohjelman komponentti, joka omistaa rajoituksen, sen sijaan että lisäät sääntöjä. Omistaja on se, joka voi todella poistaa sen.

Suodatin ei ole resolver

Liikenteen estäminen tunnelin ulkopuolella ei asenna toimivaa resolveria sen sisään. Asetus poistaa polun ja jättää tunnelin DNS-kokoonpanon sille, joka teki profiilin. Profiililla, joka ei koskaan työntänyt resolveria, ei ole nyt yhtään.

Käy kolme tarkistus läpi järjestyksessä. Ensinnäkin, mitä resolveria epäonnistuva sovellus todella käyttää. Toiseksi, sovelsiko asiakas VPN:n DNS-asetukset. Kolmanneksi, mikä liitäntä kuljettaa liikennettä tuolle resolverille.

1. Käytössä oleva resolver: vertaa Resolve-DnsName -Server <resolver-ip> <name> DNS-palvelimiin, jotka ipconfig /all luettelee.
2. VPN:n DNS käytössä: tarkastele tunnelisovittimen DNS-tietoja samassa ipconfig /all tulosteessa.
3. Käytetty liitäntä: Find-NetRoute -RemoteIPAddress <resolver-ip> nimeää lähtevän liitännän kyseiselle kohteelle.

LAN-resolver muuttuu suunnittelun mukaan tavoittamattomaksi tämän käytännön alla, vaikka muu LAN-liikenne toimii. Se on asetus tekemässä työtään. Jos suunnittelu tarvitsee VPN-DNS:ää, korjaa resolverin rekisteröinti ja tunnelin polku; jos tarvitaan split DNS:ää paikallisin poikkeuksin, kokoonpanon omistajan on ilmaistava ne poikkeukset tuetulla tavalla.

Mitä asetus ei kata

Portti 53 ei ole koko nimien selvitys. DNS over HTTPS ja DNS over TLS käyttävät eri kuljetuksia, ja jotkin sovellukset ajavat omaa resolverilogiikkaansa järjestelmäasetuksista riippumatta. Selain voi siis selvittää nimiä, kun taas komentorivi ei voi.

Käsittele eroa diagnoosina, älä ristiriitana. Vertaa molempia ennen kuin päätät, että järjestelmän resolver on rikki.

Pidä johtopäätös kapeana, kun kirjoitat sen. Tämä asetus rajoittaa yhtä kuljetusta yhdellä alustalla, ja muu osa selvityspolusta on erillinen suunnittelukysymys omine omistajineen.

Tarkista tila ennen irrotusta ja sen jälkeen

Aja sama haku yhteyden aikana ja uudelleen sen jälkeen, kun omistava asiakas katkaisee. Ensimmäisen pitäisi epäonnistua ulkoiselle resolverille, kun tunneli on ylhäällä, ja toisen pitäisi onnistua, kun suodatin on poistettu. Jos se epäonnistuu yhä irrotuksen jälkeen, suodatinta ei siivottu.

ipconfig /displaydns
nslookup <name> <resolver-ip>

Asiakaspalvelun tai koneen uudelleenkäynnistys siivoaa yleensä vanhan suodattimen. Se vahvistaa diagnoosin todistamatta pysyvää korjausta. Kirjaa mitä näit, koska irrotuksen kestävä suodatin tekee sen uudelleen, ja juuri kirjaus perustelee virheraportin.

Vasta näiden tarkistusten jälkeen on järkevää vaihtaa resolver tai rakentaa palomuurikäytäntö uudelleen. Molemmat ovat suurempia muutoksia kuin todisteet tukevat.