Mallongaj internaj nomoj malsukcesas ĉe VPN: la sufikso, kiun vi neniam vidas
Mallonga nomo funkcias nur ĉar serĉa sufikso kompletigas ĝin. Komparu la plenan kaj la mallongan nomon por distingi mankon de sufikso disde fiasko de la solvilo.
La mallonga nomo funkciis en la oficejo kaj malsukcesas ĉe la VPN, dum la plena nomo solviĝas senprobleme. Nenio estas rompita. Nuda nomo kiel intranet ne estas kompleta nomo; la kliento aldonas sufikson el sia serĉlisto kaj demandas pri la rezulto. Se la VPN-profilo ne donas tiun sufikson, la konata mallonga formo ĉesas ekzisti.
Tio estas la tuta mito. DNS ne rompiĝis, la serĉa politiko ŝanĝiĝis.
Nuda nomo ne estas nomo
Kiam vi tajpas unu etikedon, la solvilo devas decidi pri kio demandi. Ĝi provas la nomon tiel, kiel ĝi estas donita, poste aldonas erojn el la serĉlisto unu post la alia, ĝis io respondas. En Linux, resolv.conf regas tiun ordon per la agordoj search kaj ndots. En Windows, la sufiksa listo kaj la nom-solva politiko faras la samon. Forigu la sufikson kaj la solvilo havas nenion aldonendan.
Funkcianta mallonga nomo do estas pruvo de politiko, ne pruvo de sana DNS-servilo.
Kion faras la sufiksa listo kaj la solvila adreso
Ĉi tiuj du konstante konfuziĝas. La solvila adreso diras, kiun demandi; la sufiksa listo diras, pri kiu nomo demandi. VPN povas doni al vi privatan solvilon sen sufiko, aŭ sufikon kun la malĝusta solvilo. Nur unu el tiuj fiaskoj aspektas kiel DNS-interrompo.
Kontrolu ilin aparte, ĉar ripari la malĝustan forbruligas subtenan fenestron.
| What you see | Likely cause |
|---|---|
| Full name resolves, short name fails | Suffix or search list missing |
| Neither resolves | Resolver unreachable or wrong domain rule |
| Both resolve, resource fails | Route or service permission |
Tri simptomoj, tri malsamaj posedantoj.
Unue testu la plenan nomon
Petu la dokumentitan plene kvalifikitan nomon de la administranto, ne konjekton. Funkcianta FQDN pruvas, ke la solvilo estas atingebla kaj ke la rikordo ekzistas, kio forigas duonon de la eblaj kaŭzoj per unu demando. Uzu ilon, kiu montras, kiu servilo respondis, por ke vi ne legu kaŝmemorigitan rezulton.
Tenu la teston privata. Sendi internajn variantojn al publika solvilo malkaŝas nomojn kaj testas politikon, kiun neniu intencis.
Kie apartenas la korekto
Korektu la posedantan profilon aŭ la administran sistemon, kiu generas ĝin. Mana ŝanĝo al la loka solvila agordo kutime malaperas ĉe rekonekto, aŭ aplikiĝas al ĉiu reto, kiun la maŝino aliĝas, kio estas pli malbona.
En Windows, kontrolu la efektivan politikon anstataŭ la markobutonon, kiun vi memoras. Get-DnsClientNrptPolicy montras la nom-solvajn regulojn, kiuj efektive validas.
En macOS, scutil --dns presas la solvilan agordon por ĉiu limigita interfaco, inkluzive de la serĉaj domajnoj, kiujn la VPN puŝis.
En Linux, legu la linion search en /etc/resolv.conf, sed kontrolu, ĉu VPN-kliento reverkis ĝin. Se la dosiero estas administrata, redaktu la fonton de vero anstataŭ la prezentitan dosieron. Malfreŝa linio search restinta de antaŭa reto estas ofta kaŭzo.
Kion konservi kun la profilo
Konservu la korektitan plenan nomon, la sufiksan liston kaj la solvilan adreson apud la klienta profilo. La sekva persono, kiu raportos, ke la intranet-ejo ne funkcias, povos kompari tri konatajn valorojn anstataŭ komenci de malplena paĝo.
Kaj se nur la mallonga formo malsukcesas, diru tion en la bileto. Tiu frazo ŝparas al la solvila teamo tutan posttagmezon.