Eu descobri: os dois online-dns
servidores ( customer.com
e mysite.com
) tinham a configuração dos registros de caracteres curinga, por exemplo, um A-record
como *.mysite.com
Portanto, quando o DNS interno de ad.customer.com
foi consultado para um fqdn em ad.mysite.com
, ele foi encaminhado para o DNS on-line, o DNS on-line responsável por mysite.com
respondeu com o IP principal devido a seu caractere curinga Um registro:
Nãoconsigoalterarosregistrosdedomínioparaocliente,maspossoalterarosnossos.Então,euconfigureiasmétricasparaqueaconexãoremote
fosseusadaprimeiro,masparaonossotldeudesativeiocuringa,deixandoapenasvalid
nomesdehostparaseremrespondidos.
Portanto,seumaVPN-Connectionforestabelecidaagora,oWindowscomeçaráaconsultarosDNSlocaisdosclientes,mesmoparanomesdehostinternos,masnãoreceberámaisumarespostaerrada(devidoaoencaminhamentoparaoDNSonline),masnada.
AgoraoWindowsparececonsultarosservidoresdeDNSdaconexãosecundária(local,maiormétrica),quefuncionaelevaaoresultadocorreto:
Conhecendoacausa,outrasolução-talvezmelhor-foifácildeencontrar:EnquantoaSolução1sempreconsultariaoDNSlocaldosclientesprimeiro,estetrabalhaprimeirocomaconsultadonossoDNSlocal:
Primeiro,ofc.Asmétricasdasduasconexõesforamalteradas,paraqueaconexãolocalsejausadaprimeiro.
DentrodonossoservidordeDNSlocal,euconfiguroumazonaprimária,quecorrespondeaodomíniodeclientes:customer.com
-eadeixovazia.
Agora,nossoDNSlocalresponderácomnotfound
emvezdeencaminharaconsultaparaosclientesusandoocuringausandooonline-dns-server.(Quenãopoderesolverseusnomesinternos)
MeuPCagorausaráasegundaconexão(remota),ondeaconsultadenomesinternospodeserresolvida.
Inconveniente:semumaconexãoVPNestabelecida,nãopossomaisacessarositedocliente,porqueoDNSlocalnãoestámaisencaminhandoessasconsultas.
Seeuprecisassedissotambém,eupoderiaconfigurarregistrosAna"Fake-primary-Zone" ofc.