OpenVPN:n työntämä DNS jätetään huomiotta: mikä osa sen ottaa käyttöön

Loki näyttää asetuksen, jonka palvelin työnsi, tunneli on pystyssä, ja sisäiset nimet epäonnistuvat silti. Kysely suoraan resolverille vastaa, joten palvelin on kunnossa, mutta jokainen sovellus kysyy edelleen paikalliselta reitittimeltä. Asiakkaalle saapunut asia on tarjous, ei muutos resolverissa, ja nimi ratkaisun omistava osa eroaa Linuxissa, Windowsissa ja macOS:ssä. Kun erotat asetuksen sen omistajasta, neljä vikaa kattaa lähes jokaisen raportin: ei koukkua, kaksi kilpailevaa koukkua, jaettu DNS toimii suunnitellusti, tai lyhyt nimi tarvitsee jälkiliitteen eikä palvelinta.

Työnnetty asetus on tarjous, ei asennus

Palvelimella kaksi direktiiviä kuvaa aikomusta, ei vaikutusta:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

Asiakas ei saa määritettyä resolveria. Se saa ympäristömuuttujat, foreign_option_1 ja seuraavat, yhden jokaista työnnettyä riviä kohti, ja jonkin paikallisen on luettava ne ja kirjoitettava käyttöjärjestelmän resolverin tila uudelleen. Linuxissa mikään ei tee sitä oletuksena, siksi oikea palvelin ja yhdistetty asiakas voivat yhä ratkaista nimiä LANin kautta.

Kahden pään välissä on kolme vaihetta: työnnön on kuljettava perille, asiakkaan on paljastettava se ja koukun on otettava se käyttöön. Lue keskimmäinen vaihe asiakkaan lokista ja viimeinen resolverin tilasta, älä koskaan päinvastoin, koska lokirivi todistaa vain kaksi ensimmäistä.

Varmista, että työntö saapui, ja löydä omistaja

Aloita nimeämällä käynnistäjä: pelkkä openvpn komento, systemd-instanssi, NetworkManager tai toimittajan asiakas. Se ratkaisee, missä koukku voi elää. Isännässä, jossa on systemd-resolved, resolvectl status listaa jokaisen linkin DNS-palvelimineen ja hakualueineen, joita se todella käyttää, eikä tunnelilinkin nimi ole aina tun0.

Jos työnnetty osoite näkyy lokissa mutta ei millään linkillä, integraatio puuttuu. Jos se näkyy linkillä ja kyselyt lähtevät silti muualle, ongelma on siinä, mitkä kyselyt valitsevat kyseisen linkin. NetworkManager dns=dnsmasq tiedostossa /etc/NetworkManager/NetworkManager.conf ajaa paikallista edelleenlähettäjää, joka toteuttaa jaetun DNS:n tarkoituksella: VPN-alueen sisäiset nimet menevät VPN-resolverille, kaikki muu säilyttää aiemman polkunsa. Tämä käytös näyttää vialta, kun odotti koko liikenteen siirtyvän; tarkista yhteyskohtaiset asetukset komennolla nmcli connection show "My VPN", jossa ipv4.dns ja ipv4.dns-search pitävät arvot sen takana, mitä laite raportoi, ennen kuin kutsut sitä rikkinäiseksi. Jos jokaisen kyselyn todella pitäisi saavuttaa VPN-resolveri, poista dns=dnsmasq tiedostosta NetworkManager.conf ja käynnistä NetworkManager uudelleen, mikä palauttaa nimien ratkaisun yhteyden asetuksiin; muuten pidä jaettu DNS ja korjaa työnnetty verkkotunnusluettelo.

Linux: anna asetukset resolverille

Jakelupaketit toimittavat tätä varten koukun, ja asiakkaan on saatava ajaa se. Tyypillinen järjestely isännässä ilman systemd-resolvedia:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

systemd-resolvedin kanssa vanhempi resolv.conf-skripti ei ehkä muuta mitään olennaista, koska stub-resolveri pitää tilan linkeittäin. update-systemd-resolved apuohjelma dokumentoi koukkumuodon, joka käyttää up-restart ja down-pre, millä on merkitystä, kun liitäntä elää yhtä yhteysyritystä pidempään. Mitä ikinä valitset, yhden osan on omistettava tila. Asiankuulumattoman koukun lisääminen NetworkManagerin viereen antaa samalle linkille kaksi kirjoittajaa, ja tulos riippuu silloin järjestyksestä eikä kokoonpanostasi.

On myös tapaus, jossa NetworkManager jätti työnnetyn asetuksen kokonaan huomiotta, kunnes palvelimen osoite syötettiin yhteyden IPv4-asetuksiin, minkä jälkeen resolverin tila näytti sen olevan käytössä. Sitä kannattaa kokeilla ennen skriptien uudelleenkirjoitusta, koska se siirtää ongelman komentotulkin koukusta yhteysprofiiliin, joka jo kuljettaa tunnelia.

Windows ja macOS ottavat käyttöön eri osia

