Como funciona integração com Hubsoft: etapas e testes para provedores
Como funciona integração com Hubsoft: primeiro se monta um caminho fechado entre a nuvem onde o sistema roda e cada POP, e só depois os concentradores, as OLTs e o ACS passam a receber ordens por esse caminho. O trabalho termina com um ensaio de queda, em que o link até a nuvem é desligado de propósito para provar que os clientes continuam autenticando.
Resumo
- O Hubsoft roda fora do provedor, então toda ordem de corte ou ativação atravessa a internet até o POP.
- A ordem das etapas é fixa, do levantamento ao caminho, à autenticação, aos equipamentos, ao ensaio e à entrega.
- O provedor reúne endereços de saída da nuvem e mapa de POPs, e recebe diagrama, acessos e relatório do ensaio.
- O que mais falha é o silêncio, como o túnel que cai sem alerta e o corte que se perde sem ninguém notar.
Onde fica cada peça quando o ERP mora na nuvem
O sistema fica no datacenter do fornecedor e os equipamentos ficam nos POPs do provedor, separados pela internet. Entre os dois lados existem quatro peças, cada uma com um papel e um responsável.
O Hubsoft é um ERP de provedor vendido como serviço em nuvem: o provedor acessa pelo navegador e não mantém o servidor do sistema [CONFIRMAR na documentação do fornecedor]. Isso tira do provedor o cuidado com a máquina, mas cria uma distância que os sistemas instalados no POP não têm.
A integração com Hubsoft trata essa distância como parte da rede. A Táquion Tech configura o caminho, o firewall e os equipamentos do lado do provedor, e o fornecedor cuida do sistema do lado dele.
| Peça | Onde fica | Função | Quem cuida |
|---|---|---|---|
| Sistema | Nuvem do fornecedor | Guarda contratos e gera as ordens de corte, liberação e ativação | Fornecedor do Hubsoft |
| Caminho | Entre a saída da nuvem e a borda de cada POP | Leva as ordens por túnel cifrado ou filtradas por endereço | Provedor, ou quem ele contratar |
| Autenticação local | Servidor dentro da rede do provedor | Responde aos logins quando a nuvem está fora de alcance [CONFIRMAR na documentação do fornecedor] | Provedor |
| Equipamentos | Cada POP | Concentradores, OLTs e ACS que executam as ordens recebidas | Provedor |
A coluna da direita desfaz uma confusão comum. O suporte do sistema resolve o que acontece dentro da nuvem, mas não enxerga o firewall do POP, e é ali que a maioria das integrações trava.
Como funciona integração com Hubsoft em comparação com um ERP instalado no POP?
A lógica dos eventos é a mesma de qualquer sistema de gestão, explicada em como funciona integração com ERP de provedor. O que muda é o trajeto: com o sistema no POP, a ordem anda alguns metros dentro da rede; com o Hubsoft, ela cruza a internet e depende do link de trânsito.
Por isso duas perguntas, que quase não existem num sistema local, viram centrais aqui. Como a ordem entra na rede sem abrir a gerência para todos, e o que acontece com os logins quando o link até a nuvem cai.
As etapas da integração com Hubsoft, na ordem
São seis etapas, e o caminho fechado vem antes de qualquer equipamento receber ordem da nuvem. O peso relativo de cada uma no tempo total aparece entre parênteses.
- Levantamento (curto): lista de POPs, links de trânsito, equipamentos com marca e versão, e o que o plano contratado do Hubsoft libera para integração.
- Caminho (médio): túnel cifrado ou regras por endereço de origem em cada POP, com a gerência fechada para o resto da internet.
- Autenticação (médio): concentradores apontados para a nuvem e para o ponto local, com segredo próprio em cada um.
- Equipamentos (o mais longo): OLTs e ACS ligados, perfis padronizados e corte com derrubada de sessão configurado.
- Ensaio de queda (curto): link até a nuvem desligado de propósito em janela, com clientes de teste reconectando.
- Entrega (curto): diagrama do caminho, lista de acessos, relatório do ensaio e roteiro para quando a nuvem não responde.
O prazo de cada etapa depende sobretudo do número de POPs com saída própria [PREENCHER prazo típico da Táquion Tech]. O que muda o valor está no guia de quanto custa integração com Hubsoft, e não se repete aqui.
O que o provedor reúne antes do levantamento
Boa parte do levantamento depende de informação que só o provedor e o fornecedor têm. Com estes itens em mãos, a primeira etapa não fica esperando ninguém.
Itens para separar antes de começar a integração com Hubsoft
- Lista dos endereços de saída da nuvem do Hubsoft, pedida ao fornecedor.
- Mapa dos POPs, com a borda e os links de trânsito de cada um.
- Concentradores, OLTs e ACS, com marca, modelo e versão de sistema.
- Plano contratado do Hubsoft e recursos de integração liberados nele.
- Um usuário no painel do Hubsoft com permissão de integração.
- Dois contratos de teste por POP, que possam ser bloqueados à vontade.
O primeiro item é o que mais atrasa, porque depende do fornecedor. Peça a lista de endereços no mesmo dia em que decidir integrar.
Como uma ordem da nuvem chega ao concentrador?
A ordem sai do Hubsoft, entra pelo túnel ou passa pelo filtro de endereço na borda do POP e chega ao concentrador, que derruba ou libera a sessão. O diagrama mostra um corte por atraso fazendo esse trajeto.
1 · Nuvem
Ordem de corte gerada
O contrato vence, a régua de cobrança marca o bloqueio e o sistema prepara o pedido de desconexão.
2 · Internet
Saída por endereço conhecido
O pedido sai por um dos endereços que o fornecedor informou, o mesmo que a borda do POP espera receber.
3 · Borda do POP
Entrada pelo caminho fechado
O túnel entrega o pedido dentro da rede, ou o firewall confere a origem e descarta qualquer outro endereço.
4 · Concentrador
Sessão derrubada
O concentrador aceita o pedido na porta combinada, derruba a sessão e o cliente reconecta na página de aviso.
5 · Registro
Comando anotado
O equipamento grava quem pediu e quando, e um alerta dispara se o túnel estiver fora no momento do corte.
Se a etapa 3 falhar em silêncio, o Hubsoft mostra o cliente bloqueado e o concentrador mantém a sessão aberta. Por isso o alerta de túnel fora é montado junto com o caminho, e não depois.
O login de cada assinante faz o trajeto inverso: o concentrador pergunta e a resposta vem da nuvem ou do ponto local. Onde essa resposta nasce é decidido na etapa de autenticação e conferido no ensaio de queda.
Os cortes do Hubsoft estão chegando ao concentrador?
Um Especialista refaz o caminho entre a nuvem e cada POP, fecha a gerência para o resto da internet e configura alerta para o túnel fora.
Exemplo: a borda de um POP preparada para a nuvem
O bloco mostra um jeito de preparar um concentrador MikroTik para aceitar ordens só da nuvem e do ponto local. Os endereços são de documentação, e a lista real vem do fornecedor do sistema.
# Endereços de saída da nuvem informados pelo fornecedor (exemplo)
/ip firewall address-list
add list=nuvem-erp address=203.0.113.10
add list=nuvem-erp address=203.0.113.11
# Pedido de desconexão (UDP 3799) aceito só da nuvem e do RADIUS local
/ip firewall filter
add chain=input protocol=udp dst-port=3799 src-address-list=nuvem-erp action=accept comment="CoA nuvem"
add chain=input protocol=udp dst-port=3799 src-address=198.51.100.20 action=accept comment="CoA local"
add chain=input protocol=udp dst-port=3799 action=drop
# Dois servidores de autenticação: ponto local e nuvem pelo túnel
/radius
add service=ppp address=198.51.100.20 secret=SEGREDO-LOCAL timeout=1s
add service=ppp address=192.0.2.1 secret=SEGREDO-NUVEM timeout=2s
/radius incoming set accept=yes port=3799A ordem dos servidores e o tempo de espera decidem quanto um login demora quando a nuvem está fora. Esse ajuste é fechado no ensaio de queda, com clientes de teste, e não no papel.
Ensaio de queda: o teste que fecha a integração com Hubsoft
O ensaio desliga o caminho até a nuvem de propósito, em janela, e confere o que continua funcionando. É a única forma de saber, antes de uma queda real, se a autenticação local e o alerta existem de verdade.
| Momento | O que se faz | Resultado esperado |
|---|---|---|
| Antes | Clientes de teste conectados e um corte enviado pelo Hubsoft | Sessão derrubada e comando anotado no concentrador |
| Link desligado | Caminho até a nuvem cortado na borda do POP | Alerta de túnel fora chega à equipe pelo canal combinado |
| Durante a queda | Clientes de teste reiniciam o roteador | Login aceito pelo ponto local, com o plano certo |
| Durante a queda | Corte disparado no Hubsoft | Pedido fica pendente e o registro mostra que não chegou |
| Link de volta | Caminho restabelecido | Túnel sobe sozinho e os pedidos pendentes aparecem para refazer [CONFIRMAR na documentação do fornecedor] |
O ensaio é repetido em cada POP com saída própria, porque um POP pode estar certo e o vizinho não. O resultado de cada linha vai para o relatório de entrega, com data e horário.
O que acontece com os cortes enquanto a nuvem está fora?
Enquanto a nuvem não alcança o concentrador, os cortes do período ficam pendentes. O desenho precisa dizer quem os refaz quando o caminho volta: o próprio sistema, uma rotina agendada ou alguém da equipe com uma lista.
Quando todos os clientes caem juntos e a suspeita é a autenticação, a ordem de verificação está no guia sobre PPPoE caindo para todos os clientes.
Erros que só aparecem depois da virada
Na integração com nuvem, os erros ficam escondidos enquanto o link está de pé. A lista traz cada atalho com o sinal que costuma denunciá-lo.
Evite estes atalhos ao ligar o Hubsoft à rede
- Gerência aberta para facilitar: a nuvem entra, mas as varreduras da internet também, e as tentativas de senha enchem o log do concentrador.
- Um usuário para tudo: a nuvem usa o mesmo usuário dos técnicos, e o log não separa o comando automático do manual.
- Túnel sem alerta: o caminho cai num domingo e só se descobre na segunda, pelos bloqueados que seguiram navegando.
- Lista de endereços parada: o fornecedor muda um endereço de saída, a regra não acompanha e as ordens param sem erro aparente.
- POP novo esquecido: a cidade nova recebe clientes antes de ter caminho e ensaio próprios.
Separar o usuário da nuvem do usuário de cada técnico resolve o segundo atalho e facilita qualquer auditoria. O guia de implantação de TACACS mostra como registrar quem executou cada comando.
O que o provedor recebe ao fim da integração com Hubsoft?
O provedor recebe a integração funcionando e os documentos para mantê-la sem depender de quem montou. Cada item responde a uma pergunta que surge numa queda real.
- Diagrama do caminho: por onde cada ordem passa, da nuvem até cada equipamento, POP por POP.
- Lista de acessos: usuários criados para a nuvem e para a equipe, com as permissões de cada um.
- Relatório do ensaio: o resultado de cada teste de queda, com data, horário e o que foi corrigido.
- Roteiro de contingência: o que fazer quando a nuvem não responde e como refazer os cortes pendentes.
- Regras de firewall: os endereços aceitos em cada borda e quem deve atualizar a lista.
A integração com Hubsoft exige manutenção pequena e contínua, como renovar chaves do túnel, acompanhar a lista de endereços e repetir o ensaio quando um POP muda. Quem cuida disso depois da entrega fica combinado por escrito [CONFIRMAR oferta].
A guarda dos registros de conexão continua sendo do provedor mesmo com a contabilização na nuvem [CONFIRMAR na norma]. O roteiro de entrega indica onde esses registros ficam e como exportá-los.
Perguntas frequentes
O suporte do Hubsoft configura o firewall do meu POP?
O suporte do fornecedor cuida do sistema na nuvem e pode orientar sobre endereços e recursos de integração [CONFIRMAR na documentação do fornecedor]. Firewall, túnel e concentradores ficam do lado do provedor, com a equipe dele ou com quem ele contratar.
Quantas janelas de manutenção a integração precisa?
Em geral, uma janela por POP para caminho e autenticação e outra para o ensaio de queda, que podem ser a mesma em redes pequenas. O número exato sai do levantamento e vai na proposta.
Clientes já conectados caem quando o túnel cai?
Não, a sessão aberta continua no concentrador, que não depende da nuvem para manter quem já entrou. O problema aparece em quem tenta conectar de novo e nos cortes que deixam de chegar.
Preciso de túnel se o Hubsoft publica os endereços de saída?
Não é obrigatório, porque a regra por endereço de origem também restringe o acesso. O túnel compensa quando há vários POPs ou quando a gerência não pode ficar visível para nenhum endereço externo.
Ligar um POP novo obriga a refazer a integração inteira?
Não. O POP novo recebe o seu caminho, os seus equipamentos cadastrados e o seu ensaio de queda, seguindo o mesmo diagrama dos POPs que já estão ligados.
Responsável técnico da Táquion Tech · Registro profissional [PREENCHER]
Mais de 15 anos em operações de rede, com gestão de infraestruturas de TI, administração de data centers e condução de equipes em migrações de TI e telecomunicações, com foco em alta disponibilidade e segurança.
A Táquion Tech é uma empresa de engenharia de redes de Balneário Camboriú (SC) que projeta, opera e dá suporte a redes de provedores de internet e de empresas.
Fontes
- RFC 5176: Dynamic Authorization Extensions to RADIUS: pedido de desconexão que a nuvem manda ao concentrador, na porta UDP 3799
- RFC 4301: Security Architecture for the Internet Protocol: base do túnel IPsec que pode ligar a saída da nuvem à borda de cada POP
- RADIUS no RouterOS (documentação MikroTik): cadastro de mais de um servidor de autenticação e recebimento de pedidos de desconexão
