Atualização periódica do DDNS DuckDNS via cron no Synology DSM

Este é um problema que provavelmente só eu tenho, com minha configuração peculiar. Mas de qualquer forma vou descreve-lo aqui, pois ele pode inspirar soluções similares para problemas similares.

Cenário

O cenário é o seguinte: eu tinha uma rede com dois roteadores, o ASUS RT-AC86U e o Peplink Balance One, ambos já descritos aqui no Skooter Blog. Por que dois? Porque o Balance One é excelente no balanceamento de carga, mas ruim no QoS, enquanto que o RT-AC86Ué ótimo no QoS, mas tem uma implementação um tanto buguenta de balanceador de carga, e com poucos recursos. E que pra piorar ainda anula o QoS ao ser usada.

O duplo NAT pode ser um problema em muitas situações, mas minhas aplicações tem funcionado perfeitamente. Apenas me certifico de usar UPnP no roteador mais interno (RT-AC86U) e de colocar o segundo em um modo 1:1, também chamado Fullcone, onde todas as portas são redirecionadas, como num DMZ, e as portas das conexões de saída não são trocadas.

Quem cuida do DDNS é o Peplink Balance One. Uso contas no DuckDNS, que é um excelente DNS dinâmico. É gratuito e não fica perturbando para revalidar a conta periodicamente, como o No-IP. Deixo um hostname diferente para cada conexão.

Isso funcionou bem por muitos anos, mas recentemente eu mudei do Vivo Internet Fixa (ADSL) para o Vivo Fibra (fibra óptica), e com isso minha linha telefônica também passou a vir pela fibra (na prática é um VoIP) e instalaram um ONT que já faz a função de roteador e também cuida do telefone, que é acessado por uma VLAN diferente, separado da conexão de Internet.

Logo após a instalação eu já passei o ONT (um Askey RTF3505VW-N1) para o modo bridge e o Peplink passou a fazer a conexão PPPoE. Ao mudar para o modo bridge há um aviso:  “Atenção: Alterando o modo de operação para bridge irá desativar os serviços de internet, telefonia e TV.  Isto também o impossibilitará de receber suporte e atualizações com melhorias.”, o qual eu ignorei.

E isso funcionou bem por um par de meses, mas um belo dia o identificador de chamadas do telefone deixou de funcionar, sem qualquer mudança de configuração. Contatei a Vivo, mas não conseguiram consertar remotamente. Mandaram um técnico que se limitou a trocar o ONT por outro do mesmo modelo, mas com as configurações padrões (modo router). Disseram que aconteceu algumas mudanças na rede VoIP e mudaram as configurações.

O fato é que com o ONT em modo router, a Vivo consegue acessa-lo e configura-lo remotamente. Até atualizações de firmware são possíveis. Aliás, eu percebi que o novo ONT veio com um firmware mais antigo. Veio com o BR_SV_s00.00_g000_R3505VWN1001_s19, sendo que o antigo tinha o BR_SV_g000_R3505VWN1001_s26. Liguei no 10315 e pedi uma atualização e o que eles fizeram remotamente foi colocar uma versão ainda mais antiga: BR_SV_s00.00_g000_R3505VWN1001_s15. Já tentei de toda forma obter o novo firmware, mas os robozinhos da Vivo nem sabem o que é isso. Já abri até uma reclamação na Anatel, mas os trapalhões transformaram-na num chamado de que a Internet não estava funcionando e mandaram técnicos sem avisar. Enfim, o suporte da Vivo é uma imensa piada e só serve para usuários leigos. Não há ninguém lá que realmente saiba qualquer coisa de como uma rede funciona. Mas isso é assunto para outro artigo.

Voltando ao ONTAcabei entendendo que para evitar ter de chamar técnicos cada vez que alguém na Vivo resolve mudar alguma configuração, o jeito é deixar o ONT como router mesmo, mantendo o “backdoor” para a Vivo fazer mudanças de configurações para refletirem as mudanças que fazem em sua rede. Não gosto muito desse acesso externo que não sei nas mãos de quem pode cair, mas é o inconveniente de depender desse tipo de serviço.

Minha configuração acabou ficando com um triplo NAT, e prejudicada pelo fato do ONT da Vivo não suportar NAT Loopback, o que impede o acesso local usando o endereço do DDNS. Esse é um dos motivos pelo qual eu quero o firmware mais recente, uma vez que o RTF3505VW-N1 suporta essa configuração, mas o firmware da Vivo (pelo menos os mais antigos) não a possuem. Nem mesmo na interface padrão (/padrao) com todas as opções.

