Dica - Atualizando DDNS com No-IP - Minha Transição para o Docker Oficial do No-IP

Olá, pessoal!

No meu setup de rede doméstica, sempre usei o serviço de DDNS da No-IP para manter meus servidores acessíveis via hostnames dinâmicos, como meuddns1.ddns.net e meuddns2.ddns.net.

Por algum tempo, usei o DUC (Dynamic Update Client ou Cliente de Atualização Dinâmica) do próprio No-IP, rodando no Linux, para fazer isso (falei sobre isso aqui). Entretanto, como estava ainda aprendendo sobre redes e pra que isso tudo servia, com alguma frequência eu apagava e reinstalava o Ubuntu Server onde isso ficava.

Depois comecei a fazer isso com o DuckDNS. Comentei sobre isso aqui. Mas o problema era sempre o mesmo. Hardware fraco, software em constante modificação.

Em 2023, quando comprei o meu Synology, um hardware robusto para ser o server base daqui de casa, resolvi atualizar o DNS via DuckDNS rodando em um container Docker do próprio DuckDNS. Nesse post aqui, falei como fiz isso e comentei que o No-IP não tinha um container Docker para fazer isso, ao contrário do DuckDNS. Mostrei inclusive como era possível usar um container não oficial (aanousakis/no-ip), o único que encontrei, para atualizar meu IP público no No-IP.

As vantagens em usar um Docker ao contrário de uma DUC (um programa dedicado para isso) são: a economia de recursos; aprendizado; simplicidade do processo.

Nesses dois anos, não tive problemas como esse container. Porém, há alguns dias, comecei a ter problemas com ele, incluindo erros como "database is locked", e decidi migrar para a imagem oficial do No-IP (noipcom/noip-duc) que eu, até então, nem sabia que tinha sido lançado. Neste post, vou compartilhar por que fiz essa mudança, como funciona a nova DDNS Key da No-IP, e como configurei o novo docker-compose.yml para gerenciar dois hostnames no meu Portainer.

Por que abandonar o velho Docker?

O contêiner aanousakis/no-ip era simples e funcional, mas começou a apresentar instabilidades. O erro mais comum que encontrei foi:

failed to create task for container: failed to

initialize logging driver: database is locked

Esse problema sugeria conflitos no acesso a arquivos de configuração, possivelmente devido à falta de um volume persistente ou permissões inadequadas. Além disso, como era uma imagem não oficial, não havia garantia de atualizações regulares ou suporte para as mudanças recentes no sistema da No-IP, como a introdução da DDNS Key. Resolvi buscar uma solução mais robusta e oficial, que me levasse à nova imagem noipcom/noip-duc, mantida pela própria No-IP.

A novidade da DDNS Key

Recentemente, a No-IP introduziu as DDNS Keys, uma alternativa mais segura às credenciais tradicionais de login (e-mail e senha). Com a DDNS Key, você gera um par de username e senha específicos para seus hostnames no painel da No-IP (my.noip.com). Cada chave é vinculada a um ou mais hostnames, permitindo atualizações seguras sem expor sua conta principal.

Para criar uma DDNS Key:

1. Acesse o painel da No-IP.
2. Vá para a seção de DDNS Keys.
3. Crie uma nova chave, associando-a aos seus hostnames.
4. Anote o username e a senha gerados, que serão usados no contêiner Docker.

A grande vantagem da DDNS Key é a segurança: se a chave for comprometida, você pode revogá-la sem afetar sua conta No-IP. Além disso, ela é compatível com a nova imagem oficial, que usa o hostname all.ddnskey.com para atualizações via DDNS Key.

Configurando o novo Docker oficial

A imagem noipcom/noip-duc é mantida pela No-IP e está hospedada no GitHub Container Registry (ghcr.io/noipcom/noip-duc). Ela é leve, confiável e suporta as DDNS Keys nativamente. Como eu gerencio dois hostnames com chaves diferentes, configurei dois serviços no mesmo stack do Portainer, cada um com sua própria DDNS Key e volume persistente no meu HD externo (/volume).

Aqui está o docker-compose.yml final que estou usando:

version: '3.9'
services:
  noip-duc-1:
    image: ghcr.io/noipcom/noip-duc:latest
    container_name: noip-duc-1
    environment:
      - NOIP_USERNAME=<username_do_ddnskey_não_é_do_NoIP>
      - NOIP_PASSWORD=<senha_do_ddnskey_não_é_do_NoIP>
      - NOIP_HOSTNAMES=<seuddns.ddns.net
      - INTERVAL=5
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /volume/docker/noip/noip-data-1:/config
    restart: unless-stopped

  noip-duc-2:
    image: ghcr.io/noipcom/noip-duc:latest
    container_name: noip-duc-2
    environment:
      - NOIP_USERNAME=<username_do_outro_ddnskey_não_é_do_NoIP>
      - NOIP_PASSWORD=<senha_do_outro_ddnskey_não_é_do_NoIP>
      - NOIP_HOSTNAMES=<seuoutroddns.ddns.net
      - INTERVAL=5
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /volume/docker/noip/noip-data-2:/config
    restart: unless-stopped

Explicando o docker-compose.yml

• Imagem: Uso a ghcr.io/noipcom/noip-duc:latest para garantir a versão mais recente.
• Contêineres: Criei dois serviços (noip-duc-1 e noip-duc-2) para gerenciar os meus DDNS do NoIP separadamente, já que optei por que cada um tivesse sua própria DDNS Key.
• Variáveis de ambiente:
  • NOIP_USERNAME e NOIP_PASSWORD: As credenciais da DDNS Key para cada hostname.
  • NOIP_HOSTNAMES: O hostname específico que cada contêiner atualiza.
  • INTERVAL: Configurado para 5 minutos, definindo a frequência de verificação do IP.
• Volumes:
  • /etc/localtime:/etc/localtime:ro: Sincroniza o fuso horário do host.
  • /volume/docker/noip/noip-data-1:/config e noip-data-2: Diretórios no meu HD externo para persistir configurações, evitando erros como o "database is locked".
• Restart policy: unless-stopped garante que os contêineres reiniciem automaticamente, exceto se eu os parar manualmente.

Passos para implantar

1. Criei os diretórios no HD externo (mas se você tiver acesso pelo Windows ou Mac, pode simplesmente criar a pasta sem precisar de fazer isso):

   sudo mkdir -p /volume3/docker/noip/noip-data-1 /volume3/docker/noip/noip-data-2
   sudo chmod 700 /volume3/docker/noip/noip-data-1 /volume3/docker/noip/noip-data-2
   sudo chown 1000:1000 /volume3/docker/noip/noip-data-1 /volume3/docker/noip/noip-data-2

2. Salvei o docker-compose.yml em /volume/docker/noip.
3. Implantei no Portainer:
   • Acessei Stacks > Add stack.
   • Colei o conteúdo do docker-compose.yml no Web editor.
   • Cliquei em Deploy the stack.
4. Verifiquei os logs:

   docker logs noip-duc-1
   docker logs noip-duc-2

   Os logs mostraram mensagens como [INFO noip_duc::observer] update successful, confirmando que os IPs estavam atualizados.

Solucionando problemas iniciais

Durante a configuração, enfrentei alguns desafios:

• Erro de variável: Inicialmente, usei EMAIL_PASSWORD em vez de NOIP_PASSWORD, o que causou um erro de "missing required argument --password". Corrigir para NOIP_PASSWORD resolveu.
• Lentidão nos logs: O Portainer demorava para carregar os logs, mas após a correção da configuração, o problema desapareceu.
• Volume inexistente: Tive que criar manualmente os diretórios /volume/docker/noip/noip-data-1 e noip-data-2 para evitar erros de "bind mount failed".

Resultado final

Com o novo setup, meus hostnames estão atualizando o IP daqui de casa sem falhas. Você pode testar dando um < ping>:

ping meuddns1.ddns.net
ping meuddns2.ddns.net

Ambos responderam com latência baixa (~0.2 ms), confirmando que tudo está funcionando. No painel da No-IP, os hostnames estão associados ao IP correto, e os logs dos contêineres mostram atualizações regulares a cada 5 minutos.

