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.

0 0 votos
Article Rating
(Visitado 47 vezes, 1 visitas hoje)

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

Inscrever
Notificar sobre
guest

9 Comentários
mais velhos
mais novos mais votados
Inline Feedbacks
Ver todos os comentários
Dan

Opa! Você consegue fazer port forwarding no RTF3505VW-N1? Precisa de bridge?

Dan

Pois então, ontem eu passei o dia inteiro vendo a questão de fazer port forwarding nesse aparelho. No começo, parecia que nada que eu fazia adiantava, as portas não respondiam independente da porta que eu desse forward. Mexendo no firewall, na parte de encaminhamento de portas e também no virtual server do /padrao. Agora uma coisa esquisita, mesmo sem nenhuma porta encaminhada no aparelho, muitas portas tão respondendo testes externos. Não tou com dmz nem nada ativado. Tou com full cone ativado, mas pelo que eu entendi essa configuração só tem a ver com portas que tão encaminhadas. O que será que tá acontecendo?

Dan

É a Vivo mesmo, com o firmware BR_SV_s00.00_g000_R3505VWN1001_s19.

Encaminhamento com pacote de origem externa era bem o que eu queria, queria hospedar alguns arquivos pra estudo. Acho estranho o encaminhamento estar funcionando externamente sem eu ter encaminhado nenhuma porta e nem ativado dmz, nem nada. No aparelho, do jeito que tão as configs, não era pra ele encaminhar nenhuma porta, eu acho. Mas simplesmente ta encaminhando, bastante portas até. Tenho mais de um dispositivo conectado na rede.

Se eu coloco o RTF3505VW-N1 como modem em bridge com outro roteador eu ainda preciso fazer logon no PPPoE no outro roteador? Não posso ligar direto no pc e logar pelo windows mesmo pq preciso da wifi.

Obrigadão por responder.

Dan

Sim, tava testando com o Simple Port Tester no modo tcp. Deu até pra acessar uns sites que fiz com o Ms IIS. Mas é possível meu computador abrir alguma porta via UPnP no roteador sem a configuração aparecer?

Rick

You might consider two changes to your code to disperse your requests so you don’t get 502 errors since all examples are firing at 5 minute intervals.

First, to CRON, change */5 to n-59/5 where n= 1 or 2 or 3 or 4 or 5, pick randomly. This will offset your interval by the value of “n” so you are not using the same minute as everyone else. Example, 3-59/5 will fire at 3, 8, 12, 17… as opposed to 5, 10, 15, 20 … like everyone else. This spreads everyone into 5 groups.

Second, add sleep $((RANDOM % 60)) to your duck.sh before your CURL line pauas your DuckDNS call 0-60 second which will use to entire range seconds in the minute you pick for your CRON task to fire.

This means that all users will be spread out through 300 possible slots in a five minute interval and make a 502: Bad Gateway error far less likely.

9
0
Gostaríamos de saber o que você pensa, deixe seu comentáriox