Microsoft Lync Server

Ajustar la MTU en Windows

abril 8th, 2013 | Posted by Santiago Buitrago in Windows Server - (0 Comments)

En alguna ocasión seguro que habéis tenido problemas con lo valores por defecto de la MTU de vuestra conexión de red.

Red	MTU (Bytes)
——————————–	—————–
Token Ring de 16 Mbps	17914
Token Ring de 4 Mbps	4464
FDDI	4352
Ethernet	1500
IEEE 802.3/802.2	1492
X.25	576

Los datagramas pueden pasar por varios tipos de redes con diferentes tamaños antes de llegar a su destino. Por ejemplo, para que un datagrama llegue sin fragmentación al destino, ha de ser menor o igual que el menor MTU de todos los elementos de red por las que pase. En el caso de TCP/UDP, el valor máximo está dado por el MSS (Maximum Segment Size), y toma su valor en función de tamaño máximo de datagrama, dado que el MTU = MSS + cabeceras IP + cabeceras TCP/UDP. En concreto, el máximo tamaño de segmento es igual al máximo tamaño de datagrama menos 40 (que es número mínimo de bytes que ocuparán las cabeceras IP y TCP/UDP en el datagrama). Estos se puede ajustar en casi todos los elementos de red de capa 3 y 4, nosotros vamos a ver como podemos ajustar nuestros valores de MTU en Windows.

Lo primero que vamos a ver el tamaño actual de la MTU que tienen nuestras interfaces de red, para ello abrimos un CMD con derechos administrativos y escribimos el siguente comando: netsh interface ipv4 show subinterfaces

Como vemos nos muestra el listado de Interfaces con varios valores y entre uno de ellos la MTU (por defecto 1500Bytes)

Para identificar el valor de MTU que debemos aplicar, podemos hacer algo muy sencillo que es lanzar un ping desde nuestra maquina a otro host de la red (preferiblemente un enrutador o dispositivo con funciones similares) con los siguientes modificadores: -f (Establecer marca No fragmentar en paquetes) y -l (Enviar tamaño del búfer). Si superamos el tamaño máximo de MTU obtendremos la siguiente respuesta:

Debemos repetir el test hasta que obtengamos el siguiente resultado (decreciendo el valor de MTU en valores de 10)

Una vez que hemos encontrado el valor de MTU que se ajuste a nuestras necesidades, debemos establecerlo en nuestras interfaces de red. Esto podemos hacerlo con el siguiente comando:

netsh interface ipv4 set subinterface "Nombre_Interface" mtu=1300 store=persistent

Si ahora ejecutamos el primer comando (netsh interface ipv4 show subinterfaces) para que nos muestre el resumen de las interfaces y sus valores, como se aprecia se han establecido en función de nuestros parámetros

También os muestro una herramienta gráfica para realizar el cambio de MTU: DRTCP021

Los síntomas de un exceso de MTU suelen ser la lentitud, pérdida de paquetes, microcortes, acceso a Internet lento e incluso sin llegar a cargar las páginas web que queremos visitar, etc… además puede tener otros comportamientos muy extraños. En algunas ocasiones he visto enlaces de VPN a través de los cuales los usuarios se conectaban a los servidores de RDS y no les mostraba la pantalla de login pero si el resto de la ventana!!!! Ante estos síntomas a veces hasta el ingeniero de redes más experimentado tiene problemas para detectarlo.

Yo suelo utilizar una herramienta más pontente para tratar de detectar problemas de MTU, y que me permite tener estadísticas de todo el recorrido de la conexión. Tiene un nombre muy acorde con el tema: MTUROUTE. Os muestro el listado completo de sus modificadores:

mturoute [-t] [-f] [-m MAX_PAYLOAD_SIZE] host

-t : Toggles 'traceroute' mode. (Default is off)
-f : Allow fragmentation. This will return the max ping size that the
target host will respond to, but not necessarily the MTU
-w : Set the number of milliseconds to wait for a response (default 3000).
-r : Set the maximum number of probe retries on timeout (default = 3).
-i : Set the interval between two echo requests
-d : Increases the debugging level. Reports ICMP status/failures
-m : Sets a maximum payload size to test. (Default is 10000)
-v : Print version info and exit
-z : Fill ICMP packets with random data
-p : Fill ICMP packets with a specified pattern
-s : Skip speed optimizations
-x : Redact IP addresses in output

Este es un ejemplo sin modificadores y veréis como hace pequeños muestreos para verificar cual es el valor más acertado en función de los resultados:

En este caso se ha ajustado No muestra que la MTU es de 1200, y está en lo cierto porque el enlace en donde lo estoy probando es una VPN IPSec Site-to-Site y las interfaces de los Firewalls están ajustadas a una MTU de 1200Bytes. Ahora vamos a ver otra comprobación de MTU pero en un red algo más "grande" con el modificador -t:

Como ves ve nos va mostrando el valor de MTU por cada enlace que atraviesa, esto nos facilita mucho la vida :-). También debemos tener en cuenta que a cada salto que vamos atravesando desde nuestro equipo al host de destino, los dipostivos intermedios pueden tener valores de MTU más pequeños que nosotros, lo que hará que nos muestre siempre el valor más pequeño aunque el host de destino tenga una MTU de 1500. Pensad que al fin y al cabo nosotros debemos pasar por esos enlaces y con este tamaño de MTU, si quisieramos forzar el atravesarlos con nuestra MTU … es cuando tendríamos el problema, puesto que empezaríamos a fragmentar de tal forma empezaríamos a sufrir los síntomas comentados. Aqui tenéis una imagen súper clara de lo comentado, nuestro equipo y el destino tienen una MTU de 1500Bytes, pero en cuanto pasa por el salto C ya nos mostrará el salto D y el destino con la MTU del C.

Como podéis ver es una herramienta estupenda, aqui os dejo el enlace de descarga: MTUROUTE

Espero que les sea de utilidad!!

MTU

Windows Server 2012: DirectAccess

marzo 26th, 2013 | Posted by Santiago Buitrago in Windows Server - (0 Comments)

Ahora más que nunca las comunicaciones juegan un papel fundamental en el mundo empresarial, desde recibir el correo en nuestros SmartPhones hasta conectarnos remotamente vía VDI a nuestro equipo personal. Las oficinas o centros de trabajo "permanentes" dejan de ser algo esencial para las empresas, ahora las oficinas son los CPD de los proveedores de servicios de Data Center, nuestras salas de reuniones son las conferencias online de Lync. De ahi que las comunicaciones juegan un papel fundamental en este modelo de negocio, y seguramente en cualquier otro en el cual tengamos usuarios itinerantes. Pero ahora nuestro principal problema es la seguridad y disponibilidad de los servicios. Además, debemos pensar en la "comodidad" de los usuarios para acceder a la información de la empresa, y que el personal de soporte pueda responder con rapidez a las peticiones de los usuarios.

Desde hace muchos años disponemos de diferentes formas de conectarnos a nuestra infraestructura de forma segura, y casi todas ellas pasan por conectarnos mediante una VPN en sus múltiples variantes (IPSec, SSH, SSL, PPTP, SSTP, etc…). Pero esto siempre ha llevado consigo ciertos inconvenientes, como son:

Configuraciones manuales en los equipos clientes
Hardware específico para los terminadores VPN
Filtro de puertos desde redes públicas: Hoteles, Redes Empresariales, Wireless Públicas, etc..
Formación a los usuarios
Soporte a los usuarios remotos

Posteriormente han ido surgiendo nuevas tecnologías o servicios que iban haciendo más sencillo este tipo de implementaciones, cumpliendo por lo menos el objetivo final que era conectarse remotamente a los servidores de la empresa. TS Gateway es uno de esos nuevos servicios que "solucionaba" o pretendía eliminar la complejidad de las conexiones VPN, además de facilitar la conexión a los usuarios sin que para ello tengamos que comprometer la seguridad de la empresa. Al final no deja de ser una conexión tunelizada hacia servidores RDS exponiendo para ello un servicio bajo el protocolo SSL. Pero en muchas ocasiones queremos que los usuarios remotos trabajen directamente desde sus estaciones de trabajo, lo cual en muchas ocasiones resulta más fácil y ágil. Además, queremos que nuestros equipos del dominio cuando estén físicamente fuera de la organización (si adoptamos el modelo de negocio basado en la nube esto ya es el "por defecto") se encuentren adecuadamente protegidos al igual que nuestros usuarios y su información. Con esta filosofía nació DirectAccess en Windows Server 2008 R2, una tecnología que sin necesidad de VPN nos mantiene conectados a nuestra organización desde antes de iniciar sesión en nuestro equipo. El problema que inicialmente tenía esta tecnología eran los requisitos a nivel de infraestructura, puesto que no todas las empresas podrían optar a esas exigencias técnicas (Requisitos de DirectAccess):

