Dyn VPN-domein yn dnsmasq is gjin sône-oerdracht

Do sjochst nei de bedriuwsône yn 'e dnsmasq-konfiguraasje fan 'e klient, fynst dy net en konkludearrest dat de VPN syn domein net pusht hat. Wat pusht waard, is in routinghint, gjin sône. De klient registrearret it domein en de resolver dy't derop antwurdzje moat, en de behearde backend makket dêr betingst trochstjoeren fan. Op 'e ferkearde plak sykje jout in selsbewuste en folslein ferkearde diagnoaze.

Wat de klient akseptearre, is net wat de gateway oanbea

In gateway kin in resolver, in domein en de rûte oanbiede dy't nedich is om dy resolver te berikken, en de klient kin alle trije of gjinien dêrfan akseptearje. In ymportearre profyl, in helpscript of in belied dat pushte opsjes negearret, kin de akseptearre set leech litte wylst de serverside korrekt liket. Begjin by de registrearre steat fan 'e klient ynstee fan 'e konfiguraasje fan 'e server, want dy steat is wat de resolver echt ûntfangt. As it akseptearre domein mist, sil neat fierder noch wat útmeitsje. Kontrolearje de DNS-eigenskippen fan 'e ferbining foardatsto in cache ûndersykest.

Dat ûnderskied ferklearret de measte rapporten fan in domein dat nea oankaam. It waard oanbean, en it waard net tapast.

Twa soarten domeinynfieringen

In ferbining kin gewoane sykdomeinen en allinich-rûte-domeinen drage, en it twadde soarte begjint mei in tilde. In sykdomein rûtelet sawol queries as lit koarte nammen útwreidzje, wat handich is op in wurkstasjon en fernuverjend op in server. In allinich-rûte-domein seit dat queries foar dat efterheaksel nei spesifike servers gean moatte sûnder te feroarjen hoe't koarte nammen oplost wurde. Itselde domein op beide manieren skriuwe is gjin oerstalligens, want de twa ynfieringen dogge ferskillend wurk.

Foar in privee nammerom is de allinich-rûte-foarm meastentiids dejinge dy'tsto wolst. It hâldt it bedriuwsachterheaksel nei de bedriuwsresolver rjochte en lit al it oare gewurde.

localhost yn resolv.conf is gjin bug

As in lokale cacheresolver brûkt wurdt, wiist it systeembestân nei it loopback-adres en neat oars. Dy ynfiering identifisearret de lokale listener, net de upstreamservers dy't de manager deroan joech. It bedriuwsadres sil mei rjocht ôfwêzich wêze yn it bestân.

Dy ynfiering ferfange troch in iepenbiere resolver is de klassike ferkearde oplossing. It stellt iepenbiere namme-oplossing werom en smyt it betingste belied yn deselde bewurking fuort.

Ferwarje de backends net

In behearde dnsmasq-ynstânsje en in systeemresolver binne ferskillende programma's mei ferskillende konfiguraasje en ferskillende statusbylden. In statusopdracht foar de iene meldt neat nuttich oer de oare.

Stel fêst hokker backend de manager brûke moat, en lês dan de generearre konfiguraasje fan dy backend ynstee fan in distribúsjebreed bestân dat tafallich bestiet. De manager skriuwt syn eigen ynstânsjekonfiguraasje en stipet oanpaste opsjes foar dy ynstânsje, dus in net besibbe globaal bestân bewurkje feroaret neat en liket op in feroaring sûnder effekt. In twadde daemon op poarte 53 starte is slimmer as nutteleas, want no binne twa programma's it net iens oer wa't de poarte besit. Stel earst de eigner fêst, bewurkje dan wêr't dy eigner lêst.

Test it nammerom, net allinnich it antwurd

Freegje ien tastien privee namme en ien iepenbiere kontrôlenamme op fia it normale paad fan 'e applikaasje. In direkte query tsjin 'e bedriuwsseerver bewiist dat it record bestiet; it bewiist net dat de klient dy server keazen hat. De twadde query is dejinge dy't belied test.

Werhelje dat dan nei in werferbining en nei in ferbrutering. De assosjaasje moat de libbenssyklus fan 'e ferbining folgje, en de priveenammen moatte ophâlde op te lossen as de tunnel fuort is, ynstee fan werom te fallen op in iepenbiere resolver dy't foar itselde efterheaksel antwurdet. Falle se dochs werom, dan hast in lek fûn, wat in oar defekt is as in brutsen opsoch. Skriuw op hokker backend rûn, hokker domeinen tapast waarden en wat elke query weromjoech.