Microsoft Lync Server
Header

Este es el último artículo de esta serie de 4 (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), Requisitos de HW y SW para una Infraestructura IT de Comunicaciones Unificadas para PYMES (Parte III de IV)), en donde he comentado los escenarios más comunes en PYMES (y no tan PYMES)) para tener una solución de Microsoft  en sus Sistemas de Información. Lo he centrado a nivel de Hardware (Plataforma de Virtualización y Comunicaciones) y Software (Windows Server, Exchange, SkypefB, Monitorización, Backup), para que tengáis una referencia (más) de los requisitos necesarios para implementar una solución de negocio interesante, "jugando" con las características técnicas de cada elemento y adaptándonos lo máximo posible a lo que ya tiene el cliente y con inversión "mínima". Este será el último (hay muchísimo mas, pero tampoco puedo representarlos todos) escenario  (pulsar en la imagen para verla a tamaño real):

Esquema_Basico_ST_Parte_IV.jpg 
En este cuarto artículo vamos a trabajar sobre esta topología (pulsar en la imagen para verla a tamaño real):
Esquema_Basico_ST_3.jpg
En este último escenario, vamos a tener una mezcla de todo a nivel de hardware de comuniaciones, buscando siempre el mismo objetivo que en los artículos anteriores. En caso tendremos un router con una sóla interface de red (con lo cual sólo tenemos físicamente un cable conectado al router para la interface interna), pero con soporte de creación subinterfaces y  un Switch con una gestión básica para crear VLAN y tener puertos en modo TRUNK. Lo que haremos será configurado lo que en Cisco se conoce como Inter VLAN Routing, que básicamente consiste en transportar tráfico de VLAN diferentes através de una sóla interface física del dispositivo de Capa 3. Esta configuración nos permitirá configurar el Switch con distintas VLAN y el Router utilizarlo con enrutador entre las diferentes VLAN pero con una única interface, aquí tenéis a nivel gráfico el escenario que os comento (pulsar en la imagen para verla a tamaño real):

Esquema_Basico_ST_Parte_IV_0.jpg

En este caso tenemos un Switch (o los que sean) y un Router, para configurar un entorno segregado con VLANs, de tal forma que podamos aislar el tráfico entre los servidores las estaciones de trabajo, pero … queremos que los equipos de la red de usuarios puedan acceder a servicios de la red de servidores. Cómo sólo tenemos un router que tiene una conexión WAN y otra LAN, debemos hacer que con la interface LAN podamos ofrecer servicios de enrutamiento entre VLANs, para ello debemos configurar Inter VLAN Routing (Router on a Stick) pero con la particularidad de que tenemos dos subredes que deben estar asignadas a su VLAN correspondientes. Básicamente vamos a permitir enrutamiento entre VLANs conectándono a un Switch que tiene las diferentes VLANs configuradas  y para ello debemos configurar sobre una interface física varias interfaces virtuales (sub-interfaces). Esto nos permitirá conectar el Router al Switch y ofrecer enruamiento entre vlan (InterVLAN Routing). Pues dicho todo esto, veamos el escenario que tenemos para configurar:

  • 1 Router con una Interface WAN y LAN (respectivamente)
  • 1 Switch con soporte para creación de VLANs y puertos en Modo TRUNK
  • Servidor de virtualización con 4 tarjetas de red, dos de ellas serán utilizadas para las MV (DMZ y LAN respectivamente) y las otras dos en TEAMING (TEAMING en Windows Server 2012 (Actualizado 04-01-2013)) para mantener la conexión del HOST en Alta Disponible (si, es posible que eso no sea lo que necesitamos, pero os recuerdo que estamos "simulando los escenarios")

Pues con esta configuración en cuanto a recursos y utilizando la segunda imagen de este artículo (Esquema IV), vamos a empezar la configuración. Lo primero que haremos será configurar el Switch, tenemos que configurar las distintas VLAN (200 (LAN) Y 201 (DMZ)) y configuraremos el puerto en donde conectaremos el Router en modo TRUNK (es así porque debemos transportar el tráfico de las diferentes VLANs que vamos a conectar a nivel 3):