Uno o varios servidores de DirectAccess que ejecuten Windows Server 2008 R2 (con o sin UAG) con dos adaptadores de red: uno conectado directamente a Internet y otro conectado a la intranet. Los servidores de DirectAccess deben ser miembros de un dominio de AD DS.
En el servidor de DirectAccess, al menos dos direcciones IPv4 públicas consecutivas asignadas al adaptador de red que está conectado a Internet.
Equipos cliente de DirectAccess que ejecuten Windows 7 Enterprise o Ultimate. Los clientes de DirectAccess deben ser miembros de un dominio de AD DS.
Al menos un controlador de dominio y un servidor DNS que ejecute Windows Server 2008 SP2 o Windows Server 2008 R2. Cuando se usa UAG, DirectAccess se puede implementar con servidores DNS y controladores de dominio que ejecutan Windows Server 2003 cuando la funcionalidad NAT64 está habilitada.
Una infraestructura de clave pública (PKI) para emitir certificados de equipo y, opcionalmente, certificados de tarjeta inteligente para la autenticación de este tipo de tarjetas y certificados de mantenimiento para NAP.
Sin UAG, un dispositivo NAT64 opcional para proporcionar acceso a recursos de solo IPv4 para los clientes de DirectAccess. DirectAccess con UAG proporciona un dispositivo NAT64 integrado.

Estos requisitos eran más o menos asequibles por cualquier empresa, el problema era la necesidad de tener direccionamiento IPv6. Puesto que para muchas organizaciones era inviable el adaptar todos los elementos de red y servidores a esta nueva versión de IP. Está claro que antes o después las empresas cambiarán a IPv6, cuando salió DirectAccess con Windows Server 2008 R2 aún quedaba (y creo que queda) mucho camino por recorrer en este tema. Desde luego la tecnología era la adecuada y solventaba todos los problemas de antaño:

No más VPN de acceso remoto
Posibilidad de soporte remoto desde el dpto. de IT hacia los usuarios remotos
Facilidad de gestión y mantenimiento
etc..

Pero con la llegada de Windows Server 2012 todo ha vuelto a dar un giro de 180^o y los requisitos son más asequibles para la mayoría de las empresas:

No es necesario tener una infraestructura de clave pública (PKI)
Necesitamos únicamente una dirección IP pública versión 4 y convive con NAT
No tener deshabilitado IPv6 en nuestra red
Necesitamos un DC y un DNS server en Windows Server 2012

Una vez que hemos visto muy por encima los requisitos necesarios para implementar Direct Access, vamos a ver su configuración. Primero os muestro el esquema que he montado para este LAB:

Aquí os muetros los datos IP del esquema que utilizaremos en el LAB

SERVIDOR	ROL	IP 1 (LAN)	IP 2 (DMZ)
SRV-DA00	DIRECT ACCESS	192.168.250.96	172.16.0.2
SRV-DC00	ADDS, CA, DNS	192.168.250.200
SRV-CRM00	CRM	192.168.250.100
SRV-SP00	SHAREPOINT	192.168.250.101
SRV-MAIL00	EXCHANGE SERVER	192.168.250.102
ASIRPORT01	Cliente de DirectAccess	192.168.00/24
La subred 192.168.250.0/24 pertenece a la VLAN 5 y la subred 172.16.0.0/28 pertenece a la VLAN 10

El firewall tiene varias IP Públicas pero solo utilizaremos una IP v4 para el servicio del Direct Access. Está configurado NAT en el firewall y se ha configurado port forwarding en el puerto 443 hacia la interface DMZ del DA. El resto de la red es muy sencilla, tenemos dos servidores físicos, el DC (SRV-DC00) y el que tiene el hypervisor habilitado (SRV-MV00) que virtualiza las distintas máquinas virtuales (SRV-DA00, SRV-CRM00, SRV-SP00, SRV-MAIL00). Estas máquinas virtuales las utilizaremos para comprobar que podemos llegar a ellas desde el cliente conectado mediante DirectAccess. El cliente ASIRPORT01 está conectado en otra ubicación y conectado a Internet mediante una línea de ADSL de 15MB(down)/1,5MB(up), además el equipo ya está unido al dominio con anterioridad.

Vamos a empezar con la configuración de DirectAccess desde el principio, así que una vez instalado el Windows Server 2012 debemos empezar por agregar el ROL de Acceso Remoto

Nosotros solo vamos a elegir DirectAcces y VPN (RAS)

Una vez que ha finalizado la instalación, procederemos a la configuración del servicio

La configuración la podemos hacer bien por el asistente o manualmente, en este caso lo haremos mediante el asistente, y en nuestro caso solo queremos configurar DirectAccess

ahora está comprobando si la máquina cumple con los requisitos necesarios

Ahora debemos elegir la topología de servidor:

Perimetral: debemos tener dos direcciones IP Públicas contiguas (IPv4 o IPv6) si usamos Teredo. Sino utilizamos Teredo podemos utilizar una sola IP v4 o v6

Detrás de un dispositivo perimetral (con dos adaptadores): cada adaptador debe tener una IP v4 o v6, la interface LAN debe ser una IP privada.

Tras un dispositivo perimetral (con un solo adaptador de red): está también detrás de un dispositivo de seguridad pero con una única tarjeta de red, con una IP privada

Nosotros vamos a escoger la segunda opción y como nombre público para acceder al DirectAccess será vpn.asirsl.com, recordad que este registro DNS debemos tenerlo creado en nuestro servidor DNS externo

como vemos en la captura anterior tenemos la posibilidad de editar la configuración antes de que se aplique, esto podemos hacerlo desde la palabra que tenemos subrayada "aquí" y revisamos la configuración antes de aplicarse. Como vemos podemos especificar que equipos tendrán acceso al DirectAccess, la configuración del nombre DNS del DirectAccess, las IPs configuradas en el servidor de DA

si los datos están correctos pulsamos en Aceptar y aplicará la configuación

Una vez creada la configuración nos muestra el resultado, si existen advertencias nos mostrará cual es el problema. En nuestro caso solo nos comenta que si queremos configurar la opción de multisitio o clúster debemos revisarlo (esto lo veremos en otro artículo)

Para revisar la configuración abrimos la consola de administración de acceso remoto, desde aquí podemos editar "manualmente" la configuración

Paso 1, configuramos el tipo de implementación. Nosotros elegimos la primera opción en donde configuramos que podemos disponer de administración remota en los equipos que están conectados mediante DirectAccess

Ahora añadimos el grupo de equipos que tendrán acceso mediante DirectAccess a la organización, por defecto está el grupo Equipos del Dominio, yo he creado un grupo específico porque no quiero que todos los equipos tengan acceso de DirectAccess. Desmarcamos las siguientes opciones porque no queremos que solo los portátiles se puedan conectar ni que la navegación a Internet se haga desde el DirectAccess

En este paso debemos tener mucho cuidado y es muy importante que esté correctamente configurado. El nombre FQDN que nos muestra corresponde a una web creada por defecto para que el equipo si resuelve el nombre sabrá que se encuentra dentro de la red. Este registro DNS tipo A debéis crearlo solo en el servidor DNS INTERNO. Nosotros podemos crear otros recursos si lo consideramos oportuno. El nombre por defecto es: directaccess-WebProbehost.nombre_dominio.

Nombre del alias: directaccess-WebProbehost

Dirección IP: 192.168.250.96 (DirectAccess)

También podemos configurar una dirección de correo de soporte por si los usuarios tienen algún problema que conozcan con quien pueden contactar. Y si queremos que los clientes de DirectAccess utilicen los DNS locales del equipo debemos habilitar casilla de Permitir que los clientes DirectAccess use la resolución local de nombres. También comentar que la resolución de DirectAcces no enviará las consultas DNS a nombres de etiqueta única al servidor DNS corporativo, sino que lo hará utilizando la resolución local usando LLMNR y NetBios over TCP/IP

Paso 2, servidor de acceso remoto. Aquí configuraremos las distintas opciones del servidor de DirectAccess

