Guia explicativo · Starlink como contingência
Como funciona integração de Starlink como contingência no provedor
Como funciona integração de Starlink como contingência: o roteador do POP abre um túnel pela antena de satélite até um equipamento do provedor com IP fixo e deixa esse caminho parado, com rota de custo alto, até a fibra ou o rádio principal cair. O serviço anda em cinco etapas, do levantamento dos POPs à queda simulada, e termina com configuração, alertas e roteiro de teste nas mãos do provedor.
Resumo
- O terminal fica atrás de CGNAT, então a gerência só alcança o POP por um túnel que o próprio roteador abre de dentro para fora.
- A troca de caminho é decidida pelo roteador, por custo de rota no OSPF ou por teste de alcance, sem ninguém entrar no equipamento.
- O provedor prepara a lista de POPs, o ponto de chegada do túnel, a energia do rack e uma janela para derrubar o link principal.
- No fim, o provedor recebe a configuração comentada, os alertas testados, o tempo de troca medido e um roteiro para repetir a queda.
Como funciona integração de Starlink como contingência por dentro da rede
Por dentro, a integração junta um terminal de órbita baixa atrás de CGNAT, um túnel que atravessa esse CGNAT e uma regra de roteamento que só usa o túnel quando o caminho principal some. A antena sozinha não faz contingência.
Para o roteador do POP, o terminal de satélite aparece como uma porta de internet comum, com endereço recebido por DHCP. A diferença está no endereço. Nos planos residenciais, o terminal recebe um IPv4 da faixa compartilhada 100.64.0.0/10, reservada pela RFC 6598 para CGNAT, e nenhum equipamento de fora consegue iniciar conexão até ele [CONFIRMAR nos termos do fornecedor]. O guia sobre como funciona o CGNAT explica essa limitação.
Por isso a integração de Starlink como contingência inverte o sentido da conexão: quem liga é o POP. A Táquion Tech configura o roteador do POP para abrir um túnel até um concentrador do provedor com IP público, e é por esse túnel que passam as rotas, a gerência e a autenticação dos clientes.
1 · POP
Roteador perde o vizinho principal
O enlace de rádio ou a fibra para de responder, e a rota principal sai da tabela de roteamento.
2 · Túnel
Rota de custo alto assume
Gerência, RADIUS e monitoramento passam a entrar no túnel que já estava aberto pela antena.
3 · Satélite
Terminal leva o pacote ao céu
O pacote sobe ao satélite, desce numa estação terrestre do fornecedor e segue pela internet.
4 · Núcleo
Concentrador entrega ao destino
O concentrador com IP fixo abre o túnel e entrega o pacote ao servidor RADIUS, ao painel ou ao NOC.
Quando o vizinho principal volta, a rota de custo baixo reaparece e o tráfego sai do túnel sem ação manual. O túnel continua aberto, à espera da próxima queda.
Por que o túnel precisa ficar sempre aberto?
O CGNAT do fornecedor guarda o mapeamento de cada conexão por pouco tempo sem tráfego [CONFIRMAR tempo de expiração no fornecedor]. Um túnel aberto só na hora da queda começaria a negociar justo na crise.
Por isso o túnel sobe no dia da instalação e fica de pé o tempo todo, com um pacote de manutenção a cada poucos segundos. No WireGuard, esse pacote se chama persistent keepalive, e a documentação oficial sugere 25 segundos como intervalo que atravessa a maioria dos NATs.
Como o roteador decide usar o satélite
A decisão fica no roteador do POP, e há dois jeitos comuns de tomá-la. Nos dois, a troca acontece sozinha e a volta também, assim que a rota principal se recupera.
- Custo de rota: o OSPF anuncia as mesmas redes pelos dois caminhos, mas o túnel tem custo muito maior e só assume quando o vizinho principal some.
- Teste de alcance: o roteador consulta um endereço distante pela rota principal e, sem resposta, ativa a rota pelo túnel; serve para POP com rota estática.
O guia de configuração de OSPF detalha o custo de interface, o desenho que evita uma regra diferente para cada POP.
O que define o tempo de troca
O tempo até a gerência voltar pelo satélite depende dos temporizadores do roteador, e não da antena. Por isso ele é medido na entrega, e não prometido antes.
- OSPF: com os valores padrão da RFC 2328, o vizinho só é dado como morto depois de 40 segundos sem hello [CONFIRMAR na versão do equipamento].
- BFD: quando o enlace principal suporta, a falha é detectada em frações de segundo e o OSPF reage antes.
As cinco etapas, na ordem em que acontecem
O serviço anda em cinco etapas, e cada uma só começa quando a anterior deixou um entregável aprovado. A tabela mostra o peso relativo de cada etapa no calendário e o que sai dela.
| Etapa | O que acontece | Duração relativa | O que sai dela |
|---|---|---|---|
| Levantamento | POPs, roteadores, rota principal, nobreak e ponto de chegada | Curta, depende das respostas do provedor | Escopo por POP com o que fica no ar na queda |
| Desenho | Tipo de túnel, forma de troca, prioridade do tráfego e plano de volta | Curta a média, depende da aprovação | Documento de desenho aprovado por escrito |
| Instalação | Antena no mastro, cabo até o rack, energia no nobreak e túnel fechado | A mais variável: logística, mastro e entrega do kit | Túnel ativo e gerência alcançável pelo satélite |
| Roteamento | Rotas de reserva, limite de banda, ajuste de MTU e alertas | Uma janela de manutenção por POP | Rotas ativas e alertas aparecendo no painel |
| Queda simulada | Link principal desligado, troca medida e retorno conferido | Uma janela curta por POP | Relatório com tempos medidos e configuração final |
Os prazos em dias dependem da quantidade de POPs e da agenda do provedor [PREENCHER prazo típico por POP da Táquion Tech]. O que pesa no calendário é a instalação física e as janelas liberadas para mexer na rede.
Levantamento e desenho, antes de tocar na rede
As duas primeiras etapas acontecem no papel e com acesso só de leitura. A pergunta central do levantamento é o que precisa continuar funcionando quando o POP perde o caminho principal.
A resposta mais comum é gerência dos equipamentos, autenticação RADIUS e monitoramento, e cada item a mais muda o limite de banda e as regras do túnel.
No desenho entram três escolhas: o tipo de túnel (WireGuard, IPsec ou GRE protegido), a forma de trocar de caminho e o que acontece quando o link principal volta. O desenho também diz se o terminal segue com o roteador do fornecedor ou em modo bypass, ligado direto ao roteador do POP [CONFIRMAR no manual do fornecedor].
Instalação, roteamento e a janela de queda
As três últimas etapas mexem na rede, em janelas combinadas. Um detalhe da instalação decide se a reserva funciona: a rota até o IP do concentrador precisa sair sempre pela porta do satélite. Se ela seguir pela rota principal, o túnel cai junto com o link que deveria proteger.
Na queda simulada, o Especialista desliga a interface principal, mede quanto tempo a gerência fica fora, confere se os clientes do POP continuam autenticando e religa. O retorno também é cronometrado, porque uma volta mal feita derruba a rede pela segunda vez.
O que o provedor prepara e o que recebe no fim
O provedor prepara acesso, energia e o ponto de chegada do túnel, e recebe uma reserva provada com o link principal desligado. Quanto mais completo o preparo, menos janelas a integração consome.
Antes da primeira janela, confira se o provedor já tem
- Kit do satélite contratado direto com o fornecedor, com assinatura ativa e não pausada.
- Lugar com céu livre de obstrução, conferido no aplicativo do fornecedor antes de fixar o mastro.
- Tomada do terminal ligada ao mesmo nobreak que alimenta o roteador do POP.
- Roteador do POP com versão de sistema que aceita WireGuard ou IPsec.
- Equipamento com IP público e folga de processamento para receber os túneis.
- Acesso de administrador aos roteadores envolvidos, com usuário próprio para a integração.
- Uma janela de pouco tráfego por POP para a queda simulada.
Com cinco itens prontos, a integração é quase toda remota. Com menos de quatro, as primeiras janelas viram preparo da rede.
Na entrega, o provedor recebe quatro peças para não depender de quem fez a integração:
- Configuração comentada: túnel, rotas, limites e ajuste de MTU de cada POP, com o motivo de cada linha.
- Relatório da queda: tempo até a reserva assumir, tempo de retorno e o que passou pelo túnel durante o teste.
- Alertas testados: aviso de entrada e de saída da reserva no monitoramento, disparados durante a janela.
- Roteiro de teste: passo a passo para a equipe da casa repetir a queda simulada sozinha.
Seus POPs têm antena, mas não têm reserva provada?
Na integração de Starlink como contingência, um Especialista fecha o túnel, escreve as rotas de reserva e entrega o tempo de troca medido numa queda simulada.
Antena e assinatura ficam fora do trabalho de integração, e os fatores que mudam o valor do serviço estão no guia de quanto custa integração de Starlink como contingência.
Exemplo de como funciona integração de Starlink como contingência num POP de distrito
Um POP hipotético de distrito, ligado à sede por um único enlace de rádio, mostra a integração do pedido à entrega. Os endereços abaixo são de documentação e servem só para ilustrar.
- Pedido: o POP do distrito, com algumas centenas de assinantes, some do monitoramento toda vez que o rádio da sede cai.
- Levantamento: o roteador do POP é um MikroTik com RouterOS 7, o núcleo já roda OSPF e a borda da sede tem IP fixo com folga.
- Desenho: passam pela reserva a gerência, o RADIUS e o monitoramento, com limite de banda para o resto do tráfego.
- Instalação: a equipe do provedor fixa a antena com o roteiro, liga o terminal no nobreak e conecta a porta do satélite.
- Roteamento: o túnel sobe até 203.0.113.10, o OSPF passa a rodar dentro dele com custo alto e o alerta de entrada da reserva é cadastrado.
- Queda simulada: na janela de madrugada, a interface do rádio é desligada, a gerência volta pelo satélite [CONFIRMAR tempo medido no teste] e os clientes seguem autenticando.
- Entrega: o provedor recebe a configuração, o relatório com os tempos medidos e o roteiro para repetir o teste.
# túnel até o concentrador, aberto de dentro para fora
/interface wireguard add name=wg-reserva listen-port=13231
/interface wireguard peers add interface=wg-reserva public-key="CHAVE_DO_CONCENTRADOR" \
endpoint-address=203.0.113.10 endpoint-port=13231 \
allowed-address=0.0.0.0/0 persistent-keepalive=25s
/ip address add address=192.0.2.2/30 interface=wg-reserva
# rota fixa até o concentrador sempre pela porta do satélite
# (198.51.100.1 = gateway entregue pelo DHCP do terminal, só de exemplo)
/ip route add dst-address=203.0.113.10/32 gateway=198.51.100.1
# OSPF dentro do túnel com custo alto
/routing ospf interface-template add area=backbone interfaces=wg-reserva \
cost=1000 type=ptp
# ajuste de MSS para caber o cabeçalho do túnel
/ip firewall mangle add chain=forward out-interface=wg-reserva protocol=tcp \
tcp-flags=syn action=change-mss new-mss=clamp-to-pmtu passthrough=yesRepare na rota fixa até o concentrador: sem ela, o túnel segue pela rota principal, cai junto com ela e a queda simulada falha na primeira tentativa.
Erros que aparecem em cada etapa e como perceber cedo
Cada etapa tem um erro típico, e quase todos dão sinal antes da queda real para quem sabe onde olhar. A tabela liga o erro ao sintoma que ele produz.
| Etapa | Erro | Como se percebe |
|---|---|---|
| Levantamento | Esquecer o RADIUS no escopo da reserva | Na queda, a gerência volta, mas quem reconecta não autentica |
| Instalação | Obstrução parcial no campo de visão da antena | Microquedas no aplicativo e túnel renegociando várias vezes por dia |
| Instalação | Terminal fora do nobreak | Queda de energia apaga o rádio e a reserva ao mesmo tempo |
| Roteamento | Rota do concentrador seguindo pela rota principal | Túnel cai junto com o link principal no primeiro teste |
| Roteamento | MTU sem ajuste dentro do túnel | SSH abre, mas páginas de gerência e transferências travam no meio |
| Queda simulada | Testar só a ida e esquecer a volta | Quando o principal retorna, o tráfego oscila entre os dois caminhos |
A reserva que funciona e ninguém percebe
O erro mais traiçoeiro aparece quando tudo dá certo: o satélite assume, a gerência segue e ninguém nota que o link principal caiu. Dias depois, a reserva está carregando o POP sozinha e o rádio continua parado.
O alerta de entrada da reserva resolve isso. O guia de implantação de Prometheus mostra como montar um aviso para quando o tráfego começa a sair pelo túnel, e o monitoramento de rede mantém esse olho ligado no dia a dia.
Perguntas frequentes
A antena precisa ficar ligada ao roteador do fornecedor?
Não necessariamente. Muitos provedores usam o modo bypass, em que o roteador do fornecedor deixa de fazer NAT e o roteador do POP recebe o endereço direto [CONFIRMAR no manual do fornecedor]. Assim sai uma camada de NAT do caminho.
Dá para abrir o túnel pelo IPv6 do satélite?
Pode dar, porque o fornecedor entrega prefixo IPv6 em vários planos [CONFIRMAR nos termos do fornecedor]. Mesmo assim, o desenho costuma manter o túnel em IPv4 com keepalive, que atravessa o CGNAT de forma já testada.
Quem instala a antena num POP fora de Santa Catarina?
A equipe do próprio provedor, seguindo o roteiro de instalação, ou um técnico local. O túnel, as rotas e a queda simulada são feitos à distância, e a instalação com a equipe da Táquion Tech fica no litoral catarinense [CONFIRMAR área de atendimento].
Os assinantes do POP percebem quando o satélite assume?
Percebem que a navegação parou ou ficou limitada, porque a reserva leva gerência e autenticação, e não o tráfego de todos. O ganho é que o provedor enxerga o POP, sabe o que caiu e avisa os assinantes com informação certa.
Vários POPs podem usar o mesmo concentrador de túnel?
Podem, e esse é o desenho mais comum: cada POP abre o próprio túnel até o mesmo ponto com IP fixo, com endereços e chaves separados. O cuidado é a folga do concentrador numa queda que atinja vários POPs ao mesmo tempo.
Fontes
- RFC 6598, IANA-Reserved IPv4 Prefix for Shared Address Space: define a faixa 100.64.0.0/10 usada no CGNAT, o motivo de o túnel nascer no POP
- WireGuard, Quick Start: trecho sobre NAT e firewall, com o persistent keepalive de 25 segundos
- RFC 2328, OSPF Version 2: custo de interface e temporizadores hello e dead que definem o tempo de troca