Microsoft Lync Server
Header

Después de los dos primeros artículos (Requisitos de HW y SW para una Infraestructura IT de Comunicaciones Unificadas para PYMES (Parte I de IV), Requisitos de HW y SW para una Infraestructura IT de Comunicaciones Unificadas para PYMES (Parte II de IV)) de los que consta esta serie de 4, vamos a ver uno de los más comunes (no recomendados) esquemas de red en las pequeñas empresas (pulsar en la imagen para verla a tamaño real):

Esquema_Basico_ST_Parte_III.jpg
En este tercer artículo vamos a trabajar sobre esta topología (pulsar en la imagen para verla a tamaño real):
Esquema_Basico_ST_1.jpg 
Como os comentaba al principio del artículo es la configuración más "típica" entre las PYMES, puesto que con los básico en cuanto a hardware de comunicaciones, implementamos un sistema "igual" que los dos anteriores (salvando las distancias), por lo menos en cuanto a topología a nivel lógico (direccionamiento IP, PortForwarding, etc..). Aquí lo que vamos a cambiar con respecto a la anterior configuración, es que si vamos a poner en TEAM las interfaces dedicadas para las MV, pero ninguna de ellas tendrá etiquetado de VLAN (porque en este caso el switch no lo soporta). En el primero artículo os había dejado un artículo que había publicado en su momento sobre la configuración de TEAM sobre Windows Server 2012, aquí os lo vuelvo a exponer por si no lo habíais leido: TEAMING en Windows Server 2012 (Actualizado 04-01-2013).  Lo único que comentaré aquí a mayores, es que la configuración del TEAM de 3 de las 4 tarjetas de red que tiene el servidor (OJO: la foto pertence al artículo anteriormente citado, lo puntualizo para no confundiros), y el modo del TEAM será Switch Independent:
Esquema_Basico_ST_1_RED.jpg 
Con esta configuración el Switch no sabe que están configurados en TEAMING, de esta forma podemos tener una tarjeta de red conectada a un switch y el resto a otro, etc… esto es lo más cómodo en este caso, puesto que el Switch no tiene gestión. De todas formas, aquí os dejo un enlace de descarga de un documento puede ser de vuestro interés sobre como configurar y administrar los TEAMING con Windows Server 2012:
Una vez que hemos seleccionado el modo del TEAMING, que el Load Balancin Mode lo hemos configurado como Hyper-V Port y que todos los adaptadores está activos, ya tenemos nuestra configuración de Hyper-V y Windows Server finalizada.
 
Lo siquiente que tenemos que hacer es configurar el Router con dos IPs privadas, en función del router que tengamos pues lo haremos de una u otra forma. Yo como os comentaba anteriormente lo estoy explicando todo con Cisco, así que aquí tenéis la configuración de la interface interna de un Cisco con dos IPs (o más) en la misma interface:
 
interface FastEhernet0
 description Red Local
 ip address 192.168.0.1 255.255.255.0

 ip address 172.26.0.1 255.255.255.240 secondary

 ip nat inside
Como véis es únicamente añadir una segunda (o más IPs) a la inteface y añadir secondary al final de la configuración. Igualmente, lo que sí queremos es que las distintas subredes están comunicadas, para esto crearemos una ACL y se aplicará a la única inteface interna que tiene el router:

 

  • access-list 120 deny ip 192.168.0.0 0.0.0.255 172.26.0.0 0.0.15
  • access-list 120 deny ip  172.26.0.0 0.0.15 192.168.0.0 0.0.0.255
  • access-list 120 permit ip 172.26.0.0 0.0.15 any
  • access-list 120 permit ip 192.168.0.0 0.0.0.255 any

La explicación de esta ACL es sencilla, cada punto que comento a continuación hace referencia a cada ACE configurada en la ACL:

  1. Deniega todas las conexiones originadas desde la subred 192.168.0.0/24 hasta la subred 172.26.0.0/28
  2. Deniega todas las conexiones originadas desde la subred 172.26.0.0/28 hasta la subred 192.168.0.0/24
  3. Permite cualquier otra comunicación origina desde la subred 192.168.0.0/24
  4. Permite cualquier otra comunicación origina desde la subred 172.26.0.0/28