Podemos elegir las interfaces del servidor para los perfiles externo o interno, además de seleccionar el certificado autofirmado que utilizaremos para autenticar las conexiones IP-HTTPS. Si queremos utilizar un certificado de nuestra CA debemos desmarcar la casilla Usar un certificado autofirmado…. y seleccionar el certificado que queremos usar desde el almacén de certificados local del equipo. Por lo que previamente debemos instalar el certificado que queremos utilizar, pero si queremos utilizar el autofirmado ya lo tenemos instalado, solo debemos seleccionarlo. Siendo un certificado autofirmado debería mostrarnos una alerta en los equipos clientes porque no será de confianza para el resto de equipos, pero esto se soluciona con la GPO que se ha creado con la configuración del DirectAccess (Configuración del cliente de DirectAccess), que agrega el certificado autofirmado como raíz de confianza para los equipos a los cuales se les aplica la directiva:

Elegimos el método de autenticación de usuario: Credenciales de Active Directory (nombre de usuario y contraseña). Sin queremos obtener compatibilidad con clientes Windows 7 debemos marcar la opción correspondiente, al igual que si queremos utilizar NAP (lo veremos en otro artículo) que es muy interesante tenerlo habilitado. Así podremos permitir la conexión a la red con DirectAccess siempre y cuando el equipo cumpla unos requisitos mínimos de "salud" (antivirus, antispyware) y seguridad (firewall, antivirus, actualizaciones automáticas)

Paso 3, nos permite configurar a que servidores tendrán acceso los clientes DirectAccess antes de conectarse a los recursos internos. Además elegimos el certificado que el servidor utilizará para autenticarse, y como podemos observar tenemos la posibilidad de utilizar certificados autofirmados (en nuestro caso es un certificado emitido por nuestra CA)

Aquí configuramos el split-dns si tenemos el mismo nombre de dominio interno y externo. Podemos definir que host queremos evitar que se resuelvan internamente, si utilizamos Lync debemos establecer las siguientes exclusiones, de tal forma que estos registros el cliente los resolverá en el DNS externo:

Ámbito	Tipo	FQDN	Servicio
Externo	SRV	_sip._tls.asirsl.com	Descubrimiento automático de los servidores de acceso de Lync
Externo	A	sip.asirsl.com	Interface Externa del EDGE de Acceso
Externo	A	webconf.asirsl.com	Interface Externa del EDGE de Conferencia
Externo	A	av.asirsl.com	Interface Externa del EDGE de AV
Externo	A	lync.asirsl.com	Servicios Web del Front-END (ABS, etc…)
Externo	A	meet.asirsl.com	URL de las reuniones online
Externo	A	dialin.asirsl.com	URL de Conferencia Telefónica

Si tenemos servidores de remediación o actualizaciones podemos especificarlos en esta pantalla del asistente

Paso 4, configuraremos a que servidores tendrán acceso los clientes DirectAccess

Podemos crear un grupo de seguridad y añadir como miembros a los servidores a los cuales los clientes DirectAccess tendrán acceso

Una vez aplicada la configuración podemos revisarla mediante la consola de DirectAccess, tenemos varias opciones que vamos a ver a continuación:

CONFIGURACIÓN, nos muestra el esquema de la configuración del DirectAccess de manera gráfica y podemos editarla en cualquier momento

PANEL, nos muestra el estado del servidor y resumen de los clientes conectados

ESTADO DE LAS OPERACIONES, estado de los servicios

ESTADO DEL CLIENTE REMOTO, muestra el resumen del los clientes conectados

GENERACIÓN DE INFORMES, nos muestras las estadísticas de conexión pero antes debemos configurarlo. Pulsamos en Configuración cuentas

yo voy a seleccionar las dos casillas y así usaremos un servidor RADIUS y los registros almacenados con WID

Ahora debemos configurar ambas opciones, primero vamos a empezar con RADIUS. En mi caso tengo un servidor NPS que utilizo para la autenticación de la red inalámbrica, autenticación de dispositivos de seguridad (Routers, AP, Switchs, etc..) para su administración. La configuración del NPS no la voy a describir en este artículo, únicamente comenta que debemos dar de alta el cliente RADIUS en el NPS que será nuestro servidor de DirectAccess (SRV-DA00). Una vez configurado con su pre-shared-key configuramos el DirectAcces

La configuración de las cuentas de la bandeja de entrada es "automática", con seleccionarlo es suficiente a excepción del tiempo que queremos almacenar los registros. Además tenemos la posibilidad de borrar los registros manualmente entre fechas o todos los registros.

Ahora podemos ejecutar un informe y ver el registro de conexiones, protocolo, duración, etc…

Ahora que tenemos el servidor preparado, solo queda probar la configuración en un cliente. El equipo que utilice DirectAccess debe ser obligatoriamente miembro del dominio (aunque podemos configurarlo offline), yo os recomiendo que primero tengáis el equipo unido al dominio y que se apliquen las directivas correspondientes. De esta forma garantizamos que se aplican correctamente todas las directivas, y posteriormente podemos conectarnos desde Internet y verificar que nos conecta vía DirectAccess. Cuando se crea la configuración del servidor se crean dos directivas de grupo que vamos ver a continuación:

Configuración del cliente de DirectAccess, configuración aplicada a los equipos que utilizarán DirectAccess y como vemos nosotros la hemos filtrado para que se aplique al grupo de seguridad ACL DA Equipos Remotos

General

Detalles

Vínculos

Ubicación	Aplicado	Estado de vínculo	Ruta
asirsl	No	Habilitado	asirsl.com

Filtrado de seguridad

La configuración en este GPO sólo se puede aplicar a los grupos, usuarios y equipos siguientes:

Nombre

ASIRSL\ACL DA Equipos Remotos

Delegación

Estos grupos y usuarios tienen los permisos especificados para este GPO

Nombre	Permisos válidos	Heredado
ASIRSL\ACL DA Equipos Remotos	Lectura (de Filtrado de seguridad)	No
ASIRSL\Administradores de organización	Editar configuración, eliminar, modificar seguridad	No
ASIRSL\Admins. del dominio	Editar configuración, eliminar, modificar seguridad	No
NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS	Lectura	No
NT AUTHORITY\SYSTEM	Editar configuración, eliminar, modificar seguridad	No
NT AUTHORITY\Usuarios autentificados	Lectura	No

Configuración del equipo (habilitada)

Directivas

Configuración de Windows

Configuración de seguridad

Directivas de clave pública/Entidades de certificación raíz de confianza

Propiedades

Directiva	Configuración
Permitir a los usuarios seleccionar nuevas entidades de certificación raíz de confianza	Habilitado
Los equipos cliente pueden confiar en los siguientes almacenes de certificados	Entidades de certificación raíz de terceros y entidades de certificación raíz de empresa
Para realizar la autenticación de usuarios y equipos basada en certificados, las CA deben cumplir los siguientes criterios	Sólo los registrados en Active Directory

Certificados

Emitido para	Emitido por	Fecha de expiración	Propósitos planteados
vpn.asirsl.com	vpn.asirsl.com	08/12/2017 10:41:13	Autenticación del servidor

Firewall de Windows con seguridad avanzada

Configuración global

Directiva	Configuración
Versión de directivas	2.20
Deshabilitar FTP con estado	No configurado
Deshabilitar PPTP con estado	No configurado
Exención de IPsec	ICMP
IPsec a través de NAT	No configurado
Codificación de clave previamente compartida	No configurado
Tiempo inactivo de SA	No configurado
Comprobación CRL fuerte	No configurado

Reglas de salida

Nombre

Descripción

Redes principales: IPHTTPS (TCP de salida)

Regla de TCP de salida que permite a la tecnología de tunelización IPHTTPS ofrecer conectividad mediante proxy y firewalls HTTP.


Habilitado	Verdadero
Programa	%SystemRoot%\system32\svchost.exe
Acción	Permitir
Seguridad	Requerir autenticación
Equipos autorizados
Protocolo	6
Puerto local	Cualquiera
Puerto remoto	Cualquiera
Configuración ICMP	Cualquiera
Ámbito local	Cualquiera
Ámbito remoto	Cualquiera
Perfil	Privado, Público
Tipo de interfaz de red	Todo
Servicio	iphlpsvc
Grupo	DirectAccess

Configuración de seguridad de conexión

Reglas

Nombre

Descripción

Directiva de DirectAccess-ClientToCorpSimplified


