Seguramente a muchos de vosotros os suena esta situación, un cliente (o vosotros mismos en vuestros LABS) que únicamente tiene una IP Pública contratada o que simplemente tiene un hardware no profesional que no permite la configuración de un pool de direcciones IP en su interface WAN y nos encontramos que Lync utiliza el puerto 443 para varios servicios (Edge: Acceso, A/V, Conferencias Web). Aquí os muestro un esquema de cualquier empresa pequeña o mediana (sin comentarios, pero las hay ..) con una infraestructura similar a esta (pulsar en la imagen para verla a tamaño real):
Como podéis apreciar, tiene un router/firewall con una única dirección IP Pública (222.222.222.1) por lo que en este caso solo podemos publicar (Port Forwarding) el puerto 443 hacia una IP Interna y ahí el dilema si Lync necesita mínimo 4 publicaciones al puerto 443:
- Edge
- Acceso
- AV
- WebConf
- Front-END
- Servicios Web
- Móviles
- ABS
Además, no debemos olvidar que si tenemos Exchange (EWS: UM, UCS, etc … que sería lo suyo) y un servidor WAC debemos disponer de otra IP Pública más (o un reverse-proxy publicando todos los servicios Web necesarios: Lync Front-END, WAC y Exchange (EWS)). Llegado a este punto, muchos clientes o técnicos se preguntan entonces como solventar este problema que en sí tiene fácil solución si le damos unas vueltas a la arquitectura base. Si queremos publicar todos los servicios mediante una única IP Pública, debemos contar con los siguientes requisitos (Obligatio en Rojo, Opcional en Azul):
- Reverse-Proxy: TMG, IIS ARR, F5, KEMP, etc..
- Router / Firewall: con la posibilidad de configurar dos subredes en su interface LAN (si tiene más de una interface física mejor que mejor)
Como veis los requisitos son muy humildes, a día de hoy cualquier empresa puedes cumplirlos sin mayor problema. Ahora bien, veamos el porqué de estos requisitos:
Reverse-Proxy: Debemos poder publicar con una única redirección de puerto en el Firewall/Router (TCP 443) los distintos servicios web, y como solo podemos redireccionar el puerto 443 un única vez (publicaremos 3 servidores: Exchange, WAC y Front-END), tenemos que enviar las peticiones a algún dispositivo/servidor con capacidad para leer los encabezados de host de las peticiones y que las reenvíe a los servidores adecuados. Aquí os dejos un artículo sobre la necesidad de un reverse-proxy: Lync Server: Reverse-Proxy requisito indispensable
Router / Firewall: El requisitos no es tener el dispositivo (que esto lo damos por sentado), sino que pueda gestionar dos subredes IP internas. Siempre es recomendable separar lo máximo posible las subredes, simulando en la mayoría de los casos una DMZ. Pensad que para el EDGE necesitamos declarar dos subredes diferentes, una para la interface Interna y la otra para las subred externa (aunque sean subredes de ámbito privado, puesto que estarán dentrás de un dispositivo que está haciendo NAT y PAT). Y para el reverse-proxy aunque no es obligatorio tener dos IP (en este caso), siempre es igual de recomendable tener dos interfaces disponibles (WAN y LAN).
Teniendo esto más o menos claro, que más requisitos debemos cumplir para publicar los distintos servicios, pues como no los certificados digitales:
- EDGE: Como solo tendremos una IP Pública, utilizaremos un único nombre para todos los servicios por lo que necesitaremos un certificado con un único nombre
- Reverse-Proxy: Siempre recomiendo un certificado wildcard (Certificados SAN o Wildcard para nuestra implementación de Lync Server) y este caso no será la excepción si queremos publicar todos los servicios:
- Lync: lyncdiscover.asirlab.com, lync.asirlab.com, meet.asirlab.com, dialin.asirlab.com (4 nombres)
- WAC: office.asirlab.com (1 nombre)
- Exchange: mail.asirlab.com (1 nombre)
En total serían 6 nombres, por lo que económicamente es viable que solicitéis un certificado Wildcard. Además, como siempre, es posible que queráis publicar algún servicio más (SharePoint, etc…) y ya no tendríais que cambiar el certificado por otro ni realizar otro gasto a mayores, etc.. simplemente configuráis el reverse-proxy con el mismo certificado y listo.
Inicialmente esto es todo lo que necesitamos para empezar la configuración, asi que ahora vamos a ello. No voy a explicar nuevamente como configurar el EDGE, simplemente me centrarén la configuración que vamos a necesitar para publicar el EDGE con una sola IP en la interface externa (estamos detrás de un dispositivo haciendo NAT/PAT) y con el mismo nombre para todos los servicios: Acceso, A/V y Conferencias Web. Lo primero es que vayamos al Generador de Topologías y demos de alta un nuevo EDGE desde la sección de Grupos de serivdores perimetrales – Nuevo grupo de servidores perimetrales
Pulsamos en Siguiente
En nuestro caso solo tendremos un EDGE (esto sería lo normal con una infraestructura tan humilde), por lo que elegimos la segunda opción (Grupo de un solo equipo) y escribimos el FQDN con el que lo vamos a identificar y pulsamos en Siguiente
Aquí es donde debemos empezar a prestar atención, lo primero es marcar la primera casilla de forma obligatoria según lo que queremos configurar. Esto es justamente lo que queremos, publicar todos los servicios del EDGE con un único nombre y dirección IP. Las otras dos son opcionales si queremos federarnos otros sistemas Lync (Compañias con Lync, Skype o sistemas que utilicen XMPP (Google, etc..)) y pulsamos en Siguiente
Elegimos habilitar las versiones de IPv4 o 6 en función de vuestra red y además indicamos que estamos detrás de un dispositivo NAT (pensad que solo tenemos una IP Pública y que estámos detrás de este dispositivo que gestiona la conexión WAN)
Otro paso importante, definir el nombre que vamos a publicar (será el nombre que debemos tener en el certificado que compremos) y el puerto de los distintos servicios. Como solo tenemos una dirección IP Pública y algo que no podemos cambiar es el puerto de las federaciones (TCP 5061), lo vamos a configurar para utilizarlo para que los usuarios externos puedan iniicar sesión y además para las federaciones. Pensad que Microsoft utiliza el 5061 para federar Lync con Skype y además Lync a Lync entre organizaciones, por lo que no podemos definir nosotros este puerto de otra forma. Para el resto de servicios debemos elegir puertos que no se esté utilizando en el sistema y tampoco el puerto 443 que será el que utilicemos para publicar los servicios Web. Esto debemos tenerlo muy en cuanta, los servicios web debemos publicarlo vía HTTPS y no cambiarles el puerto por defecto, sino sí que podéis tener problemas con el acceso a los distintos servicios (porque no se conectarán por otro puerto alternativo, están prefijados a nivel de diseño). Teniendo esto claro, yo he elegido el siguiente nombre (sip.asirlab.com) y puertos (5061, 444 y 446) y pulsamos en Siguiente
Escribimos la dirección IP Interna y pulsamos en Siguiente, de aquí la importancia de tener un router/Firewall con posibilidad de gestionar dos subredes en su interface(s) privada. Porque estoy seguro que la empresa tendrá más servidores y salen a Internet directamente por la subred Interna del Router/Firewall, pero con la otra subred IP del Router/Firewall simulamos una conexión WAN para el Reverse-Proxy y para la interface Externa del EDGE
Aquí escribimos la dirección IP de la interface externa y se debe corresponder con la subred que tengáis configurada en el router/firewall para que pueda tener acceso a Internet. El concepto es simple, pero es posible que os pueda resultar algo lioso sino lo tenéis claro.
Debemos especificar la IP Púlica que gestiona el Router/Firewall para que los usuarios externos puedan tener sesiones de A/V con el EDGE detrás de un dispositivo haciendo NAT. Por lo que especificamos la IP que tengáis como IP Pública, en uno LAB sería la 222.222.222.1 (mirad el esquema) y pulsamos en Siguiente
Otro paso importante, elegir nuestro servidor o pool de servidores Front-END como siguiente salto, que serán los servidores a los cuales enviarán las peticiones el/los EDGE, simplemente lo elegimos y pulsamos en Siguiente
Nos muestra un resumen de la configuración y pulsamos en Finalizar
Para completar la configuración de nuestra topología, únicamente debemos publciarla y configurar los disintos servicios del EDGE. Pero antes de publicarla revisaremos que la asignación de rutas de federaciones están bien, para ello seleccionamos el nombre nuestro sitio y nos fijamos en la sección de Asignación de ruta de federación del sitio, sino está configurado pulsamos encima del nombre del sitio con el botón secundario del ratón y pulsamos en Editar propiedades
Vamos a la sección de Ruta de Fedración y habilitamos las rutas de federación que consideremos oportuno
Ahora si vemos que tenemos todo configurado según lo que queremos y únicamente quedaría publicar la topología
Por último quedaría exportar la configuración para que en el EDGE podamos importarla y temrinar su configuración. Para ello utilizamos el siguiente cmdlet: Export-CsConfiguration -FileName <ruta_fichero_exportado>
El proceso de configuración del EDGE ya no lo voy a volver a comentar, lo tenéis descrito en la Guía de Lync publicada hace casi ya un año: Primera Guía de Instalación de Lync Server 2013 en Español.
Hasta aquí el artículo no tiene nada de especial, simplemente hemos configurado el EDGE detrás de un dispositivo NAT y hemos configurado los puertos para los distintos servicios. Para los servicios Web hemos dejado libre el 443, por lo que lo podremos "abrir" (Port Forwarding) hacia el Reverse-Proxy (TMG, IIS ARR, F5, KEMP, etc…) y con un certificado Wildcard o SAN tendremos todo los servicios disponibles. Aquí os dejo algunos artículos publicado anteriormente para que podáis volver a repasarlos, teniendo en cuenta que estos servicios se publican de forma "normal", porque no hemos cambiado el puerto por defecto (443):
- Lync Server: Reverse-Proxy requisito indispensable
- Cómo podemos publicar nuestros servicios de Lync (Exchange, WAC, …) vía reverse-proxy (IIS ARR)
- Publicar los servicios Web de Lync Server 2013 mediante TMG 2010
- Lync 2013: Publicar los Servicios de Lync Mobile
- Certificados SAN o Wildcard para nuestra implementación de Lync Server
En cuanto al certificado del EDGE, tendremos como siempre uno interno y otro externo. El nombre interno es edge.asirlab.com, por lo que ese será el nombre que tendrá en el certifidado. Y como para los servicios externos hemos configurado un único nombre y es el siguiente: sip.asirlab.com únicamente debe contener ese nombre el certificados externo:
- Federación Skype con Lync
- Federación y Acceso de Usuarios Externos
- Federación Lync – Skype: Opciones disponibles para el usuario final
- Lync Server: Un Edge, Un Certificado SAN para un Dominio, Múltiples Dominios SIP y Federaciones (Actualizado 12-06-2013)
- Federar Lync con MSN Messenger
- Federar Lync 2013 con Google Talk
En este caso, tenemos lo que necesitamos en cuanto a conectividad que es tener publicado el puerto 5061 (que además lo compartimos con el servicio de acceso), por lo que únicamente debemos crear el registro DNS de tipoo SRV con la siguiente configuración:
_sipfederationtls._tcp.asirlab.com SRV service location:
priority = 0
weight = 0
port = 5061
svr hostname = sip.asirlab.com
Y debemos tener el registro DNS de tipo A sip.asirlab.com para que se pueda resolver la dirección IP Pública que tenemos asociada a ese registro: 222.222.222.1 y el puerto redirigido la IP externa declarada en el EDGE: 192.168.250.120. Con esto y un certificado público (obligatorio para federarse con sistemas públicos (Skype, Google, etc..) y opcional con otras organizaciones con Lync porque les podemos enviar nuestro certificado raíz de nuestra CA Interna).
Con todo esto ya tenemos toda nuestra infraestructura funcionando sin problemas, estarían todos los servicios publicados con el mínimo coste ( Hardware y Certificados). Pero visto esto también quisiera comentar varios errores que he visto cuando alguna gente ha tratado de realizar esta configuración. La principal es la de utilizar puertos en el EDGE que se están utilzando en los servidores, por ejemplo utilizar para los servicios de Conferencias o A/V el puerto 445:
Una vez configurado, tendréis el problema que el servicio no se inicia y os volveréis locos sino tenéis claro el concepto:
Si revisáis el Visor de Eventos os lo dejará claro
Si ejecuto el comando netstat -an | find ":445" puedo ver que el puerto está a la escucha (disponble vamos para recibir perticiones) y en cualquier IP (interface) del equipo: 0.0.0.0
No podéis elgir un puerto que el sistema ya está utlizando, y el 445 es utilizado por el servicio de SMB (http://es.wikipedia.org/wiki/Server_Message_Block), y sirve para compartir archivos e impresoras en sistemas Microsoft. Esto es muy común e imagino que será por inercia de no utilizar el 443 y utilizar los siguientes: 444 y 445
Pero no debemos caer en este erro, debemos conocer los puertos estándar que utiliza nuestros servidor, sino no podemos levantar nunca el servicio. Cada servicio de red utiliza una combinación de Dirección IP y Puerto para estar a la "escucha", si alguien ya tiene ese puerto cogido no podremos iniciar el servicio. Esto es factible cuando tenemos nuestro EDGE con tres IP, entonces cada una de ellas podrá estar a la escucha por el mismo puerto, pero no podría haber otro servicio igualmente tratando de "escuchar" por el mismo puerto e IP. En todos los sistemas operativos de Microsoft, existe un fichero llamado Services con los nombres de los servicios y puertos que utiliza y está ubicado en la sigiuente ruta: C:\Windows\System32\drivers\etc.
En este fichero podemos encontrar los llamadas puertos "bien conocidos"
#
# This file contains port numbers for well-known services defined by IANA
#
# Format:
#
# <service name> <port number>/<protocol> [aliases…] [#<comment>]
#
echo 7/udp
discard 9/tcp sink null
discard 9/udp sink null
systat 11/tcp users #Active users
systat 11/udp users #Active users
daytime 13/tcp
daytime 13/udp
qotd 17/tcp quote #Quote of the day
qotd 17/udp quote #Quote of the day
chargen 19/tcp ttytst source #Character generator
chargen 19/udp ttytst source #Character generator
ftp-data 20/tcp #FTP, data
ftp 21/tcp #FTP. control
ssh 22/tcp #SSH Remote Login Protocol
telnet 23/tcp
smtp 25/tcp mail #Simple Mail Transfer Protocol
time 37/tcp timserver
time 37/udp timserver
rlp 39/udp resource #Resource Location Protocol
nameserver 42/tcp name #Host Name Server
nameserver 42/udp name #Host Name Server
nicname 43/tcp whois
domain 53/tcp #Domain Name Server
domain 53/udp #Domain Name Server
bootps 67/udp dhcps #Bootstrap Protocol Server
bootpc 68/udp dhcpc #Bootstrap Protocol Client
tftp 69/udp #Trivial File Transfer
gopher 70/tcp
finger 79/tcp
http 80/tcp www www-http #World Wide Web
hosts2-ns 81/tcp #HOSTS2 Name Server
hosts2-ns 81/udp #HOSTS2 Name Server
kerberos 88/tcp krb5 kerberos-sec #Kerberos
kerberos 88/udp krb5 kerberos-sec #Kerberos
hostname 101/tcp hostnames #NIC Host Name Server
iso-tsap 102/tcp #ISO-TSAP Class 0
rtelnet 107/tcp #Remote Telnet Service
pop2 109/tcp postoffice #Post Office Protocol – Version 2
pop3 110/tcp #Post Office Protocol – Version 3
sunrpc 111/tcp rpcbind portmap #SUN Remote Procedure Call
sunrpc 111/udp rpcbind portmap #SUN Remote Procedure Call
auth 113/tcp ident tap #Identification Protocol
uucp-path 117/tcp
sqlserv 118/tcp #SQL Services
nntp 119/tcp usenet #Network News Transfer Protocol
ntp 123/udp #Network Time Protocol
epmap 135/tcp loc-srv #DCE endpoint resolution
epmap 135/udp loc-srv #DCE endpoint resolution
netbios-ns 137/tcp nbname #NETBIOS Name Service
netbios-ns 137/udp nbname #NETBIOS Name Service
netbios-dgm 138/udp nbdatagram #NETBIOS Datagram Service
netbios-ssn 139/tcp nbsession #NETBIOS Session Service
imap 143/tcp imap4 #Internet Message Access Protocol
sql-net 150/tcp
sqlsrv 156/tcp
pcmail-srv 158/tcp #PCMail Server
snmp 161/udp #SNMP
snmptrap 162/udp snmp-trap #SNMP trap
print-srv 170/tcp #Network PostScript
bgp 179/tcp #Border Gateway Protocol
irc 194/tcp #Internet Relay Chat Protocol
ipx 213/udp #IPX over IP
rtsps 322/tcp
rtsps 322/udp
mftp 349/tcp
mftp 349/udp
ldap 389/tcp #Lightweight Directory Access Protocol
https 443/tcp MCom #HTTP over TLS/SSL
https 443/udp MCom #HTTP over TLS/SSL
microsoft-ds 445/tcp
microsoft-ds 445/udp
kpasswd 464/tcp # Kerberos (v5)
kpasswd 464/udp # Kerberos (v5)
isakmp 500/udp ike #Internet Key Exchange
crs 507/tcp #Content Replication System
crs 507/udp #Content Replication System
exec 512/tcp #Remote Process Execution
biff 512/udp comsat
login 513/tcp #Remote Login
who 513/udp whod
cmd 514/tcp shell
syslog 514/udp
printer 515/tcp spooler
talk 517/udp
ntalk 518/udp
efs 520/tcp #Extended File Name Server
router 520/udp route routed
ulp 522/tcp
ulp 522/udp
timed 525/udp timeserver
tempo 526/tcp newdate
irc-serv 529/tcp
irc-serv 529/udp
courier 530/tcp rpc
conference 531/tcp chat
netnews 532/tcp readnews
netwall 533/udp #For emergency broadcasts
uucp 540/tcp uucpd
klogin 543/tcp #Kerberos login
kshell 544/tcp krcmd #Kerberos remote shell
dhcpv6-client 546/tcp #DHCPv6 Client
dhcpv6-client 546/udp #DHCPv6 Client
dhcpv6-server 547/tcp #DHCPv6 Server
dhcpv6-server 547/udp #DHCPv6 Server
afpovertcp 548/tcp #AFP over TCP
afpovertcp 548/udp #AFP over TCP
new-rwho 550/udp new-who
rtsp 554/tcp #Real Time Stream Control Protocol
rtsp 554/udp #Real Time Stream Control Protocol
remotefs 556/tcp rfs rfs_server
rmonitor 560/udp rmonitord
monitor 561/udp
nntps 563/tcp snntp #NNTP over TLS/SSL
nntps 563/udp snntp #NNTP over TLS/SSL
whoami 565/tcp
whoami 565/udp
ms-shuttle 568/tcp #Microsoft shuttle
ms-shuttle 568/udp #Microsoft shuttle
ms-rome 569/tcp #Microsoft rome
ms-rome 569/udp #Microsoft rome
http-rpc-epmap 593/tcp #HTTP RPC Ep Map
http-rpc-epmap 593/udp #HTTP RPC Ep Map
hmmp-ind 612/tcp #HMMP Indication
hmmp-ind 612/udp #HMMP Indication
hmmp-op 613/tcp #HMMP Operation
hmmp-op 613/udp #HMMP Operation
ldaps 636/tcp sldap #LDAP over TLS/SSL
doom 666/tcp #Doom Id Software
doom 666/udp #Doom Id Software
msexch-routing 691/tcp #MS Exchange Routing
msexch-routing 691/udp #MS Exchange Routing
kerberos-adm 749/tcp #Kerberos administration
kerberos-adm 749/udp #Kerberos administration
kerberos-iv 750/udp #Kerberos version IV
mdbs_daemon 800/tcp
mdbs_daemon 800/udp
ftps-data 989/tcp #FTP data, over TLS/SSL
ftps 990/tcp #FTP control, over TLS/SSL
telnets 992/tcp #Telnet protocol over TLS/SSL
imaps 993/tcp #IMAP4 protocol over TLS/SSL
ircs 994/tcp #IRC protocol over TLS/SSL
pop3s 995/tcp spop3 #pop3 protocol over TLS/SSL (was spop3)
pop3s 995/udp spop3 #pop3 protocol over TLS/SSL (was spop3)
kpop 1109/tcp #Kerberos POP
nfsd-status 1110/tcp #Cluster status info
nfsd-keepalive 1110/udp #Client status info
nfa 1155/tcp #Network File Access
nfa 1155/udp #Network File Access
activesync 1034/tcp #ActiveSync Notifications
phone 1167/udp #Conference calling
opsmgr 1270/tcp #Microsoft Operations Manager
opsmgr 1270/udp #Microsoft Operations Manager
ms-sql-s 1433/tcp #Microsoft-SQL-Server
ms-sql-s 1433/udp #Microsoft-SQL-Server
ms-sql-m 1434/tcp #Microsoft-SQL-Monitor
ms-sql-m 1434/udp #Microsoft-SQL-Monitor
ms-sna-server 1477/tcp
ms-sna-server 1477/udp
ms-sna-base 1478/tcp
ms-sna-base 1478/udp
wins 1512/tcp #Microsoft Windows Internet Name Service
wins 1512/udp #Microsoft Windows Internet Name Service
ingreslock 1524/tcp ingres
stt 1607/tcp
stt 1607/udp
l2tp 1701/udp #Layer Two Tunneling Protocol
pptconference 1711/tcp
pptconference 1711/udp
pptp 1723/tcp #Point-to-point tunnelling protocol
msiccp 1731/tcp
msiccp 1731/udp
remote-winsock 1745/tcp
remote-winsock 1745/udp
ms-streaming 1755/tcp
ms-streaming 1755/udp
msmq 1801/tcp #Microsoft Message Queue
msmq 1801/udp #Microsoft Message Queue
radius 1812/udp #RADIUS authentication protocol
radacct 1813/udp #RADIUS accounting protocol
msnp 1863/tcp
msnp 1863/udp
ssdp 1900/tcp
ssdp 1900/udp
close-combat 1944/tcp
close-combat 1944/udp
nfsd 2049/udp nfs #NFS server
knetd 2053/tcp #Kerberos de-multiplexor
mzap 2106/tcp #Multicast-Scope Zone Announcement Protocol
mzap 2106/udp #Multicast-Scope Zone Announcement Protocol
qwave 2177/tcp #QWAVE
qwave 2177/udp #QWAVE Experiment Port
directplay 2234/tcp #DirectPlay
directplay 2234/udp #DirectPlay
ms-olap3 2382/tcp #Microsoft OLAP 3
ms-olap3 2382/udp #Microsoft OLAP 3
ms-olap4 2383/tcp #Microsoft OLAP 4
ms-olap4 2383/udp #Microsoft OLAP 4
ms-olap1 2393/tcp #Microsoft OLAP 1
ms-olap1 2393/udp #Microsoft OLAP 1
ms-olap2 2394/tcp #Microsoft OLAP 2
ms-olap2 2394/udp #Microsoft OLAP 2
ms-theater 2460/tcp
ms-theater 2460/udp
wlbs 2504/tcp #Microsoft Windows Load Balancing Server
wlbs 2504/udp #Microsoft Windows Load Balancing Server
ms-v-worlds 2525/tcp #Microsoft V-Worlds
ms-v-worlds 2525/udp #Microsoft V-Worlds
sms-rcinfo 2701/tcp #SMS RCINFO
sms-rcinfo 2701/udp #SMS RCINFO
sms-xfer 2702/tcp #SMS XFER
sms-xfer 2702/udp #SMS XFER
sms-chat 2703/tcp #SMS CHAT
sms-chat 2703/udp #SMS CHAT
sms-remctrl 2704/tcp #SMS REMCTRL
sms-remctrl 2704/udp #SMS REMCTRL
msolap-ptp2 2725/tcp #MSOLAP PTP2
msolap-ptp2 2725/udp #MSOLAP PTP2
icslap 2869/tcp
icslap 2869/udp
cifs 3020/tcp
cifs 3020/udp
xbox 3074/tcp #Microsoft Xbox game port
xbox 3074/udp #Microsoft Xbox game port
ms-dotnetster 3126/tcp #Microsoft .NET ster port
ms-dotnetster 3126/udp #Microsoft .NET ster port
ms-rule-engine 3132/tcp #Microsoft Business Rule Engine Update Service
ms-rule-engine 3132/udp #Microsoft Business Rule Engine Update Service
msft-gc 3268/tcp #Microsoft Global Catalog
msft-gc 3268/udp #Microsoft Global Catalog
msft-gc-ssl 3269/tcp #Microsoft Global Catalog with LDAP/SSL
msft-gc-ssl 3269/udp #Microsoft Global Catalog with LDAP/SSL
ms-cluster-net 3343/tcp #Microsoft Cluster Net
ms-cluster-net 3343/udp #Microsoft Cluster Net
ms-wbt-server 3389/tcp #MS WBT Server
ms-wbt-server 3389/udp #MS WBT Server
ms-la 3535/tcp #Microsoft Class Server
ms-la 3535/udp #Microsoft Class Server
pnrp-port 3540/tcp #PNRP User Port
pnrp-port 3540/udp #PNRP User Port
teredo 3544/tcp #Teredo Port
teredo 3544/udp #Teredo Port
p2pgroup 3587/tcp #Peer to Peer Grouping
p2pgroup 3587/udp #Peer to Peer Grouping
ws-discovery 3702/udp #WS-Discovery
ws-discovery 3702/tcp #WS-Discovery
dvcprov-port 3776/tcp #Device Provisioning Port
dvcprov-port 3776/udp #Device Provisioning Port
msfw-control 3847/tcp #Microsoft Firewall Control
msdts1 3882/tcp #DTS Service Port
sdp-portmapper 3935/tcp #SDP Port Mapper Protocol
sdp-portmapper 3935/udp #SDP Port Mapper Protocol
net-device 4350/tcp #Net Device
net-device 4350/udp #Net Device
ipsec-msft 4500/tcp #Microsoft IPsec NAT-T
ipsec-msft 4500/udp #Microsoft IPsec NAT-T
llmnr 5355/tcp #LLMNR
llmnr 5355/udp #LLMNR
wsd 5357/tcp #Web Services on devices
wsd 5358/tcp #Web Services on devices
rrac 5678/tcp #Remote Replication Agent Connection
rrac 5678/udp #Remote Replication Agent Connection
dccm 5679/tcp #Direct Cable Connect Manager
dccm 5679/udp #Direct Cable Connect Manager
ms-licensing 5720/tcp #Microsoft Licensing
ms-licensing 5720/udp #Microsoft Licensing
directplay8 6073/tcp #DirectPlay8
directplay8 6073/udp #DirectPlay8
man 9535/tcp #Remote Man Server
rasadv 9753/tcp
rasadv 9753/udp
imip-channels 11320/tcp #IMIP Channels Port
imip-channels 11320/udp #IMIP Channels Port
directplaysrvr 47624/tcp #Direct Play Server
directplaysrvr 47624/udp #Direct Play Server
Y que el sistema utlizará para identificarlo, pero NO UTILICEMOS ESTO PARA CAMBIAR NADA, simplemente utilicemos otro puerto para el servicio y cambiémoslo en el generador de topologías, porque mediante la replicación entre el Front-END y el EDGE (vía puerto 4443) se le enviarán los cambios al EDGE y los servicios de iniciarán sin problema. En mi caso he elegido el puerto 446 (si lo buscáis en la lista no lo encontraréis, por lo que a menos que tengáis alguna aplicacion propietaría no está asignado a ningún servicio estándar)
Y una vez recibido el cambio en el EDGE mediante la replicación ya podemos iniciar sin problemas el servicio en el puerto 446
Ahora que los servicios se han iniciado correctamente, podemos verificar que el puerto está a la escucha con el siguiente comando: netstat -an | find ":446" y solo por la IP externa (192.168.192.120) que debe estar asignado este puerto:
Por lo que no os dejéis llevar por la "inercia" del querer terminar sin más y analizar con cuidado antes estas cosas. Porque sino como podéis apreciar, los servicios no se iniciarán nunca a pesar de que "pensemos" que teemos todo "bien configurado".
Y por último como comentario, deciros que sino utilizamos el puerto 443 para los servicios del EDGE o servicios Web a publicar, podemos tener problemas de conexión en algunos entornos. Por ejemplo, hoteles, redes inalámbricas públicas o privadas (empresas), porque si tienen una sistema de control de internet lo normal es que se permitan únicamente ciertos protocolos:
-
DNS
-
HTTP
-
HTTPS: el puerto es el 443, por lo que podríamos conectarnos por lo menos a Lync vía IM (por que podemos tener acceso al 443 pero luego tener bloqueados los puertos del RTP: 50.000-59.999)
-
FTP
-
POP (cada vez menos, viva Exchange)
-
SMTP Cliente (cada vez menos, viva Exchange)
Que podemos publicar todos los servicios con una IP Pública es cierto, con la mínima inversión, etc… pero así es posible que tengamos algún problema de conectividad por filtrado de puertos en muchas redes.
El puerto 5061 cada día es más habitual, por lo que es posible que para iniciar sesión no tengáis problemas, pero para uniros a conferencias con el cliente Lync e iniciar una sesión de A/V será más complicado. Aquí la cuestión es utilizar puertos que podamos tener disponibles y que estén habilitados en los firewalls de las redes desde las cuales nos conectemos, pero si tenemos vía libre por parte del "firewall", Lync (y servicios adyacentes) se puede implementar sin problemas con una sola IP. Como los servicios Web (Lync Móvil, Exchange (EWS), WAC) van todos mediante el puerto 443 y lo hemos dejado libre, únicamente debemos configurarlo en el reverse-proxy con su certificado correspondiente y poco más.
Espero que os esa de utilidad!!
Os adjunto los Open Specifications Posters en PDF
ExchangeOpenSpecPoster.pdf
