Etsit yrityksen vyöhykettä asiakkaan dnsmasq-kokoonpanosta, et löydä sitä ja päättelet, että VPN ei työntänyt verkkotunnustaan. Työnnetty asia on reititysvihje, ei vyöhyke. Asiakas tallentaa verkkotunnuksen ja resolverin, jonka pitäisi vastata siitä, ja hallittu backend muuttaa sen ehdolliseksi välitykseksi. Väärästä paikasta etsiminen antaa itsevarman ja täysin väärän diagnoosin.

Se, mitä asiakas hyväksyi, ei ole se, mitä yhdyskäytävä tarjosi

Yhdyskäytävä voi tarjota resolverin, verkkotunnuksen ja reitin, joka tarvitaan kyseiseen resolveriin pääsemiseksi, ja asiakas voi hyväksyä kaikki kolme tai ei yhtään niistä. Tuotu profiili, apuskripti tai käytäntö, joka jättää huomiotta työnnetyt asetukset, voi jättää hyväksytyn joukon tyhjäksi, vaikka palvelinpuoli näyttää oikealta. Aloita asiakkaan tallennetusta tilasta äläkä palvelimen kokoonpanosta, koska juuri sen tilan resolver todella vastaanottaa. Jos hyväksytty verkkotunnus puuttuu, mikään myöhempi ei enää vaikuta. Tarkista yhteyden DNS-ominaisuudet ennen kuin tutkit mitään välimuistia.

Tämä ero selittää useimmat raportit verkkotunnuksesta, joka ei koskaan saapunut. Sitä tarjottiin, eikä sitä otettu käyttöön.

Kahdenlaisia verkkotunnusmerkintöjä

Yhteys voi kuljettaa tavallisia hakutoimialueita ja vain reititykseen tarkoitettuja toimialueita, ja jälkimmäinen laji alkaa tilde-merkillä. Hakutoimialue sekä reitittää kyselyt että antaa lyhyiden nimien laajentua, mikä on kätevää työasemalla ja yllättävää palvelimella. Vain reititykseen tarkoitettu toimialue kertoo, että kyseisen suffiksin kyselyt pitäisi ohjata tietyille palvelimille muuttamatta sitä, miten lyhyet nimet ratkaistaan. Saman toimialueen kirjoittaminen molemmilla tavoilla ei ole tarpeetonta, koska kaksi merkintää tekevät eri tehtäviä.

Yksityiselle nimiavaruudelle haluat yleensä vain reititykseen tarkoitetun muodon. Se pitää yrityksen suffiksin osoitettuna yrityksen resolverille ja jättää kaiken muun rauhaan.

localhost resolv.confissa ei ole vika

Kun käytössä on paikallinen välimuistiresolver, järjestelmätiedosto osoittaa loopback-osoitteeseen eikä mihinkään muuhun. Tämä merkintä yksilöi paikallisen kuuntelijan, ei ylemmän tason palvelimia, jotka hallinta antoi sille. Yrityksen osoite puuttuu tiedostosta perustellusti.

Tämän merkinnän korvaaminen julkisella resolverilla on klassinen väärä korjaus. Se palauttaa julkisen nimien ratkaisun ja hylkää ehdollisen käytännön samassa muutoksessa.

Älä sekoita backendejä

Hallittu dnsmasq-instanssi ja järjestelmän resolver ovat eri ohjelmia, joilla on erilainen kokoonpano ja erilaiset tilanäkymät. Toisen tilakomento ei kerro toisesta mitään hyödyllistä.

Selvitä, mitä backendia hallinnan on määrä käyttää, ja lue sitten kyseisen backendin luotu kokoonpano sen sijaan, että lukisit koko jakelun tiedostoa, joka sattuu olemaan olemassa. Hallinta kirjoittaa oman instanssinsa kokoonpanon ja tukee kyseisen instanssin mukautettuja asetuksia, joten liittymättömän globaalin tiedoston muokkaaminen ei muuta mitään ja näyttää muutokselta ilman vaikutusta. Toisen daemonin käynnistäminen portissa 53 on pahempaa kuin hyödytöntä, koska nyt kaksi ohjelmaa on eri mieltä siitä, kenen portti on. Selvitä ensin omistaja ja muokkaa sitten siellä, missä omistaja lukee.

Testaa nimiavaruutta, älä vain vastausta

Kysy yhtä sallittua yksityistä nimeä ja yhtä julkista kontrollinimeä sovelluksen tavallista polkua pitkin. Suora kysely yrityksen palvelimelle todistaa, että tietue on olemassa; se ei todista, että asiakas valitsi kyseisen palvelimen. Toinen kysely on se, joka testaa käytäntöä.

Toista sitten uudelleenyhdistämisen ja yhteyden katkaisemisen jälkeen. Liitoksen pitäisi seurata yhteyden elinkaarta, ja yksityisten nimien pitäisi lakata ratkeamasta, kun tunneli on poissa, sen sijaan että ne palaisivat julkiseen resolveriin, joka vastaa samasta suffiksista. Jos ne kuitenkin palaavat, olet löytänyt vuodon, mikä on eri vika kuin rikkinäinen haku. Kirjoita muistiin, mikä backend toimi, mitkä toimialueet otettiin käyttöön ja mitä kukin kysely palautti.

Aiheeseen liittyvät artikkelit