Este problema pode acontecer tanto em federação com o Skype (PIC), quanto em federação com parceiros. É um problema simples, porém diretamente relacionado com uma configuração incorreta que já vi alguns clientes cometerem.
Vale lembrar, o Lync possui alguns requisitos de portas abertas no Firewall para que o acesso externo, federação e etc. funcionem corretamente, requisitos específicos para o funcionamento saudável do Edge. Vocês podem encontrar estes requisitos neste artigo do TechNet:
Resumo de Porta - borda consolidada única com endereços IP privados usando NAT
Este é o artigo mais comumente utilizado para o Brasil, visto que aqui, geralmente encontramos topologia com apenas um Edge e utilizando NAT. Acessando o artigo, você encontrará do lado esquerdo orientações para outros tipos de topologia.
Por esquecer de seguir este artigo e por não abrir todas portas necessárias, você poderá ter diversos problemas com o Lync para usuários externos. No caso em que estamos discutindo aqui, os usuários não conseguirão falar com usuários federados ou de PIC devido a falhas de resolução DNS. No caso da federação Skype, o usuário Skype irá conseguir encontrá-lo e adicionar, irá reconhecer a federação com o seu Lync, mas ele verá o usuário como se este não tivesse sido adicionado e com "presença desconhecida".
Do lado da estrutura do Lync, ele também verá o usuário Skype (ou federado) com presença desconhecida e ao tentar enviar mensagens, receberá um mensagem de erro ID 404. Se analisarmos os logs de UCCAPI do usuário, veremos algo parecido com o que vemos abaixo:
Neste caso, o principal erro é que foi configurado na placa Externa do Edge o IP de um DNS público, mas não foi aberto no Firewall a porta 53/TCP e 53/UDP para consultas DNS. Por este motivo, o Edge não era capaz de resolver nomes e portanto não era capaz de se comunicar com qualquer domínio que ele não conhecesse. Na tabela abaixo, extraída do artigo do TechNet, essa necessidade fica muito clara!
| Função/Protocolo/TCP ou UDP/Porta | Endereço IP de origem | Endereço IP de destino | Observações |
|---|---|---|---|
| Acesso/DNS/TCP/53 | Servidor de Borda Serviço de Borda de Acesso | Qualquer uma | Consulta de DNS sobre TCP |
| Acesso/DNS/UDP/53 | Servidor de Borda Serviço de Borda de Acesso | Qualquer um | Consulta de DNS sobre UDP |
Após resolvermos o problema de consulta DNS, o Edge foi capaz de resolver os nomes corretamente, porém ainda tínhamos problemas de comunicação com os parceiros federados. Só que dessa vez, ao enviar mensagens, o erro recebido era o ID 504. O usuário recebia mensagens, porém não enviava:
Mais uma vez, o erro estava relacionado à porta 5061, que devido a um erro na regra do firewall do cliente, estava bloqueando o tráfego. A porta 5061 é a porta essencial para que a federação funcione corretamente. A porta estava aberta Inbound, porém não Outbound.
| Função/Protocolo/TCP ou UDP/Porta | Endereço IP de origem | Endereço IP de destino | Observações |
|---|---|---|---|
| Acesso/SIP(MTLS)/TCP/5061 | Qualquer um | Servidor de Borda Serviço de Borda de Acesso | Para conectividade pública e federada de mensagens instantâneas usando SIP |
| Acesso/SIP(MTLS)/TCP/5061 | Servidor de Borda Serviço de Borda de Acesso | Qualquer uma | Para conectividade pública e federada de mensagens instantâneas usando SIP |
Por isso, vale se atentar ao artigo acima citado na hora de realizar o deploy do Edge e se preocupar com as portas necessárias. As regras devem ser seguidas com atenção, pois qualquer erro causará problemas de comunicação de todos os tipos. Aqui falamos apenas de federação e mensagens instantâneas, mas temos voz, vídeo, conferências e tudo isso é influenciado por um deploy correto.
Nenhum comentário:
Postar um comentário