Carrion: /* wserver como reenviador */

2011-12-06T20:52:58Z

wserver como reenviador

Página nueva

==Introdución==
*A continuación vaise aplicar o [http://es.wikipedia.org/wiki/Principio_de_Pareto principio de Pareto] á resolución do [[Escenario completo 4.F]].
*Vanse ver distintas solucións:
**Unha incorrecta que é a que se desexa evitar e é a primeira de todas.
**A solución sinxela e recomendada para cando xurdan problemas detectalos máis facilmente.
**Unhas solucións complexas e pouco recomendadas pola súa complexidade á hora de detectar problemas.
**Unha solución ideal, que é usando servidores secundarios pero que non se viron no curso.

*Antes de continuar o usuario debe distinguir claramente entre as partes servidor e cliente do servizo DNS:
**Servidor DNS: é o que resolve (ben consultando nas zonas que xestiona ou ben preguntando a outros servidores DNS) nomes de dominio a IPs e viceversa (se hai zonas de busca inversa).
**Cliente DNS: é o que pregunta á un ou varios servidores DNS por un nome de dominio para obter a súa IP (ou viceversa).
**Aquí é importante facer notar que todos servidor DNS tamén é cliente DNS, pero a configuración cliente DNS dun servidor só afecta ás consultas que se inician desde el e non afecta para nada ao servidor DNS que nel estea instalado.

==Configuración básica servidores==
[[image:00_Simulacion_Redes_Escenarios_Semana_04_F_Solucións_1.jpg|600 px]]
*O primeiro que se faría sería configurar os servidores:

*'''wserver''' crear as zonas:
**de busca directa: depor.local
**de busca inversa: aquí hai varias opcións que depende de como as cre o usuario, pero todas válidas:
***Opción 1: 213
***Opción 2: 60.213
***Opción 3: 254.60.213

*'''zserver''' crear as zonas:
**de busca directa: olimpia.local
**de busca inversa xa a crea atomaticamente Zentyal cando se dan os hosts de alta.

*Por agora non se fixo ningunha configuración do cliente DNS.

==Solución incorrecta: Configuración clientes DNS==
*Nestas imaxes vese como están configurado (cor vermello) os clientes DNS.
[[image:00_Simulacion_Redes_Escenarios_Semana_04_F_Solucións_2A.jpg|600 px]]
*'''Servidores''': cada un deles apuntaría a se mesmo.
*'''wclient e ulcient:
**DNS primario: 172.16.0.110
**DNS alternativo: 172.16.0.120
**Para este caso tamén valería cambiando o primario polo alternativo.
**Sufixos DNS: depor.local, celta.local

*Pero esta configuración de cliente DNS primario e alternativo ten problemas:
**"celta.local" nunca non será alcanzable mentres o servizo DNS de '''wserver''' estea accesible. Por que?.
***Porque cando '''uclient''', por exemplo, faga ping a '''balaidos.celta.local''', este consultará ao servidor DNS primario, 172.16.0.110 neste caso. O servidor DNS '''wserver''' mira nas súas zonas de busca directa e non ten '''celta.local''', co cal mira na súa cache e tampouco atopa nada. Finalmente '''wserver''' consulta ao exterior, ben reenviando ao ISP ou aos servidores raíz por recursividade. Pero fóra tampouco saben nada de '''celta.local'''. Co cal '''wserver''' vaille responder aos clientes que '''balaidos.celta.local''' non existe. E iso é co que se quedan os clientes, non van a consultar a un servidor alternativo, porque en boa lóxica teríalle que dicir o mesmo, que '''balaidos.celta.local''' non existe.

*Cando un cliente DNS fai uso do DNS alternativo?. Cando o servidor DNS primario non estea accesible:
*Razóns polas que un servidor DNS pode estar non accesible:
**Cable de rede do servidor desconectado.
**Servidor apagado.
**Servizo DNS parado.
**Firewall que non permite consultas DNS.
**Servidor DNS .... miles de causas...

*A seguinte imaxe amosa que '''wserver''' non é accesible, por calquera das razóns anteriores.
[[image:00_Simulacion_Redes_Escenarios_Semana_04_F_Solucións_2B.jpg|600 px]]
*Neste caso, o mesmo cliente de antes '''uclient''', pregunta por '''balaidos.celta.local''' ao servidor DNS primario, 172.16.0.110 e tras esperar un tempo non recibe ningunha resposta de '''wserver''', nin positiva, nin negativa. É neste caso, entón, cando o cliente pasa a preguntar ao servidor DNS secundario/alternativo, 172.16.0.120.
*Neste caso '''zserver''' é consultado, si que xestiona '''celta.local''' e dentro ten un equipo '''balaidos''' co cal devólvelle a IP a '''uclient'''.

*'''Problemas desta solución'''
**Se os 2 servidores están accesibles hai unha das zonas que non é accesible.
**Se o servizo DNS de '''wserver''' non está accesible obtéñense resultado distintos a cando está accesible e iso non ten senso.

*'''Conclusión'''
**Esta solución é a que se desexa evitar. Se a configuración cliente DNS apunta a servidores que non teñen a mesma información, ou que non xestionan as mesmas zonas, obtéñense resultados erráticos.

==Solución básica correcta: reenvío simple==
*A solución e moi simple:
**Toda configuración cliente DNS apunta a un dos servidores.
**O servidor elixido no paso anterior reenvía ao outro servidor.

===wserver como reenviador===
[[image:00_Simulacion_Redes_Escenarios_Semana_04_F_Solucións_3A.jpg|600 px]]

*'''wclient''' e '''uclient:'''
**Só configurar o DNS primario que apunte a 172.16.0.110

*'''wserver''':
**'''Servizo servidor DNS''': configuralo para que reenvíe ao servidor DNS 172.16.0.120
**'''Cliente DNS''': só configurar o DNS primario apuntando a se mesmo. Engadir os sufixos DNS depor.local e celta.local.

*'''zserver''':
**'''Servizo servidor DNS''': non tocalo ou configuralo para que reenvíe aos servidores DNS do ISP.
**'''Cliente DNS''': só configurar o DNS primario apuntando a '''wserver''' ou que apunte a se mesmo, todo depende se desde este servidor se van lanzar consultas sobre o dominio '''depor.local'''. Engadir os '''sufixos DNS''' '''depor.local''' e '''celta.local'''. O primeiro valerá a pena se se configura o cliente DNS para consultar a 172.16.0.120.
**Observar que se está a falar de que a configuración cliente DNS zserver apunte ou non a wserver, pero esta decisión só afecta para as preguntas que se inician dende zserver e non afecta para nada aos demais clientes da rede que estes só preguntan aos sevizos DNS dos servidores.

*'''Resolución de problemas'''
**Neste caso a configuración é moi sinxela para manexar mentalmente por calquera administrador.
**Os clientes non resolven nomes internos nin externos: entón o servizo DNS de '''wserver''' non está accesible.
**Os clientes resolven nomes internos, pero non externos: hai problemas en no servizo DNS de '''zserver'''.

*Conclusión:
**Esta é a solución máis axeitada, cos servidores que se teñen, pois é moi sinxela na implantación e por tanto ante un fallo calquera de resolución DNS é fácil detectar onde está o problema.

*Agora xa só quedaría implantar a configuración deste escenario ou o da seguinte imaxe nas MVs.

===zserver como reenviador===
*Este escenario é o mesmo que o anterior, coa diferenza, de que quen actúa como reenviador é '''zserver''' e todo cliente DNS primario pregunta a 172.16.0.120.
[[image:00_Simulacion_Redes_Escenarios_Semana_04_F_Solucións_3B.jpg|600 px]]

==Solución complexa correcta (Non recomendada): reenvío cruzado==
*A solución que se vai ver a continuación proporciona algo de redundancia para o acceso ao exterior. Está baseada na mistura da primeira e da segunda solucións anteriores.
[[image:00_Simulacion_Redes_Escenarios_Semana_04_F_Solucións_4A.jpg|600 px]]
*'''wclient'' e '''uclient''':
**Servidor DNS primario: 172.16.0.120
**Servidor DNS secundario: 172.16.0.110
**Poderíanse cambiar os servidores anteriores de orde.

*'''wserver'' e '''zserver''':
**Servizo DNS: configurar o reenviador de cada servidor para enviar ao servidor contrario.
**Cliente DNS: configurar cada servidor para que se consulte a se mesmo.

*'''Problemas'''
**Neste escenario hai un lazo nos servidores, que ante unha consulta de resolución dun nome externo, estes comézanse a pasar a pelota un ao outro, pero como, por defecto, cando se reenvía unha consulta o reeviador abre un temporizador para recibir unha resposta, se non a recibe ningunha resposta no tempo establecido pois reenvía ao seguinte reenviador (se hai) ou realiza a consulta por recursividade a través dos servidores raíz.

*'''Vantaxes:'''
A seguinte imaxe amosa unha vantaxe (que á par tamén é un inconveniente). Se fallase o servizo DNS do servidor 172.16.0.120 non estiver accesible, os clientes pasarían a preguntar ao servidor DNS secundario, co cal seguiría tendo a posibilidade de resolver nomes do exterior.

[[image:00_Simulacion_Redes_Escenarios_Semana_04_F_Solucións_4B.jpg|600 px]]

==Solución complexa non correcta: reenvío cruzado==
*Baseada na solución anterior, alguén podería pensar en balancear a carga entre os servidores, de xeito que uns clientes pregunten a un servidor e outros clientes a outros.

[[image:00_Simulacion_Redes_Escenarios_Semana_04_F_Solucións_5.jpg|600 px]]

*Isto ten un problema, que se pasa pasado un tempo, os administradores teñen que estar moi áxiles. Por exemplo, se o servizo DNS de '''zserver''' non estivese accesible, habería clientes na rede que resolverían nomes DNS e outros non, coa cal, a reacción inicial é para volverse louco.

*'''Conclusión''': cando algo falle é mellor que se vexan todos afectados para á hora diagnosticar o problema sexa moito máis rápido que se uns equipos teñen un problema e outros non.

==Solución ideal: servidores secundarios==
*Esta configuración non se viu no curso.
*Consiste en facer un servidor backup (secundario) de cada un dos servidores primarios.
*Un servidor secundario ten unha copia do servidor principal. E un servidor principal en Windows pode ter un servidor secundario en Linux e viceversa.

*Na seguinte imaxe, de cada servidor primario hai un servidor secundario.
*Agora escóllese que parella de servidores (Primario e secundario) vai actuar como reenviador á outra parella, neste caso escolleuse como servidores reenviadores 172.16.0.120 e 172.16.0.121 para reenviar aos outros 2 servidores: 172.16.0.110 e 172.16.0.111 . Podería ser ao revés.
[[image:00_Simulacion_Redes_Escenarios_Semana_04_F_Solucións_6A.jpg|600 px]]
*Observar que que agora todo cliente apunta a 2 servidores que conteñen a mesma información e xestionan as mesmas zonas. Neste caso, servidor DNS primario 172.16.0.120 e servidor DNS secundario 172.16.0.121.

*Que pasa en caso de que o servizo DNS do servidor primario non estea accesible?.
[[image:00_Simulacion_Redes_Escenarios_Semana_04_F_Solucións_6B.jpg|600 px]]
*Pois que os clientes preguntarán a un servidor secundario que ten a mesma información que o servidor primario.

Escenario completo 4.F - Solución - Historial de revisiones

Carrion: /* wserver como reenviador */