Ahora una pregunta para el que quiera contestar: ¿Las dos primeras líneas son necesarias? ¿Complementarias? ¿Necearias? El que quiere responder que deje un comentario y vemos la mejor forma de hacer esto.

Ahora lo único que tenemos que hacer es asignar la ACL a la interface, para ello lo utilizamos el comando ip access-group <Número/Nombre ACL> IN:

interface FastEhernet0
 description Red Local
 ip address 192.168.0.1 255.255.255.0

 ip address 172.26.0.1 255.255.255.240 secondary
 ip access-ip access-group 120 in

 ip nat inside
De esta forma aunque sólo tengamos una interface física, podemos establecer un mínimo de seguridad. Con esta configuración, cualquier usuario interno (con privilegios para ello) podría cambiar la direcicón IP de su equipo y conectarse a otra subred sin problemas. Aquí es cuando es "útil" el tener una subred lo más limitada posible (comentario del primer artículo: estos servidores estarán en al subred 172.26.0.0/28 (sólo podréis tener HOST configurados con las siguientes IPs 172.26.0.1 – 172.26.0.14, esto siempre lo hago así para limitar la cantidad de equipos que tenemos en la subred pública, evitando así que tengamos algún equipo de "más" en dicha subred). Está claro que no es una medida de seguridad, pero siempre es bueno optimizar como securizar todo lo posible nuestra infraestructura. Si tenemos un rango adecuado para los equipos que vamos a tener en la red, es posible que no dejemos ninguna IP libre para que alguien pueda conectarse a ella. Pensad, que en esta topología no hay separación física (más interfaces de red en el router) ni lógica (VLAN), por lo que la segregación de la red es simplemente porque tenemos subredes diferentes configuradas en la red.

Comentaros que si en vez de ser un router Cisco es otro cualquier más sencillo, la configuración de la ACL no la tendréis disponible, así que … podréis configurar una regla de Firewall vía GPO para los equipos del dominio y que denigue la conexión con la subred 172.26.0.0/28 (OJO, esto puede responder a mi pregunta sobre las ACL).

Pues con todo esto configurado, únicamente debéis instalar vuestras MV y asignar las tarjetas de red virtuales del único vSwitch configurado, recordad que no hay VLAN, simplemente tendréis que configurar las direcciones IP correspondientes. En los equipos de la DMZ debéis añadir dos tarjetas de red y configurar cada tarjeta con una IP de cada subred a la que pertenezcan, nada más.

Como en los anteriores artículos vamos a ver los beneficios positivos y negativos en esta topología, vamos a ver las positivas:

  • Fácil configuración
  • Coste muy reducido a nivel de inversión de hardware

Y aquí os expongo las negativas:

  • Penalización importante a nivel de seguridad sino tenemos un router con una mínima gestión entre las dos subredes IP
  • Únicamente tenemos seguridad lógica, es muy poco para lo que buscamos

Desde luego no es el escenario más idóneo, pero bueno, por lo menos tenemos dos subredes seperadas y con unos mínimos de seguridad, al final los €/$ tienen su impacto. Pero desde luego cosas siempre se pueden hacer, asi que …

"Nunca dejéis de "complicaros la vida" por no querer darle algunas vueltas a la cabecita, porque con POCO SE HACE MUCHO!!!" 

Espero que os sea de utilidad!!!

En esta segunda parte del artículo Requisitos de HW y SW para una Infraestructura IT de Comunicaciones Unificadas para PYMES (Parte I de IV) vamos a ver otros escenarios a nivel de topología de una infraestructura IT para PYMES  (pulsar en las imágenes para verlas a tamaño real):

Opción 1: Router con dos Interfaces LAN y Switch con soporte de VLAN (pero no puertos en modo TRUNK o incompatibles con el Router)

Esquema_Basico_ST_2.jpg
 
Opción 2: Switch con soporte de creación de VLAN y dos routers básicos para salir a Internet y Port Forwarding (básico)
Esquema_Basico_ST_2-1.jpg 
Opción 3: 2 Switchs sin capacidad de gestión (creación de VLAN, etc…), 2 Routers básicos con 1 interface LAN (sin soporte de IPs secundarias) y  Port Forwarding (básico)
Esquema_Basico_ST_2-2.jpg
 
En este segundo artículo veremos algunas topologías muy simples, en donde lo más avanzado será crear VLANs en switchs, luego configuraremos los vSwitch en Hyper-V utilizando cada tarjeta de red del servidor a cada uno de ellos y por último configuraremos los routers que tienen dos interfaces LAN con subredes IP diferentes (utilizaremos los mismos datos del artículo anterior). Estas configuraciones resultarán muy útiles cuando se nos dén algunas de las siguientes situaciones:
  • Nuestro Switch no soporte 802.3ad (agregración de puertos)
  • Nuestro Router NO tenga dos interfaces de red
  • No estemos utilizando Windows Server 2012 y las tarjetas de red del servidor no sean exactamente iguales (o de distinto fabricante), por lo que no podamos realizar un TEAM entre las tarjetas que vamos a utilizar para Hyper-V
  • Los routers no tengan capacidades de gestión avanzadas
  • Los Switches no tengan soporte de gestión (creación de VLAN)

Todo esto es muy probable que se nos pueda dar en algunos clientes, y por ello no vamos a renegar de aplicar ciertas medidas de seguridad o tener entornos mediamente gestionados. He puesto tres esquemas que creo que representan bastante bien la realidad de muchas empresas, así que vamos a ver que podemos hacer en cada una de ellas en base a lo que tenemos a nivel de hardware de comunicaciones, porque siempre partimos que la configuración de hardware y software del servidor es el mismo que en el primer artículo (Requisitos de HW y SW para una Infraestructura IT de Comunicaciones Unificadas para PYMES (Parte I de IV)). Lo primordial en este caso siempre será aislar la red LAN de la red de publicación de servicios y en la cual hemos configurado una DMZ (cuidado con este término que es muy amplio, pero vamos a hacer algo similar en cuanto a funcionalidad). Dicho esto vemos que en el primer esquema de red (Opción 1), lo que tenemos las siguientes capacidades positivas:

  • Router con dos interfaces de red
  • Switch con soporte VLAN

Y las capacidades negativas (las que no tenemos vamos) son las siguientes (más que nada para que quede constancia de las mismas:

  • Servidor sin soporte de creación de TEAM en las tarjetas de red para Hyper-V (vamos a dejarlo así, en que no podemos hacerlo y son las únicas tarjetas de red que debemos utilizar para Hyper-V)
  • Switch sin soporte para 802.3ad, muy interesante cuando realizamos un TEAM
  • Switch sin soporte para puertos TRUNK (eso así sin más no es real, porque si tiene soporte para VLAN tiene soporte para poner puertos en modo TRUNK) o que no es compatible con la configuración de las interfaces del Router (ejem, más de lo mismo, seguimos simulando, vale?)

Pues con este escenario, veamos las configuraciones que podemos realizar y por lo menos mantener separadas ambas subredes IP y no sólo a nivel lógico. Lo primero será configurar las VLAN en los puertos del Switch, en donde vamos a conectar dos tarjetas de red del servidor, sobre las cuales luego configurarmos los vSwitch de Hyper-V. Pues bien, aquí tenemos la configuración de dos puertos del Switch cada uno con su VLAN correspondientes (VLAN 200 la LAN y VLAN 201 la DMZ):

interface GigabitEthernet0/0
 description VLAN Interface LAN del Router Cisco
 switchport access vlan 200
 switchport mode access
interface GigabitEthernet0/1
 description VLAN Interface DMZ del Router Cisco
 switchport access vlan 201
 switchport mode access


La configuración del Router es muy básica también, es simplemente configurar las direcciones IP correspondientes a la VLAN a la que se conectarán de forma físicas en el Switch

interface FastEhernet0
 description Red Local
 ip address 192.168.0.1 255.255.255.0
 ip nat inside
 
interface FastEhernet1
 description Red Local
 ip address 172.26.0.1 255.255.255.240
 ip nat inside
 

Con esta configuración en el Switch y cada interface LAN del router conectada a su puerto correspondiente, los equipos de la red local y DMZ ya tienen acceso a Internet (si el router da ese servicio, que en nuestro caso si). Pero aún nos falta algo por configurar, porque como cualquier dispositivo de Capa 3 su función es la de enrutar (interconectar dos redes IP diferentes) y ahora tenemos conexión entre ambas redes IP cosas que no queremos. Para ello en el router creamos dos listas de acceso (ACL) que aplicaremos a cada interface LAN evitando que tenga acceso a la otra interface vía L3:
 
ACL asignada a la Interface FastEhternet0 del Router
  • access-list 120 deny ip 192.168.0.0 0.0.0.255 172.26.0.0 0.0.15
  • access-list 120 permit ip 192.168.0.0 0.0.0.255 any
ACL asignada a la Interface FastEthernet1 del Router
  • access-list 121 deny ip  172.26.0.0 0.0.15 192.168.0.0 0.0.0.255
  • access-list 121 permit ip 172.26.0.0 0.0.15 any
La primera línea de cada ACL evita que la subred local de la interface se conecte con la otra interface local del router en la otra subred, y la segunda entrada de la ACL permite el acceso a los equipos de la subred IP que tiene cada interface a cualquier destino. En Cisco como en otras tecnologías las reglas se leen de forma sencuencial de arriba abajo, por lo que en cuanto una línea de configuración tenga aplicación se aplica al momento. Dicho esto, como cada ACL se aplica a la interface correspondiente, lo primero que hará será denegar el tráfico entre las subred IP internas que tiene el router configuradas y luego sólo permitirá el tráfico en dichas interfaces que provegan de la subred que tienen configuradas. Aquí os muestro como se aplica la configuración de cada ACL a cada interface LAN de red del router:
 
interface FastEhernet0
 description Red Local
 ip address 192.168.0.1 255.255.255.0
 ip access-group 120 in
 ip nat inside

interface FastEhernet1
 description Red Local
 ip address 172.26.0.1 255.255.255.240

 ip access-group 121 in
 ip nat inside

 
Ahora tenemos que configurar los vSwitch en Hyper-V y asignarlo a cada interface de red del servidor, aquí debéis fijaros bien, porque no haremos configuración adicional en Hyper-V en cada MV para indicarle como se etiquetarán las tramas, puesto que ya se conectará cada interface a un puerto físico del Switch en donde tiene asignada ya la VLAN correspondiente. De esta formas, tendremos dos vSwitch, cada uno asignado a una tarjeta de red del servidor y cada una de ellas a interface del Switch que hemos configurado con la VLAN correspondientes. Ahora únicamente nos quedaría asignar cada vSwitch a cada MV y realizar las configuraciones necesarias en cada MV, que básicamente es la configuración de la dirección IP de cada interface de red (en el caso de los servidores de la DMZ tendrán una interface de red en la DMZ (con default Gateway configurado de su misma subred (172.26.0.0/28)) y otra interface de la red LAN (sin default gateway configurado, porque para llegar a los equipos de la red local ya tiene esa interface red en la misma subred IP de la red de destino).
 
Pues con esto ya tenemos un ambiente LAN y DMZ separado y no conectable directamente entre sí por el router, sino qu elo harán através de las interfaces LAN de los servidores de la DMZ. Estos servidores son los que están expuestos direcamente a internet (a través de la publicación de puertos necesarios para los distintos servicios a publicar), y a través de los cuales nos conectaremos desde Internet a los servicios internos, pero de forma "más segura".
 
Ahora vamos con un escenario (Opción 2) más simple todavía, en donde no tenemos un router con dos interfaces pero si tenemos dos routers de los ISPs que encima su configuración es muy básica (NAT, PortForwarding y poco más), no tienen ni para configurar dos IPs privadas … pero bueno, siempre podemos arreglar. Además, en este escenario he visto la posibilidad de tener dos conexiones a Internet de dos ISP diferentes, por lo que cada uno nos entrega un router (a cada cual más cutre) para su conexión, y eso nos viene bien. Con esto vamos a ver las capacidades positivas:
  • Líneas de INTERNET diferentes nos permite tener servicios publicados o acccesos en diferentes proveedores
  • Sin llegar a poder configurar QoS, por lo menos tenemos líneas dedicadas, una para Internet y otra para Publicar los servicios sitados en la DMZ
Y las capacidades negativas (las que no tenemos vamos) son las siguientes (más que nada para que quede constancia de las mismas:

 

  • Servidor sin soporte de creación de TEAM en las tarjetas de red para Hyper-V (vamos a dejarlo así, en que no podemos hacerlo y son las únicas tarjetas de red que debemos utilizar para Hyper-V)
  • Switch sin soporte para 802.3ad, muy interesante cuando realizamos un TEAM
  • Switch sin soporte de L3 (ahora muchos tienen soporte L3 sin grandes costos, por lo menos enrutamiento estático)

Pues bien, con esto es muy sencillo lograr aislar la red LAN de la DMZ y nivel lógico y físico. Lo primero será configurar las VLAN en los puertos del Switch, en donde vamos a conectar dos tarjetas de red del servidor, sobre las cuales luego configurarmos los vSwitch de Hyper-V. Pues bien, aquí tenemos la configuración de dos puertos del Switch cada uno con su VLAN correspondientes (VLAN 200 la LAN y VLAN 201 la DMZ):

interface GigabitEthernet0/0
 description VLAN Interface LAN del Router Cisco
 switchport access vlan 200
 switchport mode access

 
interface GigabitEthernet0/1
 description VLAN Interface DMZ del Router Cisco
 switchport access vlan 201
 switchport mode access

A nivel de router sólo tenemos que configurar su dirección IP Privada y conectarlo a cada puerto del Switch, con esto los equipos de cada VLAN ya tienen acceso a Internet. Como no se "ven" a nivel L3 (porque son routers diferentes y están en VLAN y Subredes IP diferentes), ya no tenemos que preocuparnos de configurar ninguna ACL para filtrar el tráfico entre subredes IP, porque ya no tiene posibilidad de conectarse. Ahora nos quedaría la configuración de los vSwitch de Hyper-V, aquí hacemos lo mismo que en la Opción 1 y con esto hemos terminados.

Cómo veis esta configuración es muy sencilla, mantenemos los mismos niveles de seguridad y ganamos en que tendremos líneas de Internet separadas, que aunque no podamos balancearlas (con lo que tenemos y con esta configuración, pero si la modificamos minimamente si podríamos hacerlo), por lo menos tenemos líneas con niveles de ocupación diferentes y si tenemos Lync/SkypefB con VoIP pues nos vendrá muy bien tener una línea que sin grandes alardes, por lo menos podremos disponer de un ancho de banda mínimo para poder realizar un número de llamadas (esto irá en base al ancho de banda de la linea de Internet) con calidad sin mucha complejidad. Pensad que sin un router con capidad de QoS (bueno, bueno esto es otro tema para otro día porque dará para mucho), pues mira, por lo menos podemos dejar a los usuarios y servidores por una línea de datos y los servicios de Voz y Publicaciones por otra.

Ahora vamos por la última configuración de hoy (Opción 3),  está será la topología más humilde de todas, pero aún así podemos hacer cosillas. Trataremos de hacer y tener el mismo escenario que en la Opción 2, pero con switchs sin gestión (creación de VLAN, etc..). Dicho esto veamos las siguientes capacidades positivas:

  • Líneas de INTERNET diferentes nos permite tener servicios publicados o acccesos en diferentes proveedores
  • Sin llegar a poder configurar QoS, por lo menos tenemos líneas dedicadas, una para Internet y otra para Publicar los servicios sitados en la DMZ
Y las capacidades negativas (las que no tenemos vamos) son las siguientes (más que nada para que quede constancia de las mismas:
  • Servidor sin soporte de creación de TEAM en las tarjetas de red para Hyper-V (vamos a dejarlo así, en que no podemos hacerlo y son las únicas tarjetas de red que debemos utilizar para Hyper-V)
  • Switch sin gestión alguna, planos de configuración al 100%

Con esto puede parecer que podemos hacer poco o nada, pero siempre tenemos donde rascar ya veréis. Lo primero es que tengamos un Switch para todos los equipos de la red, con las interfaces que sean necesarias, y luego para la red de DMZ únicamente vamos a necesitar un Switch (de 20€) para conectar los siguientes elementos a él:

  • Interface LAN de uno de los routers
  • Interface del servidor que configuraremos en Hyper-V para los equipos de la DMZ

La configuración de los Routers es la misma que en la Opción 2, no haremos nada diferente y a nivel de Hyper-V lo mismo, una tarjeta de red hacia el Swtich de la LAN y la otra hacia el Swtich de la DMZ y … FIN (más simplem imposible).

Recordad que en estos escenarios no tenemos que configurar en las interfaces de red de las MV la VLAN a la que pertenecen, puesto que ya lo hacemos antes a nivel físico (conexiones entre dispositivos). Tenemos que seguir creando subredes IP diferentes, aunque en las opciones 2 y 3 están separadas a nivel físico, si tenemos la misma subred en ambas redes, los equipos de la DMZ tendrán un "problema" (todo es salvable, pero bueno, mejor y más clarito que esté separado) con las dos subredes iguales en diferentes interfaces de red (también salvable, pero .. hagamos las cosas con criterio)Como vemos, siempre se puede hacer algo interesante para no dejarnos llevar por la desidia o desgana por no tener hardware profesional para realizar configuraciones más complejas. Por favor, nunca dejéis de "complicaros la vida" por no querer darle algunas vueltas a la cabecita, porque a veces con POCO SE HACE MUCHO!!!

Espero que os sea de utilidad!!!

 

 

​Nueva actualización acumulativa para Lync Server 2013, aquí tenéis el enlace de descarga: Lync Server 2013 Cumulative Update KB 2809243 y su correspondiente KB Articles: KB2809243

Updates that are released for Lync Server 2013

Y aquí os dejo algunos artículos de este blog de como podéis actualizar vuestras plataformas de Lync:

Espero que os sea de utilidad!!

Vuelvo con otro artículo sobre el ROL del EDGE para Lync o Skype for Business, espero que esto termine de aclarar algunas dudas sobre este ROL (pulsar en la imagen para verla a tamaño real):

 

EDGE el gran desconocido.jpg
En este artículo trataré de explicar la necesidad de este ROL y en base a los servicios que vayamos a implementar lo necesitaremos o no. La idea es formular una serie de preguntas y contestarlas para que de cabida a muchas de vuestras preguntas sobre este rol muy sencillo y muy complejo a la vez …. dicho esto aquí van algunas de las preguntas que creo que podrían ser de utilidad para entender a nuestro querido EDGE, pero antes veamos la definición por parte de Microsoft de lo que un servidor Perimetral (EDGE):
 

El servidor perimetral permite a los usuarios comunicarse y colaborar con usuarios externos a los firewall de la organización. Entre estos usuarios externos se incluyen los usuarios de la organización que están trabajando fuera de la oficina, los usuarios de organizaciones asociadas federadas y los usuarios externos a los que se ha invitado a participar en las conferencias hospedadas en su implementación de Lync/Skype4B Server. El servidor perimetral también permite la conectividad a servicios de conectividad de mensajería instantánea públicos, incluidos Skype, Google Talk, etc..

Con esta definición creo que tenemos más que claro en líneas generales de que es un servidor perimetral o EDGE, no? Pues ahora vamos a ver que cosas necesitamos saber del EDGE:

1. Para que necesitamos un servidor EDGE

  • Para conectarnos remotamente a Lync/Skype4B sin necesidad de VPN (Usuarios Remotos)
    • Presencia/Mensajería
    • Acceso a Conferencias Web
    • Acceso a sesiones de AV
    • Transferencia de Ficheros
    • Compartir pantalla y presentaciones (PowerPoint)
  • Para federarnos con otras compañias con Lync/Skype4B, Skype4B Online

2. ¿Cómo podemos implementar un servidor de EDGE?

3. ¿Son necesarias 3 IP Públicas para implementar un EDGE?

4. ¿Necesitamos de forma obligatoria tener instalados certificados Públicos?

5. ¿Si tenemos subredes locales tenemos que realizar alguna configuración especial en nuestro EDGE?

6. ¿Qué resolución DNS debe tener nuestro EDGE?

  • Interface Externa: Debe tener servidores DNS externos (Google por ejemplo: 8.8.8.8), puesto que debe poder resolver los nombres de los servidores EDGE a los que quiera/necesite conectarse para completar las federaciones, además de poder resolver los nombres de los servicios web en donde tenga que verificar si el certificado está o no revocado, vamos, la ubicación de las CRL.
  • Interface Interna: NO debe llevar DNS alguno y menos los internos (en el EDGE no debe tener NUNCA en ningún interface los DNS internos), debemos modificar el fichero HOSTS del servidor para que pueda rsolver los siguientes nombres (como mínimo):
    • Pool de los Front-END
    • FQDN de cada servidor que esté en el Pool
    • FQDN de cada SBS

 7. ¿Qué son las federaciones?

8. ¿Qué registros DNS necesitamos para configurar el EDGE?

  • Los registros DNS son importantísimos, para que nos permitan tanto conectarnos al servidor EDGE desde Internet, la red local y las federaciones:
    • Iniciar sesión en Lync/Skype4B desde Internet:
      • SRV: _sip._tls.dominio.com –> HOST = FQDN con la IP del servicio de acceso
      • A: FQDN con la IP del servicio de acceso configurado en el EDGE
    • Para que los usuarios internos se puedan comunicar con usuarios externos (remotos y federados): necesitamos tener un registro DNS de tipo A con el FDQN publicado en la topología y como IP la de la interface interna del EDGE.
    • Federaciones con Skype (de consumo) y Skype4B On-Line: (obligatorio si queremos federarnos con Skpe4B Online y Skype de consumo)
      • SRV: _sipfederationtls._tcp.dominio –> HOST =  FQDN con la IP del servicio de acceso
      • A: FQDN con la IP del servicio de acceso configurado en el EDGE
  • ¿Qué registros DNS debemos configurar para utilizar nuestro dominio SIP en Lync On-Line?

  • ¿Qué registros DNS necesitamos para la configuración automática del cliente Lync 2010 y 2013?

 9. ¿Si tenemos un entorno híbrido con Exchange y Skype4B Online necesitamos un EDGE?

  • SI, porque el enlace entre Office 365 y Skype4B On-Premises es el EDGE (el próximo artículo que tengo pendiente subir es la integración de los servicio de UM de Exchange OnLine con Skype4B On-Premises, ahí os mostraré la integración del EDGE con esta configuración)

10. ¿Qué puertos necesitamos abrir en nuestro dispositivos de seguridad para publicar los servicios del EDGE?

  • Os dejo una captura de los puertos que necesitaréis configurar para hacer funcionar todos vuestros servicios en el EDGE (pulsar en la imagen para verla a tamaño real):

11. ¿Necesita el EDGE tener Internet?

  • SI, puesto que necesita tener acceso a:
    • Resolver nombres de dominio para encontrar a otros EDGE (federaciones)
      • TIpo de registros DNS necesita resolver
        • A
        • SRV
    • Acceso a HTTP para conectarse a los servicios web en donde se publican las CRL de los certificados emitidos por otros servidores EDGE, los cuales se tienen que verificar si los certificados son válidos o no
  • Si queremos podemos filtrar a que sitios se puede conectar el servidor de EDGE:

Esto creo que es lo básico que debemos conocer para saber si necesitamos o no un servidor de EDGE, hay muchas más preguntas y respuesta sobre el rol del EDGE, pero creo que ya van dirigidos a otros escenarios.

Si alguien tiene más consultas sobre el EDGE, por favor, subir un comentario y asi vamos completando este artículo con más preguntas y respuestas para que todos saquemos provecho de ello.

Espero que os sea de utilidad!!!