A migração para a imagem oficial noipcom/noip-duc foi um grande acerto. A DDNS Key trouxe mais segurança, e o uso de volumes persistentes no meu HD externo eliminou os erros de "database is locked". Se você também usa o No-IP para DDNS, recomendo experimentar a imagem oficial e configurar a DDNS Key.

O DuckDNS tem várias opções de atualização, bem mais flexíveis que como o No-IP. Eu optei por fazer os dois para poder ter DDNSs distintos para serviços distintos.

Por hoje é isso, pessoal!

Tutorial: Instalar DUC do No-IP e DuckDNS no Docker do Synology

Pessoal,

Uso o DDNS do No-IP para algumas atualizações. Como já falei algumas vezes, como o meu IP público é dinâmico, preciso forneceu uma atualização frequente ao No-IP (e também ao DuckDNS) para eles saberem para onde apontar para o meu IP.

Para o DuckDNS, é fácil. Vá ao Portainer -> Stack e crie um novo Stack:

version: "2.1"
services:
  duckdns:
    image: lscr.io/linuxserver/duckdns:latest
    container_name: duckdns
    environment:
      - TZ=America/Sao_Paulo
      - SUBDOMAINS=<seu subdomain>.duckdns.org
      - TOKEN=<seu token>
    restart: always

Coloque o seu subdomínio e o seu token e pronto!

Já para o No-IP, não existe um container novo para isso, muito menos um do No-IP. Eles preferem que você instale um pequeno programa que fará isso.

Para fazer pelo Docker, vou usar essa imagem: aanousakis/no-ip. Ela também é por linha de comando, mas é bem simples.

Abra o Terminal / Putty e digite:

# docker container run -d -e USERNAME=user1 -e PASSWORD=123 -e "DOMAINS=domain1.ddns.net" -e INTERVAL=5 aanousakis/no-ip

Lembre-se apenas de trocar os dados e colocar seu username e senha do No-IP, além do nome do subdomínio. Detalhe: o username não é o email do cadastro do login, ok?

Pronto! Melhor esses processos rodarem em Docker do que ter que gastar muito recurso em uma VM só pra isso!

É isso, pessoa!

Instalei o PROXMOX!

Pessoal,

Grandes mudanças aqui.

Comprei  um HD de 8TB e, junto com dois de 4 TB que eu já tinha e um pequeno de 1TB, resolvi instalar o Proxmox e reorganizar todo o meu servidor.

O Proxmox é um ambiente de virtualização, ou seja, ele não é um NAS. Ao contrário, é preciso criar uma VM nele e instalar algum NAS. No caso, vou voltar a usar o FreeNAS (agora TrueNAS).

A vantagem do Proxmox para mim será criar as minhas VMs independente do NAS. O NAS vai ficar para rodar backups e outras coisas, inclusive uma VM com Ubuntu e alguns dockers por esse Ubuntu.

A instalação do Proxmox é bem simples e vai ficar no HD de 500GB que está na máquina. Depois de baixar a ISO no site do Proxmox e gravar um pendrive bootável com a ISO usando o Balena Etcher, coloquei no computador, dei boot e fui seguindo as instruções:

(Escolha uma boa senha aqui: é a senha do root do Proxmox)

A instalação é bem rápida, uns 5 minutos. Depois disso, ela mostra um resumo para você saber qual página vai acessar a interface web do Proxmox:

Aqui no meu roteador, esse é o endereço padrão e já previamente fixado para esta máquina. Veja aqui como fixar o IP da sua máquina, pois isso é fundamentar para o Proxmox e a instalação do NAS.

Agora vamos entrar na interface web do Proxmox. No Mac (não sei outros sistemas, mas imagino que seja a mesma coisa para qualquer sistema e qualquer navegador), vai dar um erro informando que a página não é segura. Vá em frente, é assim mesmo:

("Olá, eu sou o Proxmox!")

Digite "root" para usuário e a senha que você escolheu lá atrás.

Essa aí em cima é a tela inicial do Proxmox. Não tem nada (óbvio, acabei de instalar), mas é onde irão ficar as VM que você criar.

Como é um Debian, a primeira coisa que eu gosto de fazer é atualizar todo o Debian (veja aqui como). Não apareceu na foto, mas tem um botão escrito "Shell" à direita da tela. Clique lá para abrir o Shell do Proxmox e vamos em frente para atualizar tudo (lembre-se que você estará como root, então não será preciso o "sudo").