Cración de las VLAN y asignación de las interfaces a cada VLAN:

vlan 200
interface gigabitEthernet 1
switchport access vlan 200

vlan 201
interface gigabitEthernet 2
switchport access vlan 201

La explicación a estos comandos es muy sencilla, creamos la vlan (vlan 20x) y luego especificamos que VLAN estará asignada a que interface (interface gigabitEthernet X), con esto ya tenemos configuradas las VLAN en el Switch, además de que hemos asignado las VLANs a los puertos correspondientes (interface gigabitEthernet 1 y interface gigabitEthernet 2). Pues ahora lo único que nos falta en el Switch es configurar la interface en donde vamos a conectar el router en modo TRUNK, puesto que debemos transportar el tráfico de las diferentes VLAN, para ello aplicaremos la siguiente configuración en la interface gigabitEthernet 3:

interface gigabitEthernet 3
switchport mode trunk
switchport trunk allow vlan 200-201

Esta configuración creo que está clara, únicamente podemos el puerto en modo TRUNK (switchport mode trunk) pero además filtramos las VLANs  (switchport trunk allow vlan 200-201) que vamos a transportar por este enlace, limitando así tráfico de otras VLAN que tuviéramos configuradas  y que no deseamos que de casualidad alguien quier subir tráfico por ellas. En las interfaces gigabitEthernet 1 interface gigabitEthernet 2 en donde conectaremos las tarjetas de red del servidor fisico para luego establecerlas con vSwitch par las MV. La gigabitEthernet 1 para la LAN interface gigabitEthernet 2 para la DMZ.

Ahora nos toca configurar el Router, en donde tendremos que configurar distintas sub-interfaces de la interface LAN. Su configuración es muy sencilla,  creamos la sub-interface y le asignamos las direcciones IP correspondientes (como siempre esta IP será la que configuraremos como gateway en las conexiones de ambas redes (LAN y DMZ)).

interface fastEthernet 0/0.200
encapsulation dot1Q 200
ip address 192.168.0.1 255.255.255.0
interface fastEthernet 0/0.201
encapsulation dot1Q 201
ip address 172.26.0.1 255.255.255.240

 

 

 