Habilitado	Verdadero
Modo de autenticación	Requerir entrada y salida
Extremo 1	Cualquiera
Extremo 2	fd2a:5665:1c13:1::/64, fd2a:5665:1c13:7777::/96, fd2a:5665:1c13:3333::1
Puerto de extremo 1	Cualquiera
Puerto de extremo 2	Cualquiera
Primera autenticación	{7E1D399E-1B67-4BF3-A4F8-D2BC9ACB9307}
Segunda autenticación	{906355D1-60D4-4A72-9669-F65343A94F52}
Protección de datos	{4BFB5930-44FF-4ABF-BE75-E30AA8DD688D}
Protocolo	Cualquiera
Perfil	Privado, Público
Extremo de túnel 1	Cualquiera
Extremo de túnel 2	Cualquiera
Tipo de interfaz de red	Cualquiera

Directiva de DirectAccess-ClientToNlaExempt


Habilitado	Verdadero
Modo de autenticación	No autenticar
Extremo 1	fd2a:5665:1c13:1::/64
Extremo 2	fd2a:5665:1c13:7777::c0a8:fa60, fd2a:5665:1c13:1:0:5efe:192.168.250.96
Puerto de extremo 1	Cualquiera
Puerto de extremo 2	443
Protocolo	6
Perfil	Privado, Público
Extremo de túnel 1	Cualquiera
Extremo de túnel 2	Cualquiera
Tipo de interfaz de red	Cualquiera

Directiva de DirectAccess-ClientToDNS64NAT64PrefixExemption


Habilitado	Verdadero
Modo de autenticación	No autenticar
Extremo 1	Cualquiera
Extremo 2	fd2a:5665:1c13:7777::/96
Puerto de extremo 1	Cualquiera
Puerto de extremo 2	Cualquiera
Protocolo	Cualquiera
Perfil	Privado, Público
Extremo de túnel 1	Cualquiera
Extremo de túnel 2	Cualquiera
Tipo de interfaz de red	Cualquiera

Primera autenticación

Nombre

Descripción

DirectAccess: conjunto de autenticación de fase 1 {7E1D399E-1B67-4BF3-A4F8-D2BC9ACB9307}

DirectAccess: conjunto de autenticación de fase 1

Versión

2.20

Autenticación

Equipo Kerberos

Segunda autenticación

Nombre

Descripción

DirectAccess: conjunto de autenticación de fase 2 {906355D1-60D4-4A72-9669-F65343A94F52}

DirectAccess: conjunto de autenticación de fase 2

Versión

2.20

Autenticación

Usuario Kerberos

Intercambio de claves (modo principal)

Nombre

Descripción

Conjunto predeterminado

DirectAccess: conjunto criptográfico de fase 1

Versión

2.20

Vigencia de la clave en minutos

480

Vigencia de la clave en sesiones

Omitir versión	2.0
Intercambio de claves	Grupo Diffie-Hellman 2
Cifrado	AES-128
Integridad	MD5

Omitir versión	0.0
Intercambio de claves	Grupo Diffie-Hellman 2
Cifrado	AES-128
Integridad	SHA-1

Omitir versión	0.0
Intercambio de claves	Grupo Diffie-Hellman 2
Cifrado	3DES
Integridad	SHA-1

Protección de datos (modo rápido)

Nombre

Descripción

DirectAccess: conjunto criptográfico de fase 2 {4BFB5930-44FF-4ABF-BE75-E30AA8DD688D}

DirectAccess: conjunto criptográfico de fase 2

Versión

2.20

Confidencialidad directa total

Deshabilitado

Omitir versión	0.0
Protocolo	ESP
Cifrado	AES-192
Integridad ESP	SHA-1
Vigencia de la clave en minutos	60
Vigencia de la clave en kilobytes	100000

Omitir versión	0.0
Protocolo	ESP
Cifrado	AES-128
Integridad ESP	SHA-1
Vigencia de la clave en minutos	60
Vigencia de la clave en kilobytes	100000

Directiva de resolución de nombres

Configuración global

Avanzadas

Configuración global

Directiva	Valor
Dependencia de ubicación de red	No configurado
Error en consulta	Revertir siempre a Resolución de nombres de multidifusión local de vínculos (LLMNR) y NetBIOS si el nombre no existe en DNS o si no se puede establecer contacto con los servidores DNS cuando se encuentre en una red privada (seguridad moderada)
Resolución de consulta	No configurado

Configuración de regla

Espacio de nombres

.asirsl.com

Directiva	Valor
Espacio de nombres	.asirsl.com
Entidad de certificación	Vacío
Configuración	Acceso directo
DNSSEC (validación)	No configurado
DNSSEC (IPsec)	No configurado
DNSSEC (cifrado IPsec)	No configurado
Acceso directo (IPsec)	No
Acceso directo (cifrado IPsec)	Sin cifrado (sólo integridad)
Acceso directo (configuración de proxy)	No usar proxy web
Acceso directo (proxy web)	Vacío
Acceso directo (servidores DNS)	fd2a:5665:1c13:3333::1
Versión	1

vpn.asirsl.com

Directiva	Valor
Espacio de nombres	vpn.asirsl.com
Entidad de certificación	Vacío
Configuración	Acceso directo
DNSSEC (validación)	No configurado
DNSSEC (IPsec)	No configurado
DNSSEC (cifrado IPsec)	No configurado
Acceso directo (IPsec)	No
Acceso directo (cifrado IPsec)	Sin cifrado (sólo integridad)
Acceso directo (configuración de proxy)	Usar valor predeterminado
Acceso directo (proxy web)	Vacío
Acceso directo (servidores DNS)	Vacío
Versión	1

SRV-DA00.asirsl.com

Directiva	Valor
Espacio de nombres	SRV-DA00.asirsl.com
Entidad de certificación	Vacío
Configuración	Acceso directo
DNSSEC (validación)	No configurado
DNSSEC (IPsec)	No configurado
DNSSEC (cifrado IPsec)	No configurado
Acceso directo (IPsec)	No
Acceso directo (cifrado IPsec)	Sin cifrado (sólo integridad)
Acceso directo (configuración de proxy)	Usar valor predeterminado
Acceso directo (proxy web)	Vacío
Acceso directo (servidores DNS)	Vacío
Versión	1

Plantillas administrativas

Definiciones de directiva (archivos ADMX) recuperados del almacén central.

Red/Configuración de TCPIP/Tecnologías de transición IPv6

Directiva

Configuración

Comentario

Estado de IP-HTTPS

Habilitado

Escriba al dirección URL IPHTTPS:	https://vpn.asirsl.com:443/IPHTTPS
Seleccione el estado de la interfaz entre las siguientes opciones:	Estado Predeterminado

Red/Indicador de estado de conectividad de red

Directiva

Configuración

Comentario

Dirección de host de sondeo del DNS corporativo

Habilitado

Dirección de sondeo del DNS corporativo:	fd2a:5665:1c13:7777::7f00:1
Especifique la dirección DNS esperada que debe
sondear el nombre de host corporativo.
Ejemplo:
2001:4898:28:3:38a1:c31:7b3d:bf0

Directiva

Configuración

Comentario

Dirección URL de sondeo del sitio web corporativo

Habilitado

Dirección URL de sondeo del sitio web corporativo:	http://directaccess-WebProbeHost.asirsl.com
Especifique la dirección URL del sitio web corporativo que se debe
usar para sondear la conectividad corporativa.
Ejemplo:
http://ncsi.corp.microsoft.com/

Directiva

Configuración

Comentario

Dirección URL para determinar la ubicación del dominio

Habilitado

Dirección URL para determinar la ubicación del dominio corporativo:	https://SRV-DA00.asirsl.com:443/insideoutside
Especifique la dirección URL HTTPS del sitio web corporativo que se debe
usar para determinar la ubicación dentro o fuera del dominio.
Ejemplo:
https://nid.corp.microsoft.com/

Directiva

Configuración

Comentario

Lista de prefijos de sitios corporativos

Habilitado

Lista de prefijos de sitios corporativos:	fd2a:5665:1c13:1::/64,fd2a:5665:1c13:7777::/96,fd2a:5665:1c13:1000::1/128,fd2a:5665:1c13:1000::2/128
Especifique la lista de prefijos de sitios IPv6 corporativos
cuya disponibilidad se debe comprobar para detectar
la conectividad corporativa.
Sintaxis:
La lista debe estar separada por comas sin
espacios adicionales en blanco.
Ejemplo:
fe80::/9,fe81::/9

Directiva

Configuración

Comentario

Nombre de host de sondeo del DNS corporativo

Habilitado

Nombre de host de sondeo del DNS corporativo:	directaccess-corpConnectivityHost.asirsl.com
Especifique un nombre de host corporativo que se debe resolver
para sondear la conectividad corporativa.
Ejemplo:
ncsi.corp.microsoft.com

