Per què un punt final privat encara respon amb una adreça pública

L'ordinador es connecta, el túnel es declara actiu i el compte d'emmagatzematge continua rebutjant totes les peticions. El punt final privat existeix, la ruta cap a la seva subxarxa existeix, i el nom o bé respon amb una adreça pública o bé no es resol. No hi ha res malament amb el túnel: mai no es va dir al client quin servidor havia de respondre per aquell nom. Seguiu la consulta cap enfora i la mancança es fa evident.

Comenceu pel resolutor del client

Pregunteu al client a quin servidor consulta mentre el túnel és actiu. Un perfil punt a lloc subministra aquesta adreça, i un perfil que no subministra res deixa que el sistema operatiu torni als valors predeterminats de l'adaptador.

Els resolutors públics no veuen cap zona privada, així que responen des d'Internet, que és exactament la seva feina. La primera comprovació és, doncs, l'adreça del resolutor en ús, no el túnel ni el punt final.

Llegiu què és realment la resposta

Resoleu el nom del servei i llegiu l'adreça que torna. Una resposta pública vol dir que la consulta ha arribat a un servidor que no pot veure la zona. Cap resposta vol dir que el nom només existeix de manera privada i que res que el client pugui abastar no el té.

Aquests dos resultats produeixen errors d'aplicació semblants i pertanyen a propietaris diferents. Un és un problema de selecció de resolutor, l'altre és un enllaç de zona que falta.

Una entrada hosts demostra el camí i després menteix

Posar l'adreça del punt final al fitxer hosts local és la manera més ràpida de demostrar que el túnel i el tallafoc del servei ja funcionen. Si la petició té èxit amb aquesta entrada, només és la resolució de noms que està trencada. També és una modificació per màquina que cobreix exactament un nom.

No ajuda el segon compte, el segon punt final ni un company, i es trenca sense avís quan el punt final es torna a crear en una adreça nova.

Pitjor encara, fa que la vostra màquina es comporti de manera diferent de la de tothom, i així és com una fallada del resolutor sobreviu una setmana d'investigació. Feu-la servir per confirmar el camí, després traieu-la i arregleu la causa.

Enllaceu la zona i repartiu un resolutor

Dues condicions s'han de complir alhora. La zona privada ha d'estar enllaçada a la xarxa virtual on viu el punt final, i el client ha d'enviar les seves consultes a un servidor que pugui llegir aquesta zona. Un punt final d'entrada de DNS Private Resolver proporciona aquesta adreça dins de la xarxa i respon les consultes que arriben pel túnel. Poseu aquesta adreça al perfil de VPN i afegiu el sufix privat que el client ha d'aplicar.

Un resolutor local ja existent pot arribar al mateix resultat mitjançant un reenviador condicional adreçat a la zona.

Les regles de xarxa del resolutor compten tant com l'encaminament. Si la regla d'entrada exclou el rang de clients de VPN, les consultes expiren en comptes de retornar una resposta incorrecta. És aquesta expiració la que torna la gent a una taula de rutes on no hi ha res malament.

Comproveu nom, port i identitat per ordre

Treballeu per ordre: resoleu el nom, confirmeu que la resposta és privada, obriu el port i feu una petició autenticada. Cada etapa té el seu propietari i la seva signatura de fallada.

Una resposta privada seguida d'una expiració apunta a una ruta o a un tallafoc. Una resposta pública apunta al resolutor. Una connexió completada que retorna un error d'identitat pertany al servei.

Una fallada més pertany a aquesta llista. Un tallafoc de servei que permet una adreça de client deixa de coincidir quan el pool assigna aquesta adreça a una altra sessió després de tornar-se a connectar. Llegiu l'adreça del cridador que el servei ha registrat, no la que el client creu que té. Les dues discrepen més sovint del que la gent espera. La guia d'Azure DNS Private Resolver cobreix l'enllaç de zona i la disposició de reenviament.