OpenVPN-DNS yhdyskäytävässä: dnsmasq ja palomuurin laajuus

Aja dnsmasq tunneliosoitteessa, salli DNS vain asiakasryhmästä, työnnä selvittäjä ja testaa sitten suorat kyselyt ja sovelluksen oma haku.

Tunnelissa olevat asiakkaat pääsevät yhdyskäytävään ja yhdyskäytävä pääsee sisäiseen selvittäjään, joten DNS:n pitäisi toimia. Se ei toimi, koska ne ovat kaksi eri lupaa ja toimiva DNS-palvelu on kolmas asia. Kuuntelijan täytyy olla osoitteessa, johon asiakkaat pääsevät, palomuurin täytyy sallia kyselyt siihen osoitteeseen, ja asiakkaalle täytyy kertoa, että sitä käytetään. Tunnelin avaaminen molempiin suuntiin ratkaisee kaksi ensimmäistä sattumalta ja jättää kolmannen kesken.

Kuuntelija on paikallinen palvelu, jolla on kaksi suuntaa

Sisäänpäin asiakas lähettää kyselyn yhdyskäytävän tunneliosoitteeseen portissa 53. Ulospäin taustaprosessi välittää kyselyn määritetylle ylävirran palvelimelleen. Molempien puoliskojen täytyy toimia, ja ne epäonnistuvat eri tavoin.

Asiakkaan raportoima aikakatkaisu ja yhdyskäytävässä nähty aikakatkaisu eivät ole sama vika.

Sido tunneliosoite, älä jokaista osoitetta

Tähän työhön varattu dnsmasq-instanssi tarvitsee nimenomaisen kuunteluosoitteen, sidontatilan, joka sietää tunnelin ilmestymisen käynnistyksen jälkeen, ja yhden selvän ylävirran. Tämä on pienin käyttämäni versio:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic sitoo yksittäiset osoitteet ja tulee toimeen, kun tun0 ilmestyy myöhemmin, millä on merkitystä isännässä, jossa VPN-palvelu käynnistyy uudelleen. loopbackin listaaminen pitää paikalliset työkalut toiminnassa lisäämättä julkista kuuntelijaa. no-resolv estää taustaprosessia perimästä ylävirtoja isännän selvittäjäasetuksista, ja no-hosts estää tätä instanssia julkaisemasta yhdyskäytävän hosts-tiedostoa. Mikään näistä valinnoista ei anna kenellekään lupaa kysellä palvelua.

Tarkista, onko portissa 53 jo kuuntelija ennen kuin käynnistät toisen taustaprosessin, ja käytä jakelun asetusten omistajaa äläkä väärään hakemistoon eksynyttä tiedostoa.

Salli DNS-syöte, älä tunnelin läpikulku

Palomuurisäännöt, jotka saavat tämän toimimaan, ovat paikallisen syötteen sääntöjä, jotka on rajattu tunneliliittymään, asiakasryhmään, yhdyskäytävän osoitteeseen ja porttiin 53. Kaksi sääntöä, yksi protokollaa kohden, riittää:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS kulkee TCP:n kuin UDP:nkin yli, joten vain UDP:tä koskeva sääntö jättää suuret vastaukset epäonnistumaan tavalla, joka näyttää ajoittaiselta. Nämä eivät ole ufw route lupia, eikä niistä saa tulla laajaa sallintaa osoitteessa tun0. Järjestys on yhtä tärkeä kuin sisältö: aiempi sääntö, joka pudottaa kaiken syötteen osoitteesta tun0 voittaa edelleen, eikä sallinnan lisääminen lopullisen pudotuksen alle luo mitään.

Jos yhdyskäytävän DNS on nyt osa suunnittelua, tarkista se aiempi käytäntö tarkoituksella ja kirjaa miksi.

Ylävirran puolisko on erillinen polku

Kyselyt lähtevät yhdyskäytävästä sen omasta osoitteesta kohti ylävirran selvittäjää, joten yhdyskäytävän reitin ja kyseiseen selvittäjään kohdistuvan lähtökäytännön täytyy sallia vaihto. Tämä on eri sääntö kuin se, joka päästää asiakkaat kuuntelijaan, ja se epäonnistuu eri oireella.

Älä lisää rajoittamatonta tunnelilähtöä saadaksesi vastaukset toimimaan; seurattavat vastaukset eivät tarvitse sitä.

Työnnä valinta ja tarkista sitten luovutus

Palvelin voi ilmoittaa selvittäjän asiakkaille työnnetyllä valinnalla. Se on valinta, ei käsky, jota käyttöjärjestelmän on noudatettava:

push "dhcp-option DNS 10.90.0.1"

Linuxin komentoriviasiakas voi tarvita yhteyshallintansa selvittäjäintegraation, ja hallittu laite voi tarvita päivitetyn hallintaprofiilin. Vahvista aktiivinen selvittäjä asiakkaassa yhdistämisen jälkeen sen sijaan, että olettaisit työnnön tulleen sovelletuksi. Kun kaksi mekanismia yrittää asettaa DNS:n samaan aikaan, syntyy kilpailu, joka näkyy vilkkuvana nimien selvityksenä.

Tavoitteena on yksi omistaja asiakkaan selvittäjäasetuksille, ja työntö on yleensä tuo omistaja vain silloin, kun asiakasalusta on samaa mieltä.

Testaa se, minkä todella rakensit

Kysy yhtä yksityistä täysin kelvollista nimeä ja yhtä sallittua ulkoista nimeä suoraan tunneliosoitteelta sekä UDP:n että TCP:n yli. Toista sitten sovelluksen tavallista hakupolkua pitkin.

Jos suorat kyselyt toimivat ja sovellus silti epäonnistuu, vika on luovutuksessa eikä palvelimella:

  • Asiakas ei koskaan soveltanut työnnettyä valintaa.
  • Toinen selvittäjä asetettiin myöhemmin ja voitti kilpailun.
  • Sovellus käyttää omaa selvittäjäkirjastoaan tai välimuistiin tallennettua vastausta.

Lopeta vahvistamalla, että hyväksytyn VPN-polun ulkopuolinen lähde ei voi käyttää kuuntelijaa lainkaan. Onnistunut selvitys ei valtuuta palautettua osoitetta, joten pidä nämä kaksi kysymystä erillään.

Aiheeseen liittyvät artikkelit