Kial MagicDNS solvas aparatojn sed ne oficejajn gastigantnomojn

MagicDNS donas al ĉiu aparato en tailnet nomon derivitan de ĝia maŝinnomo kaj de la DNS-domajno de la tailnet. Tiun nomon kreas Tailscale kaj ĝi estas respondata laŭ la solvila vojo de Tailscale. Oficeja gastigantnomo kiel files.office.example apartenas al zono, kiun Tailscale neniam skribis, do renomado de aparato ne povas krei ĝin. La du nomspacoj kunekzistas; ili simple havas malsamajn posedantojn.

Tiu mekanismo staras malantaŭ tre ofta raporto: la Tailscale-gastiganto respondas, kaj la dosier-servilo ankoraŭ redonas solvan eraron.

Du nomspacoj, du posedantoj

Aparata nomo estas generata el la propra gastigantnomo de la maŝino, koliziojn solvas Tailscale, kaj la rezulto loĝas sub la tailnet-domajno. Oficejan zonon prizorgas tiu, kiu funkciigas la oficejan solvilon, kun rikordoj kreataj de administranto aŭ per dinamika registrado. Mallongaj nomoj kaŝas la diferencon: files povas esti serĉ-sufiksa etendo respondata de la oficeja DNS, tailnet-aparato, aŭ tute nenio. Pridemandado per la plena nomo montras, kiu sistemo efektive respondis.

Ŝanĝi la maŝinnomon de la subreta enkursigilo faras nenion por la oficeja zono. Ĝi renomas unu Tailscale-aparaton kaj lasas la rikordon sur la oficeja servilo netuŝita, tial renomado kaj reprovo neniam konverĝas.

Direktu la oficejan zonon al ĝia solvilo

La dividita DNS de Tailscale sendas pridemandojn por elektitaj domajnoj al nomservilo, kiun vi specifas, kaj ĉio alia sekvas la restan politikon. Aldonu la domajnon, kiun la oficeja solvilo efektive servas, ne la serĉ-sufikson, kiun vi hazarde tajpas. Serĉ-sufikso diras al la kliento, kion aldoni; ĝi ne diras al la solvilo, kie rigardi. Tiuj du agordoj aspektas similaj en konzolo kaj kondutas tute malsame.

Limigita nomservilo devas esti aŭtoritata por la domajno asociita kun ĝi, alie la respondo estos referenco anstataŭ adreso.

Atingebleco venas antaŭ solvado

La kliento ankaŭ devas atingi tiun nomservilon. Por solvilo en privata LAN, la subreta itinero devas esti anoncita kaj akceptita, la alirpolitiko devas permesi la pridemandadon, kaj revena vojo devas ekzisti. Ĝusta DNS-adreso en la administra konzolo pruvas nur, ke la agordo estis konservita. Se pakaĵoj ne povas atingi la solvilon, la simptomo estas tempolimo, kiu aspektas alie ol aŭtoritata respondo, ke tia rikordo ne ekzistas.

Tiu diferenco estas diagnoza. Tempolimo indikas enkursigadon aŭ politikon, dum tuja negativa respondo indikas la rikordon aŭ la zonon. Legu, kiun vi ricevas, antaŭ ol ŝanĝi ajnan DNS-agordon.

Apartigu la nom-fiaskon de la serva fiasko

Se la rimedo respondas ĉe sia privata adreso sed ne laŭ gastigantnomo, la esploro restas ĉe DNS. Se neniu el ambaŭ funkcias, unue riparu enkursigadon aŭ la servon, ĉar nomo, kiu solviĝas al neatingebla adreso, ne estas progreso. Pridemandu la plenan nomon kaj notu, kiu servilo respondis. En macOS iuj komandliniaj iloj sekvas alian vojon ol ordinaraj aplikaĵoj, do terminalo dig kaj retumilo povas malkonsenti pri la sama nomo.

Ripetu la teston kun elektita elira nodo, se tio estas la normala reĝimo por la aparato. La DNS-traktado de elira nodo diferencas de la agordo sen elira nodo, kaj testado nur en unu reĝimo povas maltrafi la fiaskon, kiun uzantoj efektive vidas.

Notu la zonon, la solvilan adreson kaj la itinero, kiu portas la pridemandadon. Tiuj tri klarigas plej multajn MagicDNS-surprizojn sen plia renomada raŭndo.