Configuración adicional del Registro

No se encontraron los nombres para mostrar de algunos valores. Puede resolver este problema actualizando los archivos .ADM que usa Administración de directivas de grupo.

Configuración	Estado
SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\KdcProxy\ProxyServers\*	<https vpn.asirsl.com />
SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\KdcProxyServer_Enabled	1
SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\NoRevocationCheck	1
SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityAssistant\DTEs\PING:fd2a:5665:1c13:1000::1	PING:fd2a:5665:1c13:1000::1
SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityAssistant\DTEs\PING:fd2a:5665:1c13:1000::2	PING:fd2a:5665:1c13:1000::2
SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityAssistant\FriendlyName	Conexión al área de trabajo
SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityAssistant\Probes\HTTP:http://directaccess-WebProbeHost.asirsl.com	HTTP:http://directaccess-WebProbeHost.asirsl.com
SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityAssistant\ShowUI	1
SOFTWARE\Policies\Microsoft\Windows\RemoteAccess\Config\GlobalVersion	{C694605C-C272-4B3E-9AA7-C47B56FEAD2C}
SOFTWARE\Policies\Microsoft\Windows\RemoteAccess\Config\SiteVersion	{5ED258D7-2FBB-4696-87ED-6DF056DA57AF}
SOFTWARE\Policies\Microsoft\Windows\RemoteAccess\Config\TimeStamp	20121208084126.980000+000
SOFTWARE\Policies\Microsoft\Windows\Tcpip\v6Transition\IPHTTPS\iphttpsinterface\InterfaceRole	0
SOFTWARE\Policies\Microsoft\Windows\Tcpip\v6Transition\IPHTTPS\iphttpsinterface\IPHTTPS_NoRevocationCheck	1
SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters\SMB1NATCompatibilityLevel	1

Si ahora en el equipo cliente revisamos las configuración avanzada del firewall y vamos a la sección Reglas de conexión de seguridad, vemos la configuración aplicada desde la GPO

si ahora vamos al apartado de Asociaciones de seguridad y vamos Modo Principal vemos la conexión completada

Configuración del cliente de DirectAccess, directiva aplicada y filtrada para los servidores de DirectAccess

General

Ubicación	Aplicado	Estado de vínculo	Ruta
asirsl	No	Habilitado	asirsl.com

Filtrado de seguridad

La configuración en este GPO sólo se puede aplicar a los grupos, usuarios y equipos siguientes:

Nombre

ASIRSL\SRV-DA00$

Delegación

Estos grupos y usuarios tienen los permisos especificados para este GPO

Nombre	Permisos válidos	Heredado
ASIRSL\Administradores de organización	Editar configuración, eliminar, modificar seguridad	No
ASIRSL\Admins. del dominio	Editar configuración, eliminar, modificar seguridad	No
ASIRSL\SRV-DA00$	Lectura (de Filtrado de seguridad)	No
NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS	Lectura	No
NT AUTHORITY\SYSTEM	Editar configuración, eliminar, modificar seguridad	No
NT AUTHORITY\Usuarios autentificados	Lectura	No

Configuración del equipo (habilitada)

Directivas

Configuración de Windows

Configuración de seguridad

Firewall de Windows con seguridad avanzada

Configuración global

Directiva	Configuración
Versión de directivas	2.20
Deshabilitar FTP con estado	No configurado
Deshabilitar PPTP con estado	No configurado
Exención de IPsec	ICMP
IPsec a través de NAT	No configurado
Codificación de clave previamente compartida	No configurado
Tiempo inactivo de SA	No configurado
Comprobación CRL fuerte	No configurado

Reglas de entrada

Nombre

Descripción

Redes principales: IPHTTPS (TCP de entrada)

Regla de TCP de entrada que permite a la tecnología de tunelización IPHTTPS ofrecer conectividad mediante proxy y firewalls HTTP.

Habilitado	Verdadero
Programa	%SystemRoot%\system32\svchost.exe
Acción	Permitir
Seguridad	Requerir autenticación
Equipos autorizados
Usuarios autorizados
Protocolo	6
Puerto local	Cualquiera
Puerto remoto	Cualquiera
Configuración ICMP	Cualquiera
Ámbito local	Cualquiera
Ámbito remoto	Cualquiera
Perfil	Privado, Público
Tipo de interfaz de red	Todo
Servicio	iphlpsvc
Permitir cruce seguro del perímetro	Falso
Grupo	DirectAccess

Servidor de nombres de dominio (UDP de entrada)

Regla de permiso de entrada para permitir el tráfico en el servidor DNS64 implementado en el servidor de acceso remoto.

Habilitado	Verdadero
Programa	%SystemRoot%\system32\svchost.exe
Acción	Permitir
Seguridad	Requerir autenticación
Equipos autorizados
Usuarios autorizados
Protocolo	17
Puerto local	53
Puerto remoto	Cualquiera
Configuración ICMP	Cualquiera
Ámbito local	fd2a:5665:1c13:3333::1
Ámbito remoto	Cualquiera
Perfil	Todo
Tipo de interfaz de red	Todo
Servicio	iphlpsvc
Permitir cruce seguro del perímetro	Falso
Grupo	DirectAccess

Servidor de nombres de dominio (TCP de entrada)

Regla de permiso de entrada para permitir el tráfico en el servidor DNS64 implementado en el servidor de acceso remoto.

Habilitado	Verdadero
Programa	%SystemRoot%\system32\svchost.exe
Acción	Permitir
Seguridad	Requerir autenticación
Equipos autorizados
Usuarios autorizados
Protocolo	6
Puerto local	53
Puerto remoto	Cualquiera
Configuración ICMP	Cualquiera
Ámbito local	fd2a:5665:1c13:3333::1
Ámbito remoto	Cualquiera
Perfil	Todo
Tipo de interfaz de red	Todo
Servicio	iphlpsvc
Permitir cruce seguro del perímetro	Falso
Grupo	DirectAccess

Configuración de seguridad de conexión

Reglas

Nombre

Descripción

Directiva de DirectAccess-DaServerToCorpSimplified

Habilitado	Verdadero
Modo de autenticación	Requerir entrada y salida
Extremo 1	fd2a:5665:1c13:1::/64, fd2a:5665:1c13:7777::/96, fd2a:5665:1c13:3333::1
Extremo 2	Cualquiera
Puerto de extremo 1	Cualquiera
Puerto de extremo 2	Cualquiera
Primera autenticación	{A95AAFD6-1B41-44F1-A919-BBD766C30B71}
Segunda autenticación	{73364DAD-C117-4EF9-A8FA-DBBB2266CDDB}
Protección de datos	{3D5760F4-C034-4F26-AF12-17B559FDEB0F}
Protocolo	Cualquiera
Perfil	Privado, Público
Extremo de túnel 1	Cualquiera
Extremo de túnel 2	Cualquiera
Tipo de interfaz de red	Cualquiera

Primera autenticación

Nombre

Descripción

DirectAccess: conjunto de autenticación de fase 1 {A95AAFD6-1B41-44F1-A919-BBD766C30B71}

DirectAccess: conjunto de autenticación de fase 1

Versión

2.20

Autenticación

Equipo Kerberos

Segunda autenticación

Nombre

Descripción

DirectAccess: conjunto de autenticación de fase 2 {73364DAD-C117-4EF9-A8FA-DBBB2266CDDB}

DirectAccess: conjunto de autenticación de fase 2

Versión

2.20

Autenticación

Usuario Kerberos

Intercambio de claves (modo principal)

Nombre

Descripción

Conjunto predeterminado

DirectAccess: conjunto criptográfico de fase 1

Versión

2.20

Vigencia de la clave en minutos

480

Vigencia de la clave en sesiones

Omitir versión	2.0
Intercambio de claves	Grupo Diffie-Hellman 2
Cifrado	AES-128
Integridad	MD5

Omitir versión	0.0
Intercambio de claves	Grupo Diffie-Hellman 2
Cifrado	AES-128
Integridad	SHA-1

Omitir versión	0.0
Intercambio de claves	Grupo Diffie-Hellman 2
Cifrado	3DES
Integridad	SHA-1

Protección de datos (modo rápido)

Nombre

Descripción

DirectAccess: conjunto criptográfico de fase 2 {3D5760F4-C034-4F26-AF12-17B559FDEB0F}

DirectAccess: conjunto criptográfico de fase 2

Versión

2.20