Ahora os comento la configuración, pero es muy sencilla, tenemos que crear una sub-interface de la interface física (FastEthernet0/0), la cual se nombrará con un número, yo suelo poner el número de VLAN (aquí no obligatorio), luego debemos especificar la encapulsación la cual especificamos dot1Q y seguido el número de la VLAN (si obligatorio), porque así le decimos que VLAN tiene esta interface y "hablará" con el switch indicando que está etiquetando con VLAN XXX. Por último le tenemos que asignar una dirección IP, cada una de la subred que le corresponda (vuelvo a recordar que esta es la IP que tienen que tener los equipos de la subred (cada cual la que le corresponda) como IP de Gateway.

Pensad que el router tiene una WAN y una LAN (las sub-interfaces que hemos configurado), por lo que este route les dará acceso a Internet a cada una de las subredes (esa era la idea), pero también así tal cual está tendrán acceso ambas subredes entre sí (y en nuestro caso no lo queremos así, como en los otros artículos), por lo que tendremos que volver a configurar  las ACL que eviten las conexiones directas entre las diferentes subredes:

ACL asignada a la Interface FastEthernet0/0.200
  • 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 FastEthernet0/0.201
  • 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/0.200
 description Red Local
 ip address 192.168.0.1 255.255.255.0
 ip access-group 120 in
 ip nat inside

interface FastEhernet0/0.200
 description Red Local
 ip address 172.26.0.1 255.255.255.240

 ip access-group 121 in
 ip nat inside
 

Pues con todo esto ya hemos finalizado la configuración de comunicaciones, ahora nos quedaría sería configurar los vSwitch para Hyper-V y conectar cada tarjeta de red del servidor al Switch, esto lo haremos de la siguiente forma:

Esquema_Basico_ST_Parte_IV_1.jpg 

Luego asignamos cada vSwitch a cada MV para que se configure su interface de red y configuramos las direcciones IP correspondientes a cada subred, y como puerta de enlace predeterminada tendremos que poner la IP asignada a cada sub-interface del router (en función de la subred en la que nos encontremos será la 192.168.0.1 o 172.26.0.1). 

Y como en toda red que se precie no puede faltar una red Wi-FI, pues con parte de este artículo y estos dos, tendréis una red Wi-FI profesional y por el mismo coste de infraestructura que estamos comentando:

Asignacion_VLAN_Esquema_1.jpg 

Windows Server 2012: DirectAccess (Actualizado 15-02-2013)Direct_Access_1_Esquema.jpg

Cómo asignar rutas estáticas desde un servidor DHCP (Opción 121) y DHCP Windows Server 2012: Directivas
Rutas_Estáticas_DHCP.png

En todo caso, si vuestra red sólo tenéis acceso vía cable, también podéis aplicar muchas medidas de seguridad y aquí tenéis una de las que más me gustan: NPS: Autenticación 802.1X Red Cableada

Espero que estos 4 artículos os sirvan por lo menos para tener una visión más amplia de lo que podéis implementar en vuestra empresa, aunque a veces no tengáis el hardware adecuado porque ..

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

Update for Skype for Business 2016 (KB3114516) 64-Bit …

Microsoft has released an update for Skype for Business 2016 64-Bit Edition. This update provides the latest fixes to Skype for Business 2016 64-Bit …
FREE
Date:1/5/2016
 
Microsoft has released an update for Skype for Business 2016 32-Bit Edition. This update provides the latest fixes to Skype for Business 2016 32-Bit …
Microsoft has released an update for Skype for Business 2015 32-Bit Edition. This update provides the latest fixes to Skype for Business 2015 32-Bit …

 

Microsoft has released an update for Skype for Business 2015 64-Bit Edition. This update provides the latest fixes to Skype for Business 2015 64-Bit …

 

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!!!

 

 

Es posible que en alguna ocasión tengamos la necesidad de mostrar un DID en base a la ubicación geográfica del destino de la llamada, porque tenemos varias sedes dispersas geográficamente pero queremos mostrar uno de nuestros DID asociados a nuestro troncal SIP en base al destino al cual llamamos (pulsar en la imagen para verla a tamaño real)

Mostrar DID Llamadas Salientes.jpg 
El poder tener en un CPD u oficina central nuestro sistema de telefonía (Cisco, Lync/Skype, Avaya, etc..) y que el resto de sedes lo utilicen de forma transparente, forma parte de los numerosisísimo beneficios de tener VoIP implementadas en las empresas. Imaginemos una empresa, no muy grande, con 3 sedes en el territorio nacional o no, en este caso tres oficinas distintas en España: GALICIA, MADRID y BARCELONA. Contamos con Lync/SkypefB como sistema de Comunicaciones Unificadas y además hemos portado todas nuestras líneas de Voz tradicional (PRI, BRI, ANALOGICOS,) a VoIP, por lo que todos nuestros DID los tienes nuestro ITSP. Seguramente lo que queremos es que los usuarios que estén en la oficina de GALICIA muestren su DID ((981) XXXXXX, (982) XXXXXX, (988) XXXXXX, (986) XXXXXX), los de MADRID el suyo ((91) XXXXXXX) y los de BARCELONA el suyo ((93) XXXXXXX), de tal forma que la persona que recibe la llamada tenga claro de que provincia recibe la llamada. Esto es muy sencillo, simplemente debemos configurar nuestro troncal SIP con nuestro ISTP y el cursará la llamada con alguno de nuestros DID. Como bien sabéis, con un mismo troncal SIP podemos tener varios DID "asociados", por lo que tenemos que ver la forma de que el ISTP tenga constancia de alguna forma de que queremos mostrar un determinado DID en base a la oficina la cual ha cursado dicha llamada. Hasta ahí todo normal y más o menos sencillo, pero que ocurre con las llamadas que queremos hacer y que se muestre el DID de otra oficina? Es muy probable que empresas que se encuentran en el mismo país  tengan el departamento de soporte o administración centralizados en una única oficina, y el personal de dicha oficina quiera realizar llamadas a clientes de otras localidades en donde la empresa tiene presencia en cuanto a ubicación física y quiera mostrar el DID de dicha ubicación. Ya sea por una u otra razón, es probable que necesitemos mostrar algunos de los DID que tenemos asociados a nuestra empresa en algún momento, de tal forma que el usuario que recibe la llamada pueda ver el DID que queramos en situaciones determinadas. Si bien es cierto, que lo normal es que por defecto los usuarios de una organización muestren el mismo DID, el cual siempre suele ir asociado  la ubicación física de la oficina, de tal forma que podamos asociar que una empresa de GALICIA tenga los siguientes prefijos:
 
A  Coruña: (981) XXXXXX
Lugo:  (982) XXXXXX
Orense: (988) XXXXXX
Pontevedra (986) XXXXXX)
 
