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.

Em busca do NAS doméstico (quase) gratuito! - Parte 4 - Abrindo finalmente (ou não) as portas do roteador!

 Pessoal,

Meus pobremas se acabaram-se!! Ou não!

Finalmente consegui entender como abrir as portas do roteador.

No meu roteador da NET tem uma opção: NAT. É aqui que eu tenho que trabalhar. No roteador há três opções:

1 - Virtual Server - permite criar uma conexão que chega pela WAN (identificada pelo protocolo TCP/UDP e porta externa) para um endereço IP interno na LAN (rede local). Nesse serviço, é preciso especificar o IP de destino.

2 - Port Triggering - permite que uma aplicação no lado interno da LAN (rede local) possa acessar um serviço em rede externa por uma porta pré-determinada. Tive a impressão que é meio que o oposto do Virtual Server. Nesse serviço não é preciso especificar o IP interno, uma vez que ele é a fonte, não o destino.

3 - Host DMZ - o roteador vai encaminhar ao IP de destino todos os pacotes que chegarem via WAN. Ou seja, todas as portas estão abertas, mas apenas para determinado IP.

Ou seja, pelo que entendi, o Virtual Server libera que uma porta determinada receba um fluxo externo -> interno para o IP especificado da rede local. O Port Triggering libera que um IP especificado na rede local acesse um serviço externo (fluxo interno -> externo) por uma porta pré-selecionada. E a última opção, o Host DMZ, permite um fluxo externo-> interno para determinado IP especificado na rede local (tipo o Virtual Server), porém para qualquer porta que o serviço externo queira acessar na rede interna.

O complicado no meu caso é que eu tenho um roteador dentro da rede de outro roteador. Ou seja, o IP do primeiro roteador (da NET) gerado pelo DHCP é um e o IP gerado pelo segundo roteador (o Google Wifi) é outro. Ou seja, a NET especifica um IP para o Google Wifi e este distribui outros IPs via DHCP para a minha rede local.

Fiz um teste com o Transmission (programa para baixar Torrent no Mac). Criei um Virtual Server no roteador da NET, mas especifiquei o IP do Google Wifi. A porta do Transmission que estava fechada, foi aberta. Mas pelo que entendi, a porta X aberta no Google Wifi abriu a porta X de todos os IPs da rede local. Confere, produção?

Bom, essa não é a solução que eu procuro. Meu plano passou a ser outro: colocar o roteador da NET em bridge, ou seja, ele será apenas uma ponte do serviço externo da NET para o Google Wifi. Esse é quem definirá as portas a serem abertas, os endereços IP por DHCP para cada equipamento, etc.

Então foi isso que fiz: liguei o MacBook no roteador da NET por cabo (na porta 1), desativei o Wifi (eu tinha deixado o Wifi 5GHz ativado para poder acessar, caso precisasse mas não tinha nado ligado nessa rede) e mudei para modo Bridge. Instantaneamente a internet pelo roteador da NET acabou (passaria a ser apenas pelo Google Wifi na hora que eu ligasse ele no roteador da NET).

O próximo passo foi esse, ligar o Google Wifi no roteador da NET, na porta 1. A internet voltou e pronto, passo encerrado.

Depois resolvi dar uma olhada mais atenta nas configurações do Google Wifi, uma vez que ele é a única  barreira agora.

Primeira coisa: baixei o DNS Benchmark para ver qual DNS estava melhor por agora. Antes eu estava usando o DNS do Google (DNS primário 8.8.8.8 e secundário 8.8.4.4). Minha internet tinha tido uma queda razoável e eu estava atribuindo isso a alguma decisão da NET de reduzir a velocidade de todo mundo devido a quarentena. A velocidade contratada era de 100Mbps e estava rodando entre 30-50Mbps. Como o celular é da CLARO, essa velocidade contratada era dobrada para 200Mbps. Ou seja, 50 tá muito ruim...

Usando o DNS Benchmark, vi que a melhor opção seria o OpenDNS (208.67.220.222 e 208.67.222.220). Entrei nas configurações do Google Wifi e mudei o DNS. Resetado e operante!