Feito isso, vamos começar a brincadeira.

O Proxmox faz o download da ISO do sistema que você deseja instalar na VM e vai mantendo tudo organizado. Gostei disso. Para fazer isso, vá em "Datacenter -> local (pve) -> ISO Images" e faça o download da imagem (entrei no site do Ubuntu, downloads, Ubuntu Server LTS e peguei o link para baixar - o Proxmox faz esse download). Essa imagem, no meu caso, será armazenada no HD de 500GB onde está instalado o Proxmox.

Baixada a imagem, vá em Criar VM (à direita da tela) e siga o passo a passo. É realmente muito fácil.

Clicando em "Console", você vê, via VNC, a sua VM. Muito fácil.

Após instalar o Ubuntu Server, entre nesse post aqui para ver o básico do básico que é necessário instalar para o Ubuntu funcionar bem (atualizações, GCC, Net-Tools, VPN, No-IP DUC).

Bom, por hoje é só (já são 3h da madrugada).

Amanhã eu crio a VM com o NAS e mostro para vocês!

Dica: Básico do básico para o Ubuntu Server funcionar.

Pessoal,

Mais um post para lembrar apenas.

Após instalar o Ubuntu Server, dê os comandos para atualizar:

  sudo apt-get update

  sudo apt-get upgrade

  sudo apt install build-essential (para instalar o GCC)

  sudo apt install net-tools

  sudo apt autoremove

Para instalar o DUC do No-IP e o PiVPN, veja aqui.

Outra coisa interessante a ser feito após a instalação desses "essenciais", é correr uns comandos para apagar o que não for mais útil da instalação (falei disso aqui). Mas basicamente são esses 3 aqui:

   sudo apt-get autoremove

   sudo apt-get autoclean

   sudo apt-get clean

Esse post é só isso mesmo.

* Atualização em 2025: se você estiver usando o Ubuntu Server em uma VM no Proxmox, pode querer instalar o QEMU Guest Agent para melhorar a integração com o Proxmox. Para isso, use o comando:

sudo apt install qemu-guest-agent -y

E verifique se está ativo com:

systemctl status qemu-guest-agent

No Proxmox, confirme que o QEMU Guest Agent está habilitado na aba Options da VM.

Pronto, atualizado!

NAS Doméstico - FreeNAS

 Pessoal,

Só para atualizar aqui o NAS.

Backup:

Coloquei o Carbon Copy Cloner para fazer os backups para o NAS. Foi a maneira que encontrei mais fácil de efetuar os backups. Interessante que enquanto usava o WD MyCloud com destino de backup, diversos erros ocorriam. Com o NAS, o processo AGORA está liso!

Disse "AGORA" porque o primeiro backup completo foi dureza. Depois de algum tempo, o sistema ficava offline, o disco do NAS sumia da rede e o backup não era concluído. Gastei uns dois dias para cada backup que fazia. Depois disso, não tive mais erros com o backup.

Mídias:

Instalei o PlexMediaServer como plugin do NAS. É meio chato: criei um usuário "PlexMedia", montado em /mnt/JBCNAS/iocage/jails/PlexMediaServer/root/media/plex. Dentro de Jails, no menu inicial do NAS, direcionei uma subpasta dentro da minha pasta de mídias no pool para uma subpasta do PlexMediaServer:

Depois instalei o aplicativo do Plex no celular, iPad, AppleTV e TV. Pronto: todos eles encontraram o servidor na rede local e começaram a passar as mídias.

Repararam que eu disse "rede local"? Para "streamar" para a internet, o Plex exige que você seja assinante do PlexPass. Se você, assim como eu, tiver uma VPN (veja aqui), basta entrar na VPN e acessar o Plex "localmente)!

Usei principalmente esse vídeo aqui como guia para instalar o PlexMediaServer.

Time Machine:

Estou utilizando o NAS para fazer backup via Time Machine também. Dentro do meu pool, criei um dataset com o nome Time Machine e compartilhei na rede como SMB. Até tentei compartilhar com AFP (Apple File Protocol), mas não conseguia conectar os Macs nele. Com SMB, foi sem problema e vou deixar assim porque está funcionando e está bom (é como diz o velho ditado: "o ótimo é inimigo do bom")!

