Adicione uma VPN de site ao lado do roteador do provedor sem cortar chamadas

A maioria dos sites pequenos já tem uma caixa que faz internet, DHCP e a linha de voz, e essa caixa não vai rodar o túnel do site. Adicionar um segundo gateway para o caminho privado funciona se você decidir quem é dono de cada rota antes de tocar num cabo. O risco real não é o túnel; é trocar em silêncio o equipamento que mantém os telefones registrados. Faça as cinco verificações em ordem e pare onde uma falhar.

Anote as funções que já funcionam

Registre o gateway padrão, o servidor DHCP, o resolvedor e o equipamento que tem o registro de voz do provedor. Neste exemplo o roteador do provedor é 10.50.0.1, o novo gateway ficará em 10.50.0.2 e o site remoto é 10.60.0.0/24. Nada nesse plano muda as três primeiras funções, e é exatamente esse o ponto. Depois confirme que a segunda caixa consegue mesmo terminar o túnel: veja o protocolo, a taxa de transferência esperada e se recebe atualizações de firmware ou de pacotes. Um equipamento com logotipo de VPN e sem caminho de atualização é carga, não acréscimo.

Se você não consegue dizer quem é dono do serviço de voz, pare. Trocar o roteador que tem um registro sem plano de reversão transforma um projeto de VPN em queda de telefone.

Dê ao novo gateway um endereço e uma tarefa

Reserve o endereço LAN dele fora do pool DHCP para que não se mova após reiniciar, e não lhe dê rota padrão própria a menos que queira que ele vire caminho de internet. A tarefa é manter o túnel e responder pelos prefixos remotos. Nos hosts da LAN que precisam alcançar o site remoto, prove qual rota usam agora e qual você quer depois da mudança; os mesmos dois comandos antes e depois são a prova mais barata.

ip route get 10.60.0.55
ip neigh show 10.50.0.2
traceroute -n 10.60.0.55

Se a consulta devolve o roteador do provedor e o traceroute morre na borda da internet, o host ainda não tem rota remota, o que é esperado. Se devolver algo inesperado, resolva isso primeiro, porque cada passo seguinte assume essa base.

Escolha quem é dono da rota do prefixo remoto

A opção A é o roteador do provedor: ele mantém uma rota estática para 10.60.0.0/24 apontando para o gateway, e cada host segue seu gateway padrão como antes. A opção B é por host: só as máquinas que precisam do site remoto recebem rota explícita por 10.50.0.2, e todo o resto fica intacto. A é mais limpa com muitos hosts, mas costuma exigir que o roteador do provedor aceite uma rota estática, o que alguns não fazem. B não precisa de cooperação do provedor, mas deixa a manutenção da configuração dos hosts com você, então serve para um conjunto pequeno de máquinas aprovadas.

Nos dois casos a direção de volta precisa existir. Se uma resposta remota chega ao gateway e o gateway a encaminha direto para um host da LAN, o tráfego pula o estado de firewall que o roteador do provedor mantinha no caminho de ida. Quando o gateway não é o roteador padrão da LAN, essa assimetria é uma decisão de projeto, não um defeito que se possa ignorar.

ip route add 10.60.0.0/24 via 10.50.0.2 dev eth0
ip route get 10.60.0.55 from 10.50.0.77

Torne a entrada permanente pelo dono da configuração do host, não por um script de login. Uma rota que só existe depois que alguém entra falhará na primeira vez que a máquina reiniciar por um motivo sem relação.

Prepare um ponto de entrada alcançável

O gateway precisa de um endereço que o site remoto consiga alcançar. Atrás do roteador do provedor isso significa redirecionamento de porta ou entrada DMZ, e os dois dependem de o provedor realmente entregar o tráfego. Um redirecionamento local não vence o NAT de nível de operadora do lado do provedor. Se o provedor não der um ponto alcançável, inverta a direção: deixe os dois sites iniciarem para um concentrador que você controla. É um projeto válido, mas acrescenta uma terceira dependência para encaminhamento, confiança e disponibilidade, e o DNS dinâmico não a substitui.

Confirme o redirecionamento com uma captura no gateway, não com um site que escaneia portas. Escâneres informam a porta fechada até o ouvinte ser associado, e um redirecionamento que nunca entrega tráfego parece de fora igual a uma porta fechada.

Aceite o serviço privado e a linha de voz juntos

Teste a operação pretendida a partir de um host da LAN, com DNS privado e as credenciais da própria aplicação. Um túnel roteado não faz a navegação remota parecer um segmento Ethernet local, então descoberta e resolução de nomes precisam de arranjos próprios.

curl -sS -o /dev/null -w '%{http_code}\n' https://files.example.net
ping -c 3 10.60.0.55

Depois confirme que o acesso normal à internet ainda funciona do mesmo host e que os telefones continuam registrados; essas duas verificações pegam uma mudança acidental da rota padrão, a forma mais comum de este projeto quebrar algo que nunca quis tocar. Termine com uma nota de recuperação escrita: qual equipamento tem qual função, os endereços reservados e como remover a rota do prefixo remoto num único passo. Um caminho privado que pode ser retirado de forma limpa vale mais do que um que só funciona hoje.