Como tirei (acho que tirei, né?) o limite do roteador da NET e arrumei o DNS, fiz um speed test e tive essa surpresa!

Vários testes rodando nesta faixa de 100Mbps. Às vezes alguns vieram mais altos. Mas o recordista foi esse aqui, pelo MacBook Pro do lado do Google Wifi principal:

O upload não tá uma beleza, mas o Download ficou coisa linda de D'us!!!

Bom, a primeira coisa era colocar em bridge e arrumar as configurações do Google Wifi. A segunda coisa agora SERIA realizar a abertura de portas.

Entretanto, para minha alegria, passando por videos no YT sobre como fazer isso, vi um sujeito esbravejando para ninguém abrir portas de roteador por questão de segurança e, se quisesse acessar da internet os arquivos de rede local, que criasse uma VPN (!). Aí lembrei de uma vez que tentei instalar uma VPN e não tinha dado certo. Pensei: será que não tinha dado certo porque eu estava sob dois roteadores?

Vamos lá testar no próximo (e último) post dessa série.

Google Wifi (2)

Olá pessoal.

Vai aqui o relato do uso do Google Wifi por 2 meses, resumido em uma palavra: "Espetacular"!

Sério, meus problemas com internet acabaram. Estável e fácil de configurar. O problema de pegar bem em um cômodo da casa e não pegar em outro, agora é passado.

O Google Wifi é configurado apenas por app para iOS e Android (chupa Windows Phone). Se não tiver algum aparelho desses para configurar, vai sobrar. Tudo é configurado pelo app: atualizações de software, configurações diversas, senhas, tudo.

Achei que o aparelho seria meio capado, que seria mais simples, mas achei ele bem completo. Tem opções de testar a rede, medir velocidade da internet, testar a rede Mesh (ver se a interligação dos roteadores está ok), estabelecer prioridade de equipamentos, administrar usuários (senhas, limites de uso, configurações de sites permitidos / proibidos), além das tradicionais configurações de DNS, WAN e LAN, reserva de IP DHCP, encaminhamento de portas e coisas do gênero. Tudo bem claro e fácil de configurar, a la Google.

O equipamento é bem discreto. Pequeno, bonito, sem antenas visíveis, com estilo minimalista. Tem uma luz branca com intensidade variável (ajustável via app - se quiser deixar apagada no quarto, para não incomodar o sono, é possível).

Só estranhei um pouco o fato de ter apenas uma porta de saída ethernet. Resolvi aqui colocando um switch ethernet Gigabit com 5 portas.

Coisas da vida: enquanto estava escrevendo esse texto, dei uma olhada no site do Google Wifi e vi que ambas as portas podem ser usadas como LAN nos equipamentos secundários (o equipamento primário, que recebe a internet da operadora, vai precisar de uma porta para receber o sinal; a outra funciona como LAN)... Em todo caso, precisaria do switch de qualquer modo. 😒

Uma coisa que achei bem interessante é a possibilidade de acessar e configurar tudo pelo app mesmo estando fora da rede. Claro, é também arriscado porque se você perder o telefone (e ele não tiver nenhuma trava de segurança - senha, identificação digital ou qualquer outra), você PODE estar no sal... Mas por outro lado quebra um galhão, principalmente se a esposa ligar no meio da tarde reclamando que a internet caiu, tá lenta, etc, você entra no app e descobre qual o problema e até, eventualmente, reinicializa os roteadores. Bem prático.

Rede de 2,4 e 5 GHz? Tem. Rede para visitas? Tem também.

Ou seja, é um roteador bem completo, fácil configuração, com todas as praticidades e exigências do mercado doméstico atual. Vale a compra. Como ponto negativo, acho que deveria ser possível configurá-lo pelo computador.

Tem mais um ponto bem importante, pelo menos para mim. Já devo ter comentado que sou meio obsessivo-compulsivo por Back-up. Com o Google Wifi, uma vez que todos os computadores estão dentro da MESMA rede, mesmo que eu esteja com um computador na sala, consigo fazer o TimeMachine no meu MacMini, como já tinha explicado aqui e aqui.