Confidencialidad directa total

Deshabilitado

Omitir versión	0.0
Protocolo	ESP
Cifrado	AES-192
Integridad ESP	SHA-1
Vigencia de la clave en minutos	60
Vigencia de la clave en kilobytes	100000

Omitir versión	0.0
Protocolo	ESP
Cifrado	AES-128
Integridad ESP	SHA-1
Vigencia de la clave en minutos	60
Vigencia de la clave en kilobytes	100000

Plantillas administrativas

Configuración	Estado
Software\Policies\Microsoft\Windows\RemoteAccess\Config\6To4\Enable6to4	2
Software\Policies\Microsoft\Windows\RemoteAccess\Config\Accounting\Inbox\Mode	1
Software\Policies\Microsoft\Windows\RemoteAccess\Config\Accounting\Radius\Mode	2
Software\Policies\Microsoft\Windows\RemoteAccess\Config\Accounting\Radius\srv-central1.asirsl.com\AccountingMsgs	0
Software\Policies\Microsoft\Windows\RemoteAccess\Config\Accounting\Radius\xxxxxxxx.asirsl.com\Address	xxx.asirsl.com
Software\Policies\Microsoft\Windows\RemoteAccess\Config\Accounting\Radius\srv-central1.asirsl.com\InitialScore	30
Software\Policies\Microsoft\Windows\RemoteAccess\Config\Accounting\Radius\srv-central1.asirsl.com\PortNo	1813
Software\Policies\Microsoft\Windows\RemoteAccess\Config\Accounting\Radius\srv-central1.asirsl.com\S-1-5-21-1441895848-2563715459-1397627946-6126\SharedSecret	Formato de datos desconocido
Software\Policies\Microsoft\Windows\RemoteAccess\Config\Accounting\Radius\xxxxx.asirsl.com\TimeOut	5
Software\Policies\Microsoft\Windows\RemoteAccess\Config\Authentication\Radius\Mode	1
Software\Policies\Microsoft\Windows\RemoteAccess\Config\ClientGPOs	asirsl.com\{44A9DAC0-41A1-49F6-8985-7CFB3E67A4BD}
Software\Policies\Microsoft\Windows\RemoteAccess\Config\ConnectTo	vpn.asirsl.com
Software\Policies\Microsoft\Windows\RemoteAccess\Config\CreatedGPOs	asirsl.com\{44A9DAC0-41A1-49F6-8985-7CFB3E67A4BD} asirsl.com\{D8126100-8EC6-47B2-90CF-ABDF3006F860}
Software\Policies\Microsoft\Windows\RemoteAccess\Config\DefaultDnsServers	fd2a:5665:1c13:3333::1
Software\Policies\Microsoft\Windows\RemoteAccess\Config\DefaultNRPTSuffix	asirsl.com
Software\Policies\Microsoft\Windows\RemoteAccess\Config\Dns64Nat64Prefix	fd2a:5665:1c13:7777::/96
Software\Policies\Microsoft\Windows\RemoteAccess\Config\DnsServers	fd2a:5665:1c13:3333::1
Software\Policies\Microsoft\Windows\RemoteAccess\Config\DTE1	fd2a:5665:1c13:1000::1
Software\Policies\Microsoft\Windows\RemoteAccess\Config\DTE2	fd2a:5665:1c13:1000::2
Software\Policies\Microsoft\Windows\RemoteAccess\Config\GlobalVersion	{EB60772D-266A-4B74-B0E0-A69FE68298DA}
Software\Policies\Microsoft\Windows\RemoteAccess\Config\GlobalWebProbeURL	directaccess-WebProbeHost.asirsl.com
Software\Policies\Microsoft\Windows\RemoteAccess\Config\IpHttps\InterfaceRole	1
Software\Policies\Microsoft\Windows\RemoteAccess\Config\IpHttps\State	2
Software\Policies\Microsoft\Windows\RemoteAccess\Config\Isatap\IsatapPrefix	fd2a:5665:1c13:1::/64
Software\Policies\Microsoft\Windows\RemoteAccess\Config\Isatap\IsatapState	2
Software\Policies\Microsoft\Windows\RemoteAccess\Config\MachineSIDs\S-1-5-21-1441895848-2563715459-1397627946-6126\Internalinterface	{D3FBFCF6-25AD-443A-A55B-A401A3A7DC5A}
Software\Policies\Microsoft\Windows\RemoteAccess\Config\MachineSIDs\S-1-5-21-1441895848-2563715459-1397627946-6126\Internetinterface	{B776CA73-ADEB-40C7-9EB2-EDEE06C1A690}
Software\Policies\Microsoft\Windows\RemoteAccess\Config\MachineSIDs\S-1-5-21-1441895848-2563715459-1397627946-6126\IpHttpscert	Formato de datos desconocido
Software\Policies\Microsoft\Windows\RemoteAccess\Config\MachineSIDs\S-1-5-21-1441895848-2563715459-1397627946-6126\IpHttpsCertName	vpn.asirsl.com
Software\Policies\Microsoft\Windows\RemoteAccess\Config\MachineSIDs\S-1-5-21-1441895848-2563715459-1397627946-6126\IpHttpsPrefix	fd2a:5665:1c13:1000::/64
Software\Policies\Microsoft\Windows\RemoteAccess\Config\MachineSIDs\S-1-5-21-1441895848-2563715459-1397627946-6126\Nlscert	Formato de datos desconocido
Software\Policies\Microsoft\Windows\RemoteAccess\Config\MachineSIDs\S-1-5-21-1441895848-2563715459-1397627946-6126\ServerCertForRadius	Formato de datos desconocido
Software\Policies\Microsoft\Windows\RemoteAccess\Config\ManagementServerInfo
Software\Policies\Microsoft\Windows\RemoteAccess\Config\Nls\NlsCertName	SRV-DA00.asirsl.com
Software\Policies\Microsoft\Windows\RemoteAccess\Config\Nls\NlsPort	443
Software\Policies\Microsoft\Windows\RemoteAccess\Config\PlumbDTE1	1
Software\Policies\Microsoft\Windows\RemoteAccess\Config\PlumbDTE2	1
Software\Policies\Microsoft\Windows\RemoteAccess\Config\RADeploymentMode	196617
Software\Policies\Microsoft\Windows\RemoteAccess\Config\ServerGPO	asirsl.com\{D8126100-8EC6-47B2-90CF-ABDF3006F860}
Software\Policies\Microsoft\Windows\RemoteAccess\Config\SiteVersion	{5ED258D7-2FBB-4696-87ED-6DF056DA57AF}
Software\Policies\Microsoft\Windows\RemoteAccess\Config\SiteWebProbeIPAddress	192.168.250.96
Software\Policies\Microsoft\Windows\RemoteAccess\Config\Teredo\Type	0
Software\Policies\Microsoft\Windows\RemoteAccess\Config\TimeStamp	20121208155111.916000+000
Software\Policies\Microsoft\Windows\RemoteAccess\Config\Version	1
Software\Policies\Microsoft\Windows\RemoteAccess\Config\WebProbeList	http://directaccess-WebProbeHost.asirsl.com

Una vez que las directivas se hayan aplicado a los equipos y servidores, ya podemos probarlo. Ahora veréis un equipo con Windows 8 que está fuera de la organización y cómo podemos comprobar que estamos conectado a DirectAccess. Primero iniciamos sesión en el equipo con la cuenta de usuario del dominio (debemos permitir inicios de sesión cacheadas), lógicamente debemos estar conectamos a internet para que el equipo inicie la conexión con DirectAccess, tratará de resolver el registro directaccess-WebProbehost.asirsl.com y conectarse al servicio HTTP, sino tiene éxito tratará de conectarse con DirectAccess. Podemos comprobar que se ha conectado de varias maneras, una desde las conexiones de red:

si vamos a las propiedades de la conexión veremos como ha identificado la conexión, además podemos ver los registros para tratar de solucionar cualquier problema de conexión.

También podemos ver la conexión de DirectAccess desde PowerShell, para ello abrimos una consola de PowerShell y escribimos el siguiente cmdlet: Get-DAConnectionStatus

si no estamos conectados nos mostraría la siguiente información

Tenemos otros cmdlet muy interesantes para el DirectAccess que nos permite ver la configuración, por ejemplo: Get-DAClientExperienceConfiguration

