Pritunlin yksityinen DNS epäonnistuu? Lisää kapea resolver-reitti

Yksityiset nimet ratkeavat kaikille yritysverkossa ja vanhenevat kaikille VPN:ssä. Resolver vastaa yhdyskäytävälle, reitti sinne on olemassa, ja kysely ei silti koskaan saa vastausta. Puuttuva ei ole toinen julkinen resolver tai leveämpi reitti: se on lähdeosoite, jolle yksityinen DNS-palvelin on valmis vastaamaan.

Vahvista, että resolver hylkää asiakaspoolisi

Aloita osoittamalla, että vika koskee lähdettä, ei tavoitettavuutta. Kysy yhdistetystä asiakkaasta yksityistä resolveria suoraan ja seuraa, vanheneeko pyyntö vai palautuuko se hylkäyksenä. dig @10.40.0.53 intranet.example.net +time=2 +tries=1 vanhenee, kun sama kysely yhdyskäytävästä onnistuu, viittaa resolverin käyttöoikeuskäytäntöön. SERVFAIL-vastaus viittaa aivan muualle, yleensä vyöhykkeeseen tai ylävirran välittäjään.

Kirjaa asiakkaan osoite ennen testausta. ip -4 addr show tun0 asiakkaassa tai konsolissa näkyvä lease kertoo, minkä poolin resolver näkee.

Vahvista sitten, että polku ylipäätään on olemassa. Reitti, joka lähettää resolverin osoitteen tunneliin, on edellytys, ei korjaus; jos paketit eivät koskaan saavu, lähdekäytäntöä ei koskaan kuulla. Tarkista se ip route get 10.40.0.53 asiakkaassa.

Lisää yksi isäntäreitti sen sijaan, että kääntäisit kaiken

Pritunlin yksityisen DNS:n ohje kuvaa kapean keinon: NATilla varustettu /32-reitti resolverin osoitteelle, ja tämä osoite valitaan asiakkaiden DNS-palvelimeksi. Reitti muuttaa lähdettä, jonka resolver näkee, vain DNS-liikenteelle. Sovellusliikenne säilyttää lähdettä säilyttävän suunnittelun, jonka valitsit sille.

Määritä se palvelimen tuetun reittien omistajan kautta, kun olet tarkistanut olemassa olevat reitit päällekkäisyyksien varalta. Yllä olevassa esimerkissä kohde on 10.40.0.53/32 NATilla, ja asiakaspooli pysyy 10.90.0.0/24. Älä käännä koko yksityistä aluetta yhden palvelun korjaamiseksi, koska jokainen alavirran käytäntö, joka nojaa asiakkaan todelliseen osoitteeseen, alkaa nähdä sen sijaan yhdyskäytävän. Vahvista osoite, jonka resolver todella saa, seuraamalla sen kyselylokia testihaun aikana. Pelkkä isäntäreitti ei todista mitään käännöksestä tai luvasta.

Resolverin on edelleen sallittava käännetty lähde UDP:llä ja TCP:llä, ja sen vastausten on voitava palata. Lähteen muuttaminen ei voi luoda puuttuvaa vyöhykettä tai tietuetta.

Päätä, lähettääkö kyselyn palvelin vai asiakas

Pritunl dokumentoi myös DNS-välitysjärjestelyn, joka liittyy VPN Client DNS Mappingiin, jossa palvelin välittää ylävirran kyselyitä asiakkaiden puolesta. Siinä mallissa ylävirran lähde kuuluu palvelimen omaan verkkokontekstiin, ja asiakaspuolen poikkeus on väärä korjaus.

Tunnista, mikä malli on aktiivinen ennen kuin lisäät mitään. Kolme päällekkäistä korjausta, välityspalvelin, asiakkaan resolverin ohitus ja manuaalinen NAT-skripti tarkoittavat yleensä sitä, ettei kukaan ole selvittänyt: minkä komponentin pitäisi lähettää kysely. Tarkista myös bootstrap: vain yksityinen resolver ei voi olla ainoa tapa löytää päätepiste ennen tunnelin olemassaoloa, eikä pysyvä resolverin muutos saisi elää yhteyttä pidempään.

Testaa yksityistä hakua, älä julkista verkkosivua

Kun olet ottanut muutoksen käyttöön ja yhdistänyt uudelleen, tarkista asiakkaan tehollinen resolver-kokoonpano ja ratkaise sitten nimi, jonka tiedät olevan olemassa vain yksityisellä vyöhykkeellä. dig intranet.example.net ilman nimenomaista palvelinta näyttää, mitä asiakas todella käyttää. Jatka pyynnöllä osoitteeseen, jonka haku palautti, koska ratkaisu ja palvelun käyttö ovat erillisiä vaiheita. Selain, joka lataa julkisia sivustoja DNS-over-HTTPS:n kautta, ei todista mitään käyttöjärjestelmän yksityisestä resolver-polusta. Julkinen toissijainen resolver ei ole sekään sisäisen vyöhykkeen auktoriteetti.

Kirjaa resolverin osoite, /32-reitti ja asiakkaan DNS-asetus yhdessä palvelimen muistiinpanoihin. Puolet tästä kokoonpanosta yksin palautettuna toistaa alkuperäisen vian.

Vahvista lopuksi, että tunneli reitittää sovelluskohteen edelleen DNS:n onnistumisen jälkeen. Reitti, palvelun käyttö ja todennus pysyvät riippumattomina nimien ratkaisusta, eikä toimiva haku kerro mitään läpimenosta. Jos yksityinen sivu on hidas mutta ratkeaa, resolver teki tehtävänsä ja ongelma siirtyi polulle.