O NAT triplo também pode ser contornado ativando a opção de NAT Fullcone. Um bônus de usar o RTF3505VW-N1 como roteador é que ele suporta IPv6, o que o Peplink Balance One até hoje não faz. Assim eu configuro os outros dois roteadores para IPv6 passthrough e posso usar IPv6 na minha rede.

Problema

Mas ao passar o IP público e o PPPoE para o RTF3505VW-N1, o Peplink Balance One não sabe mais quando o IP público muda. Ele até tem uma opção para obter o IP público quando ele recebe um IP privado, e assim ele atualiza o DDNS corretamente. Porém, ele não é capaz de detectar quando o IP público muda. Ele deveria ter uma opção para ficar verificando o IP público periodicamente, mas não tem. Já pedi o recurso para a Peplink, mas ainda não fui atendido.

O RTF3505VW-N1 suporta DDNS, mas só do DynDNS e do No-IP, os serviços que ficam perturbando o usuário do plano gratuito e obrigando uma reativação periódica. Não dá para usar o excelente DuckDNS. O terminal do RTF3505VW-N1 não é bash, é apenas um shell limitado com poucas opções.

Pensei então em deixar essa tarefa para o Synology DS918+. Dá para configurar o DuckDNS nele, via interface. O problema nesse caso é que o método que ele usa para pegar o IP externo quase sempre pega a conexão do segundo provedor, que de vez em quando atribui um IP privado, via CGNAT, que não me serve para nada. Eu precisava garantir que ele sempre pegasse o IP da Vivo.

Forçar atualização do DuckDNS sem fornecer o IP seria uma solução, pois essa atualização é feita via HTTP ou HTTPS, e quando o IP não é fornecido ele automaticamente detecta o IP que fez a conexão. No meu Peplink Balance One fiz regras para que conexões TCP com porta de destino 80 ou 443 (HTTP/HTTPS) usem sempre a conexão Vivo Fibra, evitando que o Netflix selecione a conexão mais lenta (15 Mbps vs 200 Mbps do Vivo Fibra), que não funcionaria bem com vídeos em 4K. Assim as atualizações sairiam sempre via Vivo Fibra, a menos que essa conexão estivesse indisponível.

Mas aí há outro problema: o mecanismo interno do Synology DSM só atualiza o IP quando ele percebe uma mudança e, como já mencionei, normalmente ele vai estar monitorando o IP da segunda conexão, pois a regra que deixo como padrão é usar a conexão que responde primeiro, e essa tende a ser o segundo provedor, que apesar de menos largura de banda, tem uma latência média menor que a do Vivo Fibra.

Solução

O jeito aqui foi apelar para uma solução via cron, que a cada 5 minutos chame o mecanismo de atualização do DuckDNS. Como a chamada é via HTTP ou HTTPS, ela sempre sai pela conexão do Vivo Fibra, a menos que ela esteja inativa.

Eis os passos que segui. Primeiramente é preciso abrir uma sessão SSH como o DS918+.

Dentro do meu home (~), criei um diretório ‘duckdns’ e entrei nele:

mkdir duckdns  
cd duckdns

Em seguida, criei um script ‘duck.sh’, usando o nano. Lembrando que o nano precisa ser instalado via pacote da comunidade no DSM. O vi está disponível nativamente, para quem preferir:

nano duck.sh

Dentro do script coloquei a seguinte instrução (tudo na mesma linha):

echo url="https://www.duckdns.org/update?domains=DOMINIO&token=TOKEN&ip=" | curl -k -o ~/duckdns/duck.log -K -

Troque DOMINIO e TOKEN pelos respectivos valores que podem ser obtidos no DuckDNS.

Salvei o script e deixei-o executável:

chmod 700 duck.sh

Então testei a execução do ‘duck.sh’:

./duck.sh

Com a execução é criado um arquivo ‘duck.log’. Vamos checa-lo:

cat duck.log

Dentro dele deve existir um ‘OK’. Se for um ‘KO’ ou outra resposta ocorreu algum erro.

Falta adicionar a tarefa no cron. Primeiro é preciso tornar-se root:

sudo -i

E editar o ‘/etc/crontab’:

nano /etc/crontab

E adicionar esta linha no final do arquivo:

*/5 * * * seuusuario ~/duckdns/duck.sh >/dev/null 2>&1

É preciso trocar ‘seuusuario’ pelo seu nome de usuário.

Em seguida salva-se o arquivo e reinicia-se o daemon do cron:

synoservice -restart crond

E já podemos sair do root:

exit

Se estiver tudo funcionando, um novo duck.log é gerado a cada 5 minutos.

Link permanente para este artigo: https://www.skooterblog.com/2019/04/04/atualizacao-periodica-do-ddns-duckdns-via-cron-no-synology-dsm/

Deixe um comentário

avatar
  Inscrever  
Notificar sobre
×