Por lo que si recibimos una llamada con alguno de estos prefijos, ya sabemos de que localidad nos están llamando. Por temas legales (no voy a entrar en ello) es más de lo mismo, como por ejemplo que no podemos mostrar como DID un 902 que hayamos contratado, aunque técnicamente sea viable, estaríamos incumpliendo la ley. Hace algunos años, los ITSP lo permitían, pero ahora mismo aunque quisierais no podéis realizar una llamada mostrando el 902 de vuestra empresa y el ISTSP debería bloquear dicha llamada. Dicho esto, para no liarnos, lo que si es posible es que en algún caso necesitéis que estando en la oficina de GALICIA podáis llamar a un cliente de MADRID y queréis mostrarle el DID que tenéis asigando para la oficina de MADRID, pues bien, vamos a ver como podemos hacerlo y cuales son los requisitos:
  • Que vuestro ITSP os permita mostrar vuestro DID siempre que así lo requiráis
  • Debemos realizar ciertas configuraciones en nuestro Plan de Marcado, Directiva de Voz, Usos de RTC y Rutas

Como véis los requisitos son mínimos y las configruaciones serán muy sencillas, simplemente es buscar la "fórmula" adecuada para que podamos salir identificados con un DID diferente al habitual. Pues ya teniendo claros los requisitos, vamos a ver cual sería el proceso a llevar a cabo para realizar esta configuración. Si os fijáis en el esquema que he creado, simplemente son diferentes planes de Marcado, Directivas de Voz, Usos de RTC y Troncos (vaya traducción)  por los que irá pasando nuestra gestión de la llamada para luego entregarla la ITSP con el DID que queremos mostrar.

Ahora vamos a centrar el tiro, lo que queremos es que un usuario X que está en GALICIA pueda llamar a MADRID pero mostrando un DID de MADRID (910 000 000) al usuario al cual estamos llamando. Para lograr esto, tenemos que decirle de alguna forma a Lync/Skype por donde queremos enviar la llamada (ruta), para ello yo utilizaré el número 2 como identificador de que si marco un número con el 2 delante (2 91X XXX XXX) escogerá la Ruta que yo configure en mi Uso de RTC el cual está asociado a una Directiva de Voz.Esto que ahora puede parecer un poco "complejo" ya veréis que no es tal, lo único que queremos hacer es ofrecer a nuestra llamada una virtual por la que llegue al ITSP y le hayamos forzado que queremos mostrar el DID de MADRID (para este ejemplo el DID es 910 000 000).

Siempre hemos repetido que lo suyo es normalizar toda la marcación de los usuarios (Planes de Marcado – Reglas de Normalización), vamos que si un usuario marca 986 000 000 nosotros lo "normalizamos" a +34 986 000 000. Bien, pues ahora creo que debemos hacer algo similar pero en vez de normalizarlo a +34 (en mi caso) … no haré nada, de tal forma que si el usuario marca 2 y el DID de destino no se normalice. Esto lo haré así para que el usuario sea 100% consciente de que está llamando a través de una linea que mostrará al usuarios que recibe la llamada el DID de MADRID. Entiendo que penséis que no es necesario, puesto que cuando uno marca el 2 antes que el DID del usuario al que quiere llamar, se supone que es 100% consciente, pero bueno, yo lo he configurado así para que no haya confusión. Dicho esto, lo que nos queda es configurar ahora un Uso de RTC con una Ruta que sea capaz de llevar esta llamada hasta el Troncal, y en dicha ruta es donde forzaremos el DID que enviaremos al ITSP para que lo "deje pasar tal cual" y así el usuario que recibe la llamada pueda ver el DID que queremos.