Si ahora lanzamos un ping a cualquier servidor interno al cual tenemos acceso, debería responder sin problema. Como vemos estamos lanzando un ping a una IPv6 pero que nosotros no hemos configurado, solo hemos dejado habilitar el Protocolo de Internet versión 6. Además en la configuración anterior se ha habilitado NAT64 y DNS64 para la interoperabilidad con nuestra red en la cual solo tenemos IPv4

Si ahora nos conectamos a alguna aplicación con autenticación integrada veréis que es una maravilla, podemos acceder directamente con la autenticación integrada

Además podemos acceder a cualquier recurso compartido (para el que tengamos acceso), solo notaremos que la velocidad de acceso puede no ser la más idónea (depende del tipo de conectividad claro está) pero el acceso está disponible

Como vemos es una maravilla, no tenemos que lanzar la conexión VPN y tenemos todas las funcionalidades como si estuviéramos dentro de la red local. Esto nos permite recibir cualquier cambio de GPO, actualizaciones mediante WSUS, etc…

Además como veremos podemos acceder desde la red interna al equipo conectado mediante DirectAccess, lo que hemos apuntando como un valor añadido para la gente de soporte

Si nos encontramos dentro de la red de la empresa, y resuelve el registro directaccess-WebProbehost.asirsl.com y puede contarse al servicio Web que está en esa máquina, comprenderá que estás dentro de la red y no te conectará con DirectAccess.

podemos verificarlo también desde powershell: Get-DAConnectionStatus

Como podeís apreciar en las capturas de pantalla detecta que estamos dentro de la red, bien conectados mediante VPN o directamente en la red local. Esto es lo lógico, pueseto que si nos conectamos vía VPN los DNS siempre serán los internos y podremos resolver correctamente los registros DNS de los servidores DNS internos. De tal forma que la podrá resolver directaccess-WebProbehost.asirsl.com.

También os muestro las claves de registros las cuales el equipo utiliza para verificar la conectividad desde dentro de la LAN:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator\CorporateConnectivity

El servicio Web al que tratará de conectarse el equipo no es más que la web por defecto del IIS 8

Cómo veis es unas maravilla el poder estar conectado desde fuera de la organización y tener acceso desde la misma forma como si estuviéramos dentro de la red. Desde el punto de vista del usuario no tendrá que autenticarse para cada aplicación que quiera conectarse desde Internet, no tiene que conectarse mediante VPN ni tiene que estar conectado a un servido RDS. Desde el punto de vista del personal de IT, tiene múltiples beneficios:

Sistemas actualizados (WSUS) desde la empresa
Facilidad la hora de dar soporte al usuario final
Aplicación de GPO
Control de las máquinas que se conectan mediante DirectAccess

Si dentro de la red de la empresa tenéis varias subredes debéis configurar rutas estáticas en el serivdor de DirectAccess para que pueda llegar a ellas, puesto que en la interface internet no tiene ni debe tener un gateway configurado. En la ruta estática que creéis debéis especificar la interface por la que se conectará a las otras subredes internas, el comando sería el siguiente:

ROUTE ADD IP_DESTINO MASK MÁSCARA GATEWAY IF Nº_INTERFACE -p

Para conocer el ID de vuestra interface podéis hacerlo escribiendo únicamente el comand router print

Ejemplo: route add 172.21.0.0 mask 255.255.255.0 192.168.250.1 if 25 -p

Creo que sobran los elogios a este servicio porque es una maravilla, y ahora con Windows Server 2012 se nos facilita la posibilidad de instalarlo en casi cualquier cliente por no decir en cualquier cliente.

Espero que os sea de utilidad!!!

DirectAccess

La Nube Privada: Migración de Oficina, Beneficios del CPD y la VoIP

marzo 24th, 2013 | Posted by Santiago Buitrago in Lync Server | SharePoint | Windows Server - (0 Comments)

Hace una semana he comprobado de primera mano los supuestos y reales beneficios de migrar nuestra infraestructura a un CPD. Tengo un cliente/amigo (Alfonso Lorenzo, un excelente consultor de Sistemas de Gestión de Seguridad de la información (ISO 27001), aquí os dejo la web de su empresa EQ2B CONSULTING por si tenéis la intención de implementarla en vuestra empresa, ya sabéis con quien tenéis que contactar) que tiene toda su infraestructura virtualizada con tecnología Microsoft (Windows Server 2012), que además tiene una infraestructura de telefonía entre dos aguas: Cisco y Microsoft Lync. Llevaba unas semanas dándole vueltas a un cambio de oficina, y que cosas debería tener en cuenta en base a su infraestructura a la hora de cambiar de oficina y que tenga un tiempo de parada 0 para sus empleados

Ampliar Imagen

La infraestructura con la que cuenta EQ2B es la siguiente

SERVIDOR	SO	ROL	DESCRIPCIÓN
SRV-DC00	Windows Server 2012	AD DS y CA	Controlador de dominio y servidor de PKI
SRV-DC01	Windows Server 2012	AD DS	Controlador de dominio
SRV-TMG00	Windows Server 2008 R2	Reverse-Proxy	Publicación de servicios Web y servidor de VPN con NAP
SRV-SP00	Windows Server 2008 R2	SharePoint 2010	Servidor de SharePoint 2010: Gestión Documental y Procesos
SRV-SQL00	Windows Server 2008 R2	Servidor de BBDD	Servidor de Base de Datos en SQL Server
SRV-TS00	Windows Server 2008 R2	RDS	Servidor de Escritorio Remoto
SRV-APP00	Windows Server 2008 R2	Apps y RDS Web Access	Servidor de Aplicaciones (ERP) y RDWeb para publicación del ERP en SharePoint
SRV-DA00	Windows Server 2012	Servidor DirectAccess	Servidor de DirectAccess
SRV-MV00	Windows Server 2012	Hipervisor	Servidor de Hyper-V

En la parte de comunicaciones tiene un Cisco UC540, con teléfonos 7965 y 7921 (Wireless) para los usuarios de la oficina, además tienen Lync como herramienta de Comunicaciones Unificadas conectada con el UC540 mediante un Direct SIP. La conexión de Direct SIP se ha securizado mediante IPSec, puesto que el UC540 se encuentra en la oficina y el Lync Server en el CPD. El Lync Server lo tiene contratado con ASIR (claro está, ejeje), por lo que como requisito para conectase con su Gateway (UC540) era que el tráfico debería ir cifrado entre ambos extremos. Los consultores que están fuera de la oficina, utilizan Lync para comunicarse con el personal de la empresa y para llamar a la PSTN. Pueden llamar de Lync a los teléfonos Cisco y de los teléfonos Cisco a Lync, lo que permite ahorrar costes en comunicación interna (eliminación de tarifas planas, etc..)(Direct SIP Lync 2013 –> Cisco CME 8.X (Parte I), Direct SIP Lync 2013 –> Cisco CME 8.X (Parte II)) .Además, ofrecen formación OnLine vía Lync Web APP, lo que permite dinamizar la formación de una manera eficaz, permitiendo a los asistentes participar de forma proactiva en la formación.

Todas llamadas tanto desde los teléfonos Cisco como de los usuarios de Lync cursan sus llamadas a través de VoIP, lo que nos ofrece una independencia total sobre el operador de Voz. Además, EQ2B tiene un número para el SAT con varios agentes para recibir las llamadas de los clientes, y este SAT se gestiona en Lync con los grupos de Respuesta (Lync: Grupos de Respuesta (Parte I), Lync: Grupos de Respuesta (Parte II), Lync: Grupos de Respuesta (Parte III), Lync: Grupos de Respuesta (Parte IV)) y las llamadas se envían a los agentes que tienen instalados en su equipos el cliente Lync.

Todos los equipos de la oficina se conectan mediante una red wireless, cuenta con un Cisco AP 1041 configurado con 802.1x para autenticar a los equipos del dominio mediante su correspondiente certificado de equipo (NPS: Autenticación 802.1x para nuestra red inalámbrica). El teléfono inalámbrico se conecta igualmente mediante el mismo AP y el mismo SSID pero mediante un usuario y contraseña del AD y se le asigna la VLAN de Voz correspondiente (NPS: Autenticación 802.1X y Asignación de VLAN).

Los equipos están conectados al data center mediante DirectAccess(Windows Server 2012: DirectAccess), lo que permite a los usuarios estar logueados en el dominio, facilitando la autenticación con las herramientas de negocio. Esto permite reducir las tareas de administración sobre los equipos, puesto que nos aprovechamos de las directivas de grupo para la tareas de actualización, aplicación de medidas de seguridad, etc…