Windowsin asiakas todella asettaa VPN-sovittimen DNS-palvelimet, mutta Windows valitsee liitännän edelleen metriikan mukaan ja tarvitsee edelleen jälkiliitteen lyhyen nimen laajentamiseen. Vahvista sovittimen tila eikä profiilia:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

Jos osoite puuttuu, aseta se komennolla Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, lisää sitten jälkiliite sovittimen IPv4-ominaisuuksiin, jotta fileserver muuttuu muotoon fileserver.corp.example. Koneenlaajuinen SearchList arvo kohdassa Tcpip\Parameters tekee saman. Kun pitkä nimi ratkeaa ja paljas ei, resolveri on jo oikein ja vika on hakuluettelossa. Korjaukset järjestyksessä: työnnä DOMAIN jotta asiakas oppii jälkiliitteen, lisää se jälkiliite sovittimen tai yhteyden hakuluetteloon, ja kiinnitä nimi väliaikaisesti kohtaan hosts, tai kohtaan LMHOSTS Windowsissa; NetBIOS-selaus ei ylitä reititintä, joten lähetys, joka löytää lyhyen nimen toimiston LANissa, ei koskaan saavuta tunneliasiakasta.

block-outside-dns block-outside-dns on Windows-asiakkaan käytös, ei siirrettävä profiilirivi, eikä sen kopiointi Linux- tai macOS-profiiliin toista sitä siellä. Jos julkiset nimet toimivat ja sisäiset epäonnistuvat Windowsissa, vertaa sovittimien järjestystä Lisäasetuksissa komennon ipconfig /all kanssa. macOS:ssä palvelukohtainen resolverijärjestys kuuluu järjestelmälle, joten käytä scutil --dns nähdäksesi, miltä resolverilta mitä verkkotunnusta kysytään, ja pidä jokaista yksittäistä raportoitua profiilikorjausta asiakasriippuvaisena eikä yleisenä.

Saman kannettavan virtuaalikone ei peri tästä mitään. Anna vieraalle oma resolverimerkintä sisäiselle verkkotunnukselle tai anna hypervisorin NATin välittää sen kyselyt isännän kautta, mikä on oikein vain niin kauan kuin isännän tunneli on pystyssä.

Historia on kolmas syy. Aiemman profiilin DNS-palvelimet tai jälkiliiteasetukset voivat säilyä uudelleenyhdistämisten yli, joten kun sovitin näyttää oikealta ja haut yhä epäonnistuvat, vertaa elävää sovitinta komennon Get-VpnConnection kanssa ja tyhjennä tai korvaa vanhentunut merkintä ennen kuin kosket palvelimeen.

Todista, minne kysely meni

Kaappaus yhden haun aikana ratkaisee väittelyn: tcpdump -ni eth0 port 53 näyttää kyselyt fyysisellä liitännällä, mikä tarkoittaa, että ne lähtevät tunnelin ulkopuolelle eikä resolveria koskaan vaihdettu. dig @10.8.0.1 name.corp.example erottaa sitten kaksi jäljellä olevaa tapausta. Jos suora kysely vastaa, resolveri toimii eikä asiakas käytä sitä; jos se aikakatkaistaan, resolveri ei ole tunnelin kautta tavoitettavissa eikä mikään paikallinen muutos auta.

Jos yhä käytössä oleva resolveri on se, jonka palveluntarjoaja jakoi, tunneli salaa liikenteen, mutta nimet jäävät näkyviksi kyseiselle tarjoajalle. Se on vuotokysymys eikä toiminnallinen, ja sama kaappaus vastaa siihen: fyysisen liitännän kysely menee jollekin tunnelin ulkopuolelle.

Tavoitettavuus kattaa VPN-isännän palomuurin, jonka on sallittava UDP ja TCP 53 altaalta. Suljettu portti näyttää täsmälleen rikkinäiseltä työnnöltä, ja niin näyttää myös resolveri, joka vastaa vain tunneliverkon sisältä. Toista kaappaus yhden katkaisun ja uudelleenyhdistämisen jälkeen, koska asetukset, jotka ilmestyvät ensimmäisellä yhteydellä ja katoavat toisella, ovat koukun elinkaarivika eikä puuttuva asetus.

Pidä yksi omistaja ja tarkista järjestyksessä

Skripti, joka kirjoittaa sovittimen DNS:n uudelleen arvatun tunnelitilan perusteella, monistaa kokoonpanon, jonka profiili jo kuljettaa, ja epäonnistuu hiljaisesti ensimmäisen kerran, kun arvaus on väärä. Suosi yhteyden omia DNS-asetuksia tai yhtä dokumentoitua koukkua ja kirjaa, kumman valitsit, jotta seuraava henkilö ei lisää toista.

Sulje silmukka neljällä tarkistuksella: työnnetty osoite tunnelilinkillä, sisäinen nimi ratkeaa täysin kvalifioituna nimenä, sama nimi ratkeaa ilman jälkiliitettä, ja molemmat ovat yhä totta yhden uudelleenyhdistämisen jälkeen. Yksi kaappaus kertoo, mikä neljästä epäonnistui. OpenVPN 2.6 -käsikirja luettelee dhcp-option ja skriptidirektiivit alustakohtaisine huomautuksineen.