Antes de iniciar el proceso de configuración en base al esquema mostrado al inicio del artículo quiero mostraros en que fase de la gestión de la llamada nos encontramos desde que el usuario está escribiendo el DID al que quiere llamar. Luego en base al Plan de Marcado que tiene asignado, se le aplicará la Regla de Marcado correspondiente:

Mostrar DID Llamadas Salientes_PM.jpg

Bien, ahora lo primero que haremos será configurar una Regla de normalización asociada al Plan de Marcado el cual tiene asignado el usuario(s), para ello simplemente editamos el Plan de Marcado y añadimos una nueva Regla de normalización. Le indicamos los dígitos iniciales de la llamada para que esta regla pueda tener aplicación, en mi caso como os había comentado he puesto el 2 y además que luego el siguiente dígito sea entre el 6 y el 9 cualquier número. Le indicamos que como mínimo debe tener 10 dígitos para que se aplique dicha regla, y por último no le vamos a indicar que no le quitaremos ningún dígito:

Mostrar_DID_Trunk_SIP_4.png
Esta Regla de normalización la voy a colocar al principio, para tenerla más visible dado que es una regla "especial" que quiero tenerla más presente. Además, es posible que tengamos extensiones internas o extensiones cortas y queremos que esta sea evaluada la primera. Pero bueno, en mi caso ya me he preocupado de indicarl que empiece por 2 y acontinuación entre 6 y 9, con un mínimo de 10 dígitos, por lo que no habrá lugar a equivocación.

Mostrar_DID_Trunk_SIP_1.png 

Hecho esto, vamos a probar que la regla funciona como esperamos, para ellos escribiremos un número de MADRID (en el caso del ejemplo) con el 2 delante para ver sino entra en conflicto con otra regla o nos hemos equivocado en su creación. Como vemos se aplica correctamente con el DID que hemos probado (2910000001) puesto que no le ha quitado ningún digito como así queríamos.

Mostrar_DID_Trunk_SIP_2.png
Nuevamente os voy a mostrar en que fase nos encontraríamos en base al esquema mostrado al inicio, simplemente para que veáis como se procesa la llamada a nivel lógico antes de poder ser enviada al ISTP. De hecho, de momento,  simplemente estamos gestionando las distintas configuraciones que normalizarán (Planes de Marcado – Reglas de Normalización) y directivas (Directiva de Voz – Usos de RTC – Rutas) que permitirán definir si podemos o no cursar la llamada y por donde la vamos a enviar (Troncal SIP). Ahora mismo vamos a definir por donde vamos a enviar la llamada la cual tiene como número de destino el 2 y el DID al que queremos llamar. Para ello tenemos que definir en la Directiva de Voz de los usuarios los distintos Usos de RTC que den cabida a las llamadas que empiecen por 2[6-9]:

Mostrar DID Llamadas Salientes_DV.jpg

Pues ahora vamos definir la configruación que necesitamos realizar para poder llamar a MADRID con el 2 delante del DID a llamar y mostrando nuestro DID de MADRID que nos ha asignado el ITSP. Yo simplemente voy a editar una Directiva de Voz que ya tengo con su Uso de RTC asociado, para añadirle una nueva Ruta:

Mostrar_DID_Trunk_SIP_5.png
Una vez que estamos dentro del Uso de RTC asociado (ES-GUA-RTC-NMI) a la Directiva de Voz, creamos una nueva Ruta de Voz en donde le indicamos que los dígitos iniciales que permitirá esta ruta es el 2, forzamos el DID a mostrar y para ello habilitamos la casilla Suprimir identificar de llamada para poder escribir el DID que queremos mostrar y por último agregamos el Troncos asociado (que será el TRUNK SIP que tenemos con nuestro ITSP (en mi caso)).