Próximos passos: instalar o NextCloud no NAS, ver se vou manter o PiVPN no RP ou se ele vai para o NAS e instalar o PiHole no RP. Outra possibilidade é instalar o Ubuntu Server em uma VM no NAS e rodar o PiHole e PiVPN nesta VM, além do aplicativo do NoIP!

Atualização:

Acabei de descobrir que o meu PC véio não tem suporte para criação de VM. Assim, como já tenho o RP rodando o PiVPN e o aplicativo do NoIP (expliquei tudo isso aqui, lá no meio do post; leiam que vale a pena), vou colocar o PiHole no RP também. Explicarei isso no próximo post.

É isso por enquanto.

Em busca do NAS doméstico (quase) gratuito! - Parte 5 - VPN

Pessoal,

Vou dar continuidade ao desenvolvimento do meu NAS doméstico (quase) gratuito.

Um ponto que sempre pegou para mim, como já coloquei em posts anteriores, é a necessidade de acessar os dados do meu NAS (e consequentemente da minha rede doméstica) de fora de casa.

Ora, ter os dados apenas dentro de casa não resolve muito. Um NAS que se prese tem que não apenas gerenciar o armazenamento de dados mas também permitir seu acesso no momento oportuno.

Então, como diria Jack, vamos por partes: primeira, obter um acesso externo de um modo seguro à minha rede local; segundo, resolver um NAS que atenda as necessidades de confiabilidade e acesso tanto por computador quanto por dispositivo móvel.

Acesso a rede doméstica

Como falei aqui, descobri a duras penas que eu tinha um grande problema com os roteadores.

O roteador da NET estava habilitado a toda e gerava um IP por DHCP para o Google Wifi que gerava os IPs também por DHCP para os equipamentos na rede local. Ou seja, abrir uma porta para um IP local seria, além de difícil, arriscado. Para abrir uma porta, teria que abrir primeiro no router da NET e direcionar para o IP do Google Wifi. Assim, pela lógica, essa porta estaria aberta para todos os equipamentos da rede interna,  independente do IP delas ou se houvesse ou não necessidade para isso. Mas nem isso funcionava.

Assim, coloquei o router da NET em bridge (já falei aqui) e fui estudar um pouco sobre NAT (Network Address Translation), Virtual Server, Port Triggering e DMZ Host.

Mas tudo isso mudou quando relembrei de uma vez que tentei, sem sucesso, criar uma VPN. Na época nem sabia bem para que isso poderia me ajudar, acho que fui instalar para aprender mesmo, sem utilidade prática. Não seria uma VPN para acessar um conteúdo no exterior (falei disso bem no começo do blog, lá em 2010!). Meu objetivo aqui é ligar dois pontos seguros: minha rede local e meu notebook ou celular. Sei onde está a entrada e saída dos dados.

Na época, quando tentei fazer essa VPN, utilizei o PiVPN, fazendo do RP3B+ um servidor de VPN. Não funcionou e hoje suspeito que seja por conflito de IP dos roteadores. Como bypassei o da NET colocando ele em bridge, espero que dê certo desta vez.

Antes de tudo, fiz uma instalação limpa no cartão do RP com o Raspberry Pi OS. Depois instalei o OpenMediaVault (veja como instalar facilmente aqui). O objetivo era ter um HD na rede para testes e saber se a VPN funcionaria bem mesmo. Tudo pronto, vamos à VPN em si.

Optei pelo PiVPN. O processo é fácil, tá bem explicado e tem vários tutoriais na Internet. Gostei muito deste vídeo do Lon Seidman no Lon.TV, um dos melhores do YouTube.

Uma das vantagens do PiVPN é a facilidade para instalação. Outra é que o processo já cria a chave para criptografia durante a instalação.

Para iniciar a instalação, abra o Console do RP (ou Putty ou Terminal, se estiver usando SSH) e digite:

    sudo curl -L https://install.pivpn.io | bash

A instalação vai começar e algumas telas serão mostradas:

Um ponto importante é que, como todo servidor, o PiVPN necessita ter um IP Estático. Além disso, o cliente VPN (o celular ou o notebook) precisará saber para qual IP válido (o IP fornecido pelo provedor, ISP) ele deverá mandar a requisição. Vou falar disso daqui a pouco.

Definir um IP fixo na rede doméstica é fácil. Entre no seu roteador e procure por reservar de IP, reserva de endereços no DHCP ou algo assim. Cada router tem um nome pra isso. Aqui o meu já estava fixado (o RP, pela conexão ethernet, sempre tem esse IP).

Escolha como você vai se conectar, cabo ou wifi. O recomendado para um server sempre é cabo devido a estabilidade. Assim, escolhi eth0.

Confirme se o IP está certo e vamos em frente.

Agora o PiVPN deseja saber onde será guardada as informações do OVPN. Como só tenho um usuário no RP, as configurações serão guardadas em /home/pi/ovpns. Nesta pasta ficará guardada a chave de criptografia que será transferida para o cliente posteriormente.

O sistema agora perguntará se desejamos permitir a instalação automática das atualizações de segurança. Por motivos óbvios, a resposta só pode ser SIM.

Agora escolheremos o protocolo que o PiVPN utilizará, UDP ou TCP (veja a diferença aqui, muito bem explicado) e a porta que deverá ser utilizada. Por padrão o PiVPN escolhe o protocolo UDP e a porta 1194. Eu optei por manter o protocolo UDP, mas troquei a porta por segurança (existem portas que não devem ser utilizadas; o sistema tem 65.536 portas e algumas -veja aqui e aqui devem ser evitadas porque normalmente são utilizadas).

Nesse momento, você deverá retornar ao seu router e reservar, no IP fixado para o RP, qual a porta escolhida para receber o fluxo externo, a porta do fluxo interno (geralmente a mesma) e registrar qual o protocolo deseja utilizar (TCP, UDP ou ambos).

Agora será perguntado sobre nível de encriptação das chaves. Escolha 2048 ou 4096. É a segurança de seus dados e da sua rede doméstica que está em jogo. Jogue para ganhar.

Agora vamos ter mais um pouco de teoria para continuar o processo.

As operadoras fornecem um IP para cada computador conectado na rede. Esse IP é conhecido como IP válido ou IP público (IP atribuído pelo órgão regulador). Para saber se um IP é válido ou não, é só saber o seguinte:

    -> 10.x.x.x

    -> de 172.16.x.x a 172.32.x.x

    -> 192.168.x.x

Todos os IPs que estejam nessa regra de cima NÃO são IPs válidos, servem apenas para uso em redes locais. Fora isso, são IPs válidos (e distribuídos pela sua ISP ou por um órgão regulador).

Os IPs geralmente estão distribuídos na versão 4 (famoso IPv4). Esse endereços têm 32 bits de comprimento e existem 2ˆ32 endereços IPv4 (cerca de 4,3 bilhões de endereços). Com o aumento dos dispositivos conectados, esses endereços são insuficiente. Assim, existem duas saídas: a melhor para o usuário e a melhor para a operadora.

A melhor saída para o usuário é a adoção do IPv6. Aqui os endereços têm 128bits e existem 2ˆ128 endereços IPv6 (cerca de 340 duodecilhões de endereços, 340 seguido de 12 zeros...). Assim, cada dispositivo na rede teria seu endereço fixo (um IP válido para cada equipamento na rede).

MAS (sempre tem um mas...) nem todos os servidores e roteadores suportam IPv6. Tirando a questão de bugs e outros problemas que ainda podem existir. Como sempre, vale a regra do "MAS": nada depois de um MAS pode ser bom!

As operadoras resolveram isso de outra forma: CGNAT. Resumidamente, com a escassez de endereços IPv4 (tem mais equipamento na rede que endereço), eles distribuem os endereços entre que está ativo e podem trocar seu endereço a qualquer momento.

O que isso tem a ver com a nossa VPN? Tudo! O cliente precisa saber qual IP válido ele deve procurar para fazer a requisição do dado. Ora, se o seu IP válido muda frequentemente, como você pode resolver isso? Ou pagando para ter um IP válido fixo ou utilizado um serviço de Dynamic DNS (DDNS, No-IP, etc).

Esses serviços de DDNS fazem basicamente uma atualização do seu IP válido e o registram em um sistema de domínios (DNS). Ou seja, pegam o seu 189.17.48.190 que a sua ISP atribuiu para você e o registram como fulano.ddns.net. Assim, quem digitar isso vai ser encaminhado para o IP atribuído a esse DNS. Esses serviços geralmente tem um aplicativo que faz automaticamente essa atualização. Alguns roteadores fazem essa atualização também (MAS, sempre o MAS, Google Wifi não tem esse serviço de DDNS...).

Assim, entrei no No-IP, fiz o cadastro e escolhi o nome. Baixei o aplicativo deles para atualização pro Mac, mas como estava tudo rodando no Pi, achei melhor baixar pra lá e deixar o RP fazendo tudo isso. Basicamente fiz isso:

    sudo su #para ficar com super usuário

    cd /usr/local/src

    wget http://www.no-ip.com/client/linux/noip-duc-linux.tar.gz

    tar xzf noip-duc-linux.tar.gz

    cd noip-2.1.9-1

    make

    make install

Agora o programa vai pedir o nome de usuário ou email registrado no No-IP.com, a senha, vai pedir pra você escolher qual nome deseja atualizar e com qual frequência (o padrão é 30 minutos, mas eu escolhi 5 minutos). Depois digite, ainda com SU:

    /usr/local/bin/noip2

Pronto. Agora já temos um DNS ligado ao nosso IP válido e continuamente atualizado.

O próximo passo agora no PiVPN é escolher se quer utilizar o IP público (ou válido) ou escolher um DNS. Obviamente vamos escolher entrar com DNS e colocar o DNS que acabamos de criar no No-IP (lembre-se, é só no DNS, sem "http"):

Agora somos perguntados sobre qual serviço de DNS desejamos usar. Escolhi o Google, mas o OpenDNS também é bem rápido. Falei um pouco disso no final deste post.

Bom, a configuração acaba aqui. Agora falta apenas entrar com os usuários (clientes) da VPN.

Dê um

    pivpn add

e digite o que é pedido: nome do cliente, senha e senha novamente. Nunca é demais reforçar que a senha deve ser boa, né?

Agora, se tudo deu certo, a chave para o cliente foi criada e deverá estar em /home/pi/ovpns. Essa chave deve ser enviada para o cliente. No meu caso, como o cliente sou eu mesmo (será meu notebook, iPad e iPhone), posso passar por três formas: por email (pior opção, insegura), pendrive (tem que lembrar de apagar depois) ou por um serviço de nuvem.

Não se esqueça de liberar essa porta UDP no roteador, em Port Management. Acrescente a regra com a porta escolhida, o padrão de comunicação (UDP, TCP ou ambos) e confira se o MAC Address do servidor é o mesmo que você está liberando.

No Mac instalei o Tunnelblick para acessar a VPN. Arrastei a chave para o ícone do programa, digitei o usuário e a senha e pronto. Fica um pequeno ícone na barra superior e aí é só clicar lá e começar a navegação via VPN.

No iPad e iPhone o processo é um pouco diferente. Para ambos existe aplicativo da OpenVPN que deve ser baixado na AppStore. Depois de baixado, conecte o iDevice ao computador, abra o Finder, selecione seu dispositivo e, à direita, escolha "Arquivos". A seguir arraste a chave para o aplicativo OpenVPN e termine de configurar no iDevice.

Bom, o próximo passo é efetivamente criar um bom NAS.

Utilizando a VPN, tenho a segurança agora de acessar o NAS de fora da rede, qualquer que seja o NAS escolhido.

Pode ser o OpenMediaVault (e ele ficaria apenas para arquivos e/ou TimeMachine). Pode ser o NextCloud (que tem aplicativos que podem ser utilizados nos dispositivos móveis) ou tentar o XPEnology, meu sonho de consumo.

Para o XPEnology, precisarei de uma máquina boa, que permita virtualização.

Lembram do MacMini que morreu no começo do ano? Pois é, descobri uma empresa aqui em BH que tentará recuperar a placa lógica dele. Se der certo, ótimo. Se não der, é pensar no plano B.

Só que esse post acaba por aqui. Obrigado.