El correo electrónico que utilizan es Exchange 2010, los usuarios utilizan Outlook 2013 mediante Outlook Anywhere, EAS y OWA. Además, utilizan la MU de Exchange conetado a Lync. Utilizan distintos tipos de SmartPhones, desde iPhone hasta Nokia pasando por todo el resto (de esto doy fe). Esto les permite se mucho más eficientes con la gestión de sus correos electrónicos, viendose beneficiados sus propios clientes, puesto que la inmediatez lograda es vital para su negocio. Además, en el Exchange se cuenta con un software de firmas, que permite centralizar la plantilla de correo electrónico de tal forma que cualquier usuario del dominio y con cuenta en Exchange tiene su plantilla corporativa desde el primer momento.

Todas los portátiles (movilidad absoluta) tienen Windows 8 Enterprise, algo que se ha tenido en cuenta a la de decidirse por esta versión o la PRO por la utilización de Direct Access (Windows Server 2012: DirectAccess). Claramente la opción de Direct Access garantizaba cierto control y disponibilidad deseada para mejor la productividad y reducir el coste en IT.

Todas las conexiones y servicios están en el Data Center, por lo que la ubicación física de los usuarios y oficina no se debe tener en cuenta. Lo único a lo que debemos prestar atención es a las comunicaciones, puesto que forman un papel fundamental en este modelo de infraestructura IT. Lo importante era tener un proveedor que cumplieses las siguientes premisas:

– Rapidez de instalación en la línea de datos en la Oficina, además de implementar una opción de Backup en la solución

– Relación Calidad/Precio

Los requisito no eran muy altos, puesto que la necesidad era tener una conexión de datos estable y en el menor tiempo posible. EQ2B finalmente contrató la línea de ADSL con backup de 3G con Vodafone, sin IP fija puesto que no era necesario para la comunicación vía IPSec con el CPD. EL hardware de comunicaciones que Vodafone instala en estos casos es el HUAWEI hg556a, un hardware sencillo pero con backup de USB y sencillo de configurar.

Una vez que tenemos todos los elementos de la infraestructura, lo que quedaba era diseñar el "plan" de migración hacia la nueva oficina. Como todos los servicios están en su nube privada, únicamente tenemos que conectar la oficina con el CPD mediante una conexión segura (IPSec) y todos los servicios estarán disponibles en el mismo momento. Teniendo en cuenta que DirectAccess ya ofrece la conectividad a los usuarios, puede parecer que no teníamos nada que hacer, pero debemos tener en cuenta que la autenticación de la red Wireless es mediante 802.1x se conecta la servidor NPS que está en el CPD. Además la comunicación entre el UC540 y Lync también es de forma directa y para ello necesitamos tener la VPN establecida. Como la comunicación es entre IP Privadas (rangos IP de las sedes), con que tengamos configurada la VPN tenemos todo operativo. El direccionamiento IP privado en la nueva oficina será la misma que en la oficina actual, de tal forma que no tengamos que modificar ninguno de los servicios. Ahora que tenemos claro que solo debemos configurar la VPN para poner en marcha la nueva oficina, solo debíamos preocuparnos por trasladar los muebles y poco más.

Para configurar la VPN mediante IPSec utilizaremos el Router Cisco 1841 que está en el CPD y el UC540 de la oficina remota. Debemos tener en cuenta que en la oficina remota el dispositivo que gestiona la conexión a Internet el el router del proveedor (Vodafone), por lo que debemos utilizar IPSec con NAT-Traversal, por que es posible que necesitamos abrir determinados puertos hacia el UC540.

Para permitir el funcionamiento de IPsec a través de NAT; los siguientes protocolos deben estar permitidos en el firewall:

Internet Key Exchange (IKE) – User Datagram Protocol (UDP) puerto 500
Encapsulating Security Payload (ESP) – IP protocol number 50

o, en caso de NAT-T:
IPsec NAT-T – UDP puerto 4500

Esto es así porque el router de Vodafone está configurado con NAT y por detrás tenemos el UC540 haciendo otra vez NAT para no tener que cambiar nada en la migración, y así poder mantener el direccionamiento IP interno sin tener que realizar cambio alguno.

La configuración de IPSec mediante dispositivos Cisco y solo con una IP fija en uno de los extremos es la siguiente:

Data Center

Nueva Oficina

crypto isakmp policy 10

encr aes 192

authentication pre-share

group 2

crypto isakmp key contraseña_ipsec address 0.0.0.0 0.0.0.0

crypto ipsec transform-set ipsec esp-aes 192 esp-sha-hmac

crypto dynamic-map vpneq2b 10

set transform-set ipsec

match address 180

crypto map vpnipsec 10 ipsec-isakmp dynamic vpneq2b

access-list 180 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255

access-list 180 deny ip 192.168.200.0 0.0.0.255 host 0.0.0.0

No NAT

access-list 110 deny ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255

access-list 110 permit ip any any

crypto isakmp policy 10
encr aes 192
authentication pre-share
group 2
crypto isakmp key contraseña_ipsec address IP_Pública_CPD
crypto ipsec transform-set ipsec esp-aes 192 esp-sha-hmac
crypto map vpneq2b 10 ipsec-isakmp
set peer 213.60.255.111
set transform-set ipsec
match address 180

access-list 180 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255
access-list 180 deny ip 192.168.100.0 0.0.0.255 0.0.0.0 0.0.0.0

No NAT

access-list 110 deny ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255

access-list 110 permit ip any any

Por último se deben aplicar los crypto-map a las intr

Esta configuración es la ideal para ser totalmente independiente del proveedor, del router del proveedor, etc.. además que evitar un gasto innecesario en la IP fija de la oficina, puesto que no es necesaria. Además, como el proveedor ya nos ofrece el failover automático en 3G, la conexión de IPSec se negociará automáticamente en cuanto vuelva a tener internet para llegar el otro extremo de VPN (CPD).

Ahora que ya conocéis el escenario, que creéis que debemos hacer para que en la nueva oficina el sistema esté funcionando con el menor tiempo de para posible? Pues si, solo hacerlo en un fin de semana y estas son las tareas que hemos tenido que completar en la nueva oficina:

– Conectar todos los elementos de Red

Router Vodafone
UC540
AP 1041
Teléfonos

– Configurar IPSec (copiar y pegar la configuración anterior)

En cuanto a la parte de Voz, como tenemos VoIP para nuestras comunicaciones de voz, no tenemos que migrar líneas de teléfono ni nada parecido. Las llamadas de la PSTN nuestro ITSP nos las envía al servidor de Lync y de ahí a los teléfonos de Cisco los números de la oficina y los del SAT al grupo de respuesta de Lync. De nuevo como las comunicaciones entre el Lync y Cisco son "directas", con tener establecida la VPN ya sería suficiente, y para los agentes del SAT con que hayan iniciado sesión sería suficiente.

Como vemos lo que en teoría en otro escenario se puede volver complejo, con decenas de tareas, coordinación de varias personas, etc.. ahora únicamente debemos mover los muebles, tener internet en la oficina y que los usuarios se vayan sentando en sus sitios!!! Sin olvidarnos que los clientes que se conectan a los servicios de la compañía han estado operativos el 100% del tiempo, por lo que los clientes no se han enterado del cambio de oficina hasta que se le ha enviado vía e-mail los nuevos datos postales.

Espero que os haya resultado ilustrativo, a mi me ha resultado muy gratificante poder ayudar a un amigo en este proceso de ampliación y expansión de forma tan sencilla. Si bien es cierto, que para llegar a esto hemos tenido mucho que trabajar, que darle forma, horas y horas para tener este resultado, pero al final ha merecido la pena. Porque aun no os he contado lo más interesante, tiempo invertido en la puesta en marcha de la infraestructura IT: 2 horas y 35 min!!!! Esto hace 2 años para EQ2B o cualquier otra empresa de tamaño medio sería imposible, ahora es una realidad para todos

Espero que muchas más empresas empiecen a ver los beneficios de la nube privada, de las comunicaciones empresariales y la telefonía IP. Seguramente me hayan quedado algunos detalles atrás, pero bueno la idea general espero que os sea de ayuda para vuestros proyectos presentes o futuros.

"EL PRESENTE ES LA CLOUD Y LAS COMUNICACIONES UNIFICADAS"

Ajustar la MTU en Windows

Windows Server 2012: DirectAccess

La Nube Privada: Migración de Oficina, Beneficios del CPD y la VoIP

Santiago Buitrago

Entradas recientes

Comentarios recientes

Archivos

Categorías

Únete y comparte tu conocimiento

Sígueme en Twitter