Mostrar_DID_Trunk_SIP_7.png
Una vez que hemos guardado la configuración de esta ruta, ya tenemos nuestro Uso de RTC configurado de la siguiente forma:

  • Todo lo que empieza por +34 o 00 se enviará por la Ruta ES-GUA-NMI que lo enviará a un troncal que mostrará el DID de GALICIA
  • Todo lo que empiece por 2 se enviará  la ruta ES-GUA-MAD-NMI que hemos definido y que suprimirá el DID que tenga el usuario o el ITSP por defecto por el que le hemos escrito nosotros

Tened en cuenta que para llegar aquí con el +34 o 00 o 2 hemos tenido que normalizar el número que el usuario ha marcado en el cliente Lync/Skype, para ello hemos utilizado los Planes de Marcado y Reglas de normalización que habéis visto antes:

Mostrar_DID_Trunk_SIP_6.png 

Aquí os dejo un artículo sobre la configuración de las rutas, el balanceo de carga entre varios ITSP, etc..

Llegados a este punto, ya tenemos lo que queremos, puesto que cuando un usuario en Lync/Skype esriba 2 más un DID de al menos 10 dígitos se aplicará la regla de normalización DID-MAD y, como además tiene una Directiva de Voz asociada en la cual tiene un Uso de RTC con una Ruta que es capaz de saber que si alguien marca un número que empieza por 2 sabe a que ruta llevarlo .. pues ya tenemos lo que buscamos. OJO, para ello tenemos que tener bien configurado nuestro Plan de Marcado (con sus reglas de normalización)  y Directiva de Voz (con sus Usos de RTC y Rutas),  y por último nuestro ITSP debe permitirnos forzar el DID que queremos mostrar a la persona que llamanos (que no todos lo permiten así de fácil). De esta forma y con un número Troncal SIP, podemos manejar desde Lync Server o Skype For Business 2015 que DID (DID que tengamos asociados a nuestra empresa) mostrar al usuario que recibe nuestras llamadas.

Aún no hemos finalizado la configuración, pueso que ahora nos encontramose en esta fase de la lógica de la llamada, en la "Configuración del Tronco". Aquí es donde le vamos a enviar la llamada al ITSP (o lo que tengamos conectado), me explico, mi ITSP me solicita que le envìe el DID al que queremos llamar siempre sin normalizar (es muy común), por lo que quiere únicamente sólo el DID al que llamamos. Un ejemplo sería: 2910 000 001 y le enviaremos al ITSP el 910 000 001, esto sólo aplica al DID que llamamos, no el DID que vamos a mostrar, puesto que esto se lo hemos definido en la ruta y ya no se tocará más:

Mostrar DID Llamadas Salientes_Tronco.jpg
Comentado todo eso, vayamos a ver la configuración que debemos realizar en la sección de Configuracion de Tronco. Como nosotros le hemos puesto el 2 delante, ahora se lo tenemos que quitar, porque sino el ITSP no sabrá a quien le tiene que enviar la llamada (independientemente de que en cualquier otra llamada en donde hemos normalizado el número marcado a +34XXX XXX XXX, que ya lo tenemos que hacer si o si porque el ITSP quiere que le enviemos sólo el DID la que llamamos sin el código de país), puesto que un DID con el 2 delante .. no existiría en nuestro caso. Bien, pues para ello tenemos que editar la configuración del Tronco y añadir un nueva regla de Traducción de números llamados. Es una regla muy sencillo, simplemente le indicamos que todas las llamadas que tengan como dígito de inicio el 2 se lo quite. En nuestro caso el orden no nos importa, puesto que las otras reglas simplemente quitan la normalización E.164 de los números que comienzan por +34 o 34, vamos que le quitamos el código de pais:

Mostrar_DID_Trunk_SIP_8.png
Como en el resto de configuraciones de Voz, podemos realizar un test y ver si realmente quita el 2 o no, para ello escribimos en Número de teléfonos para probar el DID de MADRID al que queremos llamar con el 2 delante y seleccionamos la opción Número llamado. Ahora vemos que lo que le vamos a enviar al ITSP es 910 000 000 sin el 2 delante:

Mostrar_DID_Trunk_SIP_9.png
Si queremos probar las otras reglas, simplemente escribimos un DID que tenga como dígitos de inicio el 34 (en mi caso porque es el código de mi país) y vemos que funciona correctamente, puesto que se le aplica la regla de traducción correcta:

Mostrar_DID_Trunk_SIP_10.png
Si queréis saber algo más de como manipular los dígitos de los números llamados y de llamada, aquí os dejo un artículo que había publicado en su momento:

Pues ahora si, ya tenemos lo que queremos y se aplicaría el 100% del esquema que he mostrado al inicio, puesto que desde que el usuario marca los dígitos del usuario al que va a llamar hasta que el usuario final la recibe y ve en su terminal el DID que queremos mostrar:

Mostrar DID Llamadas Salientes.jpg
Ahora nos queda la prueba de fuego … que lo pruebe el usuario!! Aquí os dejo lo que vería un usuario final cuando vaya introduciendo los dígitos para llamar en base a las reglas que hemos configurado:

Utilizando el 2 para llamar a MADRID desde un DID de GALICIA: el usuario no lo verá modificado en ningún momento en pantalla. Recordad que las reglas de normalización contemplaban que los dígitos iniciales sean siempre 2 y luego entre 6 y 9, de ahí que ambas llamadas no son normalizados al E.164. Porque además de llamada a números fijos de MADRID (91X XXX XXX) es posible que querramos llamar a móviles de clientes ubicados en MADRID (6-7):

Mostrar_DID_Trunk_SIP_12.pngMostrar_DID_Trunk_SIP_15.png

Llamadas a números de la misma ubicación del usuario (en base a su Plan de Marcado): cómo podemos apreciar se aplican las reglas de normalización que "modifica" lo que ve el usuario cuando marca un DID (esté en su locación o no), porque puede querer llamar a MADRID pero mostrando su DID de GALICIA:

Mostrar_DID_Trunk_SIP_16.png

Con todo esto, cuando el usuario con un Plan de Marcado configurado con la Regla de Normalización que contiene como dígito inicial el 2, una Directiva de Voz con un Uso de RTC el cual tiene una Ruta que tiene como dígitos  de inicio el 2 … se enviará la llamada al ITSP forzando el DID que queremos mostrar!!!

Espero haya quedado más o menos claro, el proceso es sencillo y totalmente variable (el 2 por otro dígito o caracter), en base a las condiciones que queráis, etc.. simplemente ya véis que aun teniendo un único TRUNK SIP podemos enviar  llamadas mostrando varios DID sin problema. Como siempre os comento, vuestro ITSP también lo tiene que soportar y permitiros a vosotros enviar el DID que queréis mostrar (siempre y cuando lo tengáis asignado a vuestra empresa).

Esta configuración también es valida para trabajar contra SBC, ETC.. al final para Lync/Skype es simplemente un troncal a donde enviar las llamadas. Como os comentaba al principio, esta configuración es muy cómoda cuando tenemos varias oficinas en distintas ubicaciones geográficas o usuarios teletrabajando en distintas ciudades, Comunidades,  Paises, etc… porque lo suyo es que si tenemos presencia en Barcelona tengamos un DID de Barcelona y si estamos en Madrid pues más de lo mismo. Pero siempre cabe la posibilidad de centralizar por ejemplo un departamento de Ventas o Soporte en Galicia y que  las llamadas se reciban por el DID de Madrid y Galicia y queramos mostrar un DID diferente en determinadas ocasiones en base al DID que vamos a llamar. Porque a estas alturas entiendo que ya tenéis claro como hacer para mostrar el DID de Galicia si llamamos a un DID de Galicia y si llamamos a un DID de Madrid si llamamos a Madrid … me refiero de forma predeterminada, sin que el usuario tenga que hacer nada .. Verdad que sabemos como hacerlo? Esto ya los le dejo a vosotros y si alguno tiene alguna duda, por favor, plantearla en los comentarios.

Espero que os sea de utilidad!!!