Outra coisa que foi uma grata surpresa: minha impressora Wifi, uma Samsung M2070FW, que só aceita WPA - informação do Call Center da Samsung Brasil - (😓 porra, Samsung!), está funcionando na rede que está com senha WPA2. Não me perguntem como...

Até a próxima!

Google Wifi (1)

Olá Pessoal,

   Chegou aqui em casa, há umas 3 semanas, o Google Wifi.

   Antigamente eu utilizava um roteador ASUS RT-AC66U. Excelente roteador, sem nenhuma queixa. Amigável, completo, rápido. Havia comprado por ser AC, pela possibilidade de usar impressora e um HD conectados para acesso remoto e por ter porta Gigabit. Lembro que na época havia ficado em dúvida entre ele e o TimeCapsule da Apple e acabei optando por ele. O coitado passou por poucas e boas, tendo sobrevivido (quase ileso) ao ataque furioso da minha cachorra que mastigou suas antenas... Ficaram as marcas dos dentes nele, mas ele funcionava bem, com antenas novas, apesar de tudo.

   Infelizmente um dia ele morreu :( . Descobri que era, na verdade, o botão de power on/off que havia estragado. Assim, ele ficava constantemente desligado. Se eu apertasse e segurasse, ele funcionava. Acabei comprando um TP Link Archer C50 para substituí-lo mas, confesso, não rolou! Não havia percebido, mas o C50 não tem porta Gigabit, era bem mais instável, etc. Nunca gostei de TP Link, mas parece ser dos melhorzinhos que a gente acha por aqui no Brasil...

   Um dia acabei abrindo meu ASUS, peguei um clipe de metal, um palito de fósforo e fita isolante e, à la MacGyver, construí uma bomba atômica travei o botão em ON. Pronto, aposentei o TP Link (inclusive vou vender-lo no ML!) e voltei a usar o ASUS.

   Todas as configurações que havia feito no C50 para funcionamento dos backups via TM, endereços reservados de IP, enfim, tudo, descritos aqui, copiei pro ASUS e tudo funcionou perfeito.

   Entretanto uma coisa sempre me incomodava. Devido à disposição dos equipamentos aqui em casa, o roteador da NET (aquela inhaca) não pega no escritório (onde estão os computadores e impressora). A patroa não deixou eu colocar um roteador na sala ("só se ficar dentro do armário, escondido", ou seja, com o sinal limitado) e no escritório, onde eu coloquei, o sinal era péssimo na sala. Tentei por o mesmo nome nas duas redes e ficou pior, porque o computador às vezes se conectava no roteador longe e a internet ficava um lixo. Tentei nomes diferentes, conectar por cabo, modo bridge, repetidor, tudo! e nada de ficar bom.

   Há alguns meses, conversando com o pessoal da TI do hospital onde trabalho, fiquei conhecendo o Unifi, solução profissional para um problema que estávamos tendo com a nossa rede de Wifi no hospital. Este equipamento se baseia na tecnologia MESH para redes sem fio, que é uma evolução das redes comuns: vários (ou apenas um) roteadores são espalhados em uma área e compartilham uma rede (ou várias, se desejado); quando um equipamento entra na rede, o(s) roteador(es) detectam se ele está com o melhor sinal possível e, caso não esteja, desconectam o equipamento da rede e reconectam automaticamente no melhor sinal possível. Pena que é caro...

   Mas há 3 semanas fui em NY e vi vários equipamentos domésticos desses na Best Buy. Na faixa de 200 a 300 doletas o kit com 3 roteadores. Pensei: é agora! e comprei o da Google.

   O Google Wifi promete cobertura de até 200 metros quadrados. Cada um dos roteadores é um equipamento com um processador ARM quad-core, 512MB de ram e 4GB de memória flash, além de ser um roteador AC1200 com tecnologia 802.11s (MESH) e trabalhar com as frequências 2,4 e 5 GHz.

   Todos os ajustes são feitos através do aplicativo para Android ou iOS.

   Vou falar, nos próximos posts, da configuração e de alguns problemas que tive com ele.