// // Chicletes para o Cérebro: NextCloud
Mostrando postagens com marcador NextCloud. Mostrar todas as postagens
Mostrando postagens com marcador NextCloud. Mostrar todas as postagens

domingo, 24 de julho de 2022

Dica: Acessando remotamente o NextCloud sem precisar abrir portas do roteador!

Pessoal,


Descobri um serviço bem interessante para conseguir acessar remotamente um serviço rodando em nosso servidor sem precisar de IP fixo ou abrir portas no roteador.

Além disso, vai um macete para instalar o NextCloud do jeito mais fácil que encontrei.

Pra começar, precisaremos de uma máquina para o servidor. No meu caso, criei uma para teste dentro do Proxmox rodando o Ubuntu Server (tem vários posts aqui no blog sobre Ubuntu Server: veja aqui).

Bom, criada a VM e instalado o Ubuntu, dê o comando abaixo para instalar o NextCloud:

sudo snap install nextcloud


Após algum tempo, menos que um minuto, dever receber uma resposta como essa no final:

nextcloud 24.0.1snap1 from Nextcloud installed


O NextCloud está instalado na sua máquina! Fácil!

Para acessar, digite o endereço da VM no browser. Se não souber, digite:

# hostname -I

192.168.1.34


Pronto! Entre no seu NextCloud e divirta-se.

Quer mais? Então vamos habilitar o NextCloud para acessar https.

Primeiro digite: 

# sudo nextcloud.enable-https self-signed


E você deve receber a resposta: 

Generating key and self-signed certificate... done

Restarting apache... done


Agora vamos habilitar o NextCloud a permitir o acesso proveniente de fora da rede local. Primeiro vamos acessar o arquivo de configuração com:

# sudo nano /var/snap/nextcloud/current/nextcloud/config/config.php


Agora procure a linha no arquivo a linha de "trusted_domains":


E troque o endereço aí dentro por um asterisco. Deve ficar assim:


Agora vá ao site https://ngrok.com e faça seu cadastro gratuito. Esse site cria um túnel entre o terminal que você está acessando e o seu computador. Depois, para instalar o serviço no servidor, use o comando:

# sudo snap install ngrok


E você deverá receber uma mensagem como essa se tudo der certo:

ngrok (v3/stable) 3.0.6 from Kyle Wenholz (kyle-ngrok) installed


Agora tem uma pegadinha: para instalar a configuração do Ngrok, você tem que estar no diretório raiz do servidor. Se estiver em outra pasta, receberá uma mensagem de erro. Na página do serviço, após seu cadastro, haverá um link com comando para a instalação. Essa senha muda para cada cadastro e para cada serviço instalado. Aqui o comando para instalar foi:            
E a resposta foi:

Authtoken saved to configuration file: /root/snap/ngrok/79/.config/ngrok/ngrok.yml


Por último, vamos configurar por onde o ngrok vai acessar o NextCloud:

# ngrok http 443


Pronto. Ou quase. Essa última linha direciona o acesso externo para a porta 443 do servidor. Como a nossa conta no Ngrok é gratuita, temos esse endereço feio aqui embaixo (no campo Web Interface)


Digitando esse endereço no navegador, de qualquer browser em qualquer lugar, você acessará seu NextCloud neste servidor.

Assim, se você tiver um docker rodando em outro servidor com acesso por alguma porta específica, basta instalar o Ngrok naquele servidor e configura a porta dele (ao invés da 443) e acessar! Show!

Um detalhe é que ao dar o comando para criar o túnel (esse ngrok http 443), uma janela é aberta (essa figura aí de cima) e ela deverá ficar aberta durante todo o funcionamento do túnel

 - se você sair com da janela com Control+C, o túnel será fechado e seu serviço cairá;
 - se você simplesmente fechar a janela, perderá o controle do túnel (a interface web no site do serviço só permite fechar o túnel na versão paga);
 - para você ter novamente acesso ao controle do túnel, terá que dar o comando: killall ngrok  para fechar o túnel e recriá-lo novamente com ngrok http 443 , mas endereço do túnel será alterado.

Última dica do dia:

Como foi visto, aqui sairá um endereço feio, difícil para lembrar. Para facilitar, use um encurtador de link (já falei disso aqui e aqui). O endereço até pode não ser bonito também, mas será mais curto e mais fácil de lembrar...

Outra opção é criar uma conta no DuckDNS e fazer como eu expliquei aqui. Depois de criar a conta no DuckDNS e ativar o serviço para atualizar seu IP no serviço deles, é fundamental corrigir o trusted_domains (como explicado aí em cima) e autorizar o NextCloud a acessar o https (também explicado aí para cima).

Por hoje é isso!

sábado, 12 de março de 2022

Resolvido: acessando o NextCloud fora da minha rede doméstica!

Pessoal,

Há algum tempo venho tentando entender como funciona redes, Docker e essas coisas para montar meu NAS e acessa-lo do meu celular, em qualquer lugar do mundo.

Hoje, finalmente, consegui resolver isso. Com isso, encerro (por enquanto) este assunto iniciado lá em 2020 no auge da pandemia (veja os posts relacionados aqui, aqui, aqui, aqui, aqui, aqui, aqui, aquiaqui e aqui).

Nestes posts conto a saga para entender o básico de redes, como abrir portas no roteador, VPN, discos em rede, NAS, Docker, etc. É aprendizado demais!

Tenho certeza que qualquer pessoa com algum grau de instrução em TI ou equivalente faria isso com os dois pés nas costas, mas a minha formação é outra. Além de aprender isso, eu ainda tinha que fazer anestesia, dar plantão em CTI, administrar uma equipe de anestesia, administrar essa equipe em um momento de troca do dono do hospital, começar em um serviço novo e, sete meses depois, largar tudo para começar em outro serviço! Isso sem férias há 3 anos!! É, COVID fudeu a vida de todo mundo...

Enfim, vamos terminar essa novela.

O NAS (OMV) já está rodando no Proxmox. Estável, sem sobressaltos. No Proxmox também roda uma VM com o Ubuntu Server com algumas coisas em background.

Por comodismo mesmo optei por colocar o Docker na mesma VM do OMV, mas pensando agora talvez deveria ter colocado em outra. enfim, já foi e não vou inventar moda de alterar isso agora.

O NextCloud roda no Docker e isso tem uma grande vantagem: é facinho acessar os arquivos de configuração dele. Por exemplo, para autorizar acessos ao NextCloud, é preciso editar uma linha num arquivo (config.php). Para acessar, basta entrar no Portainer, ir em Stacks -> nextcloud e, lá embaixo, em Quick options, acessar o quarto ícone (Exec Console):


Isso abre o shell deste docker específico. Aí é só navegar até a pasta onde está o arquivo desejado:


Esse arquivo aí, o config.php, contém as informações para acessar o NextCloud de qualquer lugar, especificamente o campo  "trusted_domains". Fica algo mais ou menos assim:


Bom, outra coisa importante é liberar as portas no roteador. Pra isso, os roteadores tem uma configuração chamada Port Forwarding. Basicamente ela recebe uma solicitação de um IP externo para acessar a porta X e encaminha para um IP interno pela porta determinada internamente.

Por exemplo, você pode determinar que quem acessar a porta 1234 do seu IP determinado pela sua provedora vai se conectar no IP de uma VM e usar a porta 2345 dessa VM. Assim:

    181.191.45.23:1234 -> 192.160.1.15:2345

Ou seja, se você quiser acessar o NextCloud que está rodando na sua VM que utiliza um IP fixo (fornecido pelo seu roteador de casa) '192.168.1.15' e que usa a porta 2345 que você escolheu, você pode usar o seu IP fornecido pela sua operadora (pra isso, acesse o site whatismyip e você ficará sabendo qual IP seu IPS fornece para você) para acessar a porta 1234. O seu roteador vai escutar a porta 1234 e vai encaminhar para o local correto (no exemplo, 192.168.1.15:2345). Simples. Lembre-se apenas de não usar portas reservadas do sistema (veja as portas reservadas aqui).

Agora você já pode usar o seu IP residencial, fornecido pela seu provedor, para acessar o NextCloud.

Provavelmente o seu provedor fornece um IP variável, ou seja, de tempos em tempos o IP da sua casa muda. Só que para acessar um serviço de fora da sua rede doméstica, o IP tem que ser fixo. Pra isso ou você paga os tubos pra ter um IP fixo em casa ou arruma um servidor de DNS que atualize o seu IP de tempos em tempos automaticamente.

Pra isso tem o No-IP (que exige que você atualize seu cadastro a cada mês para ser de graça) ou o DuckDNS. Basicamente, tanto um quanto o outro, instalam um pequeno programa no computador que verifica o seu IP e informa ao serviço que o DNS buscado corresponde a um IP determinado (que o serviço vai atualizar automaticamente).

Assim, por exemplo, o seu NextCloud está instalado numa VM com IP 192.168.1.15 e usa a porta 2345 para se comunicar. Já o seu IP em casa é, agora, 181.191.45.23. Aí você escolheu abrir a porta 1234 do seu roteador para acessar o seu NextCloud. Só que, por exemplo, a cada semana seu IPS troca o seu IP. Assim, fica assim:

Semana 1: 181.191.45.23:1234 -> 192.168.1.15:2345

Semana 2: 182.191.45.57:1234 -> 192.168.1.15:2345

Semana 3: 182.191.41.37:1234 -> 192.168.1.15:2345

O DuckDNS e o No-IP criam um nome de DNS (por exemplo meuhomeserver.duckdns.org) que vai corresponder ao seu IP atualizado diariamente pelo programinha deles.

Semana 1: 181.191.45.23 = meuhomeserver.duckdns.org
                  meuhomeserver.duckdns.org:1234 -> 192.168.1.15:2345

Semana 2: 182.191.45.57 = meuhomeserver.duckdns.org
                  meuhomeserver.duckdns.org:1234 -> 192.168.1.15:2345

Semana 3: 182.191.41.37 = meuhomeserver.duckdns.org
                  meuhomeserver.duckdns.org:1234 -> 192.168.1.15:2345

A grosso modo, é isso que esses serviços fazem. Muito útil, não?

Depois você pega esse endereço 'meuhomeserver.duckdns.org' e coloca lá no 'trusted_domains':


Fica algo mais ou menos assim:

'trusted_domains' =>   [
   0 => '192.168.1.15',    ],

Esse é o IP da sua VM, por exemplo. Colocando o nome do DNS do DuckDNS, vai ficar assim:

'trusted_domains' =>   [
  0 => '192.168.1.15',
     1 => 'meuhomeserver.duckdns.org',
  ],

Assim, quando você acessar o NextCloud, seja pelo computador, seja pelos aplicativos, o NextCloud vai saber que o acesso pode ser autorizado!

A última coisa é que cada vez que você acessa o serviço, o NextCloud reclama que não tem certificado de segurança.


Então temos que fazer um certificado e resolver isso! E aqui está o problema: todas as opções que testei deram erro. Preciso entender como fazer isso e será assunto de um post em breve (assim que descobrir como resolver).

Então é isso por enquanto!

ATUALIZAÇÃO:

Pessoal, a resolução deste problema está explicada aqui.

sexta-feira, 2 de abril de 2021

Novo NAS - Open Media Vault

Pessoal,

Já contei em vários posts aqui do blog sobre o NAS que eu fiz utilizando o FreeNAS (aqui sobre o próprio OpenMediaVault - OMV - quando fiz um teste no RP3, aqui quando fiz um dual boot no MacWhite para instalar o Ubuntu Server e instalar o NextCloud via Docker, aqui sobre a tentativa frustrada de abrir o roteador para acessar a minha rede fora de casa, aqui sobre a VPN com o OpenVPN e NoIP - solução que vou manter no OMV também -, aqui onde falo das minhas impressões sobre o OMV, XPEnology e FreeNAS e porque tinha decidido a usar o FreeNAS e, por último, aqui onde falo do FreeNAS e utilização para PlexServer e backup - incluindo o TimeMachine).

O FreeNAS é derivado do FreeBSD e o OMV é derivado do Debian (Linux). Ambos são derivados do Unix, mas cada um com uma proposta um pouco diferente. O BSD (que origina o FreeBSD) é a base, inclusive, para o MacOS (sim, o MacOS é derivado do BSD e, assim, do Unix! Linux e MacOS são, de certo modo, primos!).

Quando tinha optado pelo FreeNAS, eu vi e gostei muito da forma de instalar "plugins" nele, pelos Jails. Eu não sabia, todavia, que o OMV também tinha essa opção (OMV Extras). Pelo que percebi, o FreeNAS é um pouco mais complexo devido aos jails, que tem um sistema de permissões mais complexos. O OMV, ao contrário, parece ser um pouco mais flexível.

Como exemplo, não adianta simplesmente instalar um jail do NextCloud ou instalar o Docker no FreeNAS e instalar o NextCloud nele. Para acessar o pool de arquivos, é uma luta. Parece (digo parece porque ainda não instalei isso no OMV) que o sistema de instalação e compartilhamento no OMV é bem mais simples.

Outra coisa que havia me direcionado ao FreeNAS era o suporte à VM. O problema é que o FreeNAS usa toda a RAM que eu coloquei como cache. PQP! Haja RAM! Assim, as VM ficam leeeennnntttttaaaaassss! Inutiliza toda a ideia do negócio. Óbvio que tem solução: colocar um SSD para cache, por exemplo, mas não vou gastar nada com isso.

Aí vi que o o OMV tem suporte a VM também, utilizando o Virtual Box. Acho que aí eu resolvo minha questão com VM.

Além disso, outras coisas motivaram essa troca toda.

Uma delas foi a esdrúxula decisão do Yahoo de acabar com o Auto Forward de mail. Uma das medidas mais antipáticas que já vi. Lá pelos idos 1997, quando a internet começou a chegar no Brasil, eu ainda estava na Faculdade de Medicina da UFMG. Na época, criaram o Centro de Informática Médica na faculdade e disponibilizaram emails para os alunos. Eu tinha um e era bem simples (como toda a internet da época). Aí apareceram o Yahoo Mail (fiz dois, um .com.br e um .com), o HotMail (também fiz um, antes de ser comprado pela Microsoft) e na iG (lembram dela?).

Pois bem, quando saí da faculdade, o acesso ao email da FM-UFMG foi cancelado. Comecei a usar o iG como meu email principal. Depois, mudei para o yahoo.com.br. Quando o Gmail surgiu, a interface dele era melhor e comecei a utilizar o Auto Forward do Yahoo para o Gmail, que acabou sendo a minha interface de email, apesar de receber e responder como yahoo.com.br.

A questão passou a complicar no começo de 2021, quando o Yahoo acabou com o auto forward para as contas gratuitas, alegando que não havia segurança, mas manteve para as contas pagas. Peraí! Não é seguro para conta gratuita mas é seguro para conta paga? PQP! Arranja outra desculpa melhor, né?

Como vários serviços e sites que eu acesso estavam cadastrados com o email Yahoo, fui mudando, ao longo de alguns meses para o Gmail. Atualmente só utilizo o Yahoo para o NoIP e a Apple.

Assim, aproveitei toda essa mudança e vou trocar o serviço do NoIP do Yahoo para Gmail. Só que isso vai resultar na reconfiguração do serviço de DNS dinâmico que preciso para o OpenVPN.

Enfim, dadas as devidas explicações, confirmei que todos os meus arquivos backupados no FreeNAS estão nos meus HD externos e mandei ver na troca do FreeNAS pelo OMV.

Além disso, aproveitei um HD de 500GB parado aqui para colocar no servidor. Assim, ele vai ter um HD de 500GB para rodar o OMV (mais que necessário), além de um de 1TB que já está nele e mais alguns externos para fazer o serviço de Storage.

A instalação é super simples. Após baixar a imagem estável no site deles (eles direcionam para o SourceForge, aqui), basta seguir as instruções na tela. Ja mostrei a instalação no primeiro post da série "Em busca do NAS doméstico (quase) gratuito!". Lá eu tinha mostrado como fazer no RP3 com o RaspOS instalado. Hoje fiz diferente: gravei a ISO baixada num pendrive bootável, desconectei os HDDs do servidor, coloquei o pendrive e reiniciei a máquina. Na hora de escolher onde gravar o OMV, formatei o HD interno da máquina e gravei nele. O resto é só seguir as instruções.

Duas coisas importantes: primeiro, reserve um IP fixo para o server, ajuda muito. Já falei disso aqui e vale sempre recomendar a leitura. Segundo, escolha uma boa senha.

Após instalar e trocar a senha, vá em Sistemas -> Update Management e atualize tudo que houver para ser atualizado.


O OMV, ao contrário do FreeNAS, não tem uma opção para acessar o Shell. E, ao contrário do RP, onde podemos instalar como um programa no RaspOS e acessar o Shell via VNC, o OMV não tem suporte para VNC (não ainda e não o VNC). Assim, ou você precisará de um monitor e um teclado para digitar algumas linhas de comando ou você pode utilizar o SSH. Por padrão, o SSH já está habilitado no OMV e você acessa digitando:

        ssh <usuário>@<endereço do OMV> <enter>

No meu caso, é:

        ssh root@192.168.1.2 <enter>

Usuários do Windows precisam, se não me engano, acessar pelo Putty.

Uma vez dentro do Shell do OMV, instale os "extras" com a seguinte linha de comando:

     wget -O - https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install | bash

Esses extras é que contêm a parte divertida: Docker, Transmission, PlexServer, Vitual Box, etc. Mas vamos falar disso mais pra frente.

Agora vamos preparar os discos para Storage.

Uma das grandes vantagens do FreeNAS e do OMV é aceitarem, nativamente, discos via USB (o XPEnology não aceita nativamente).

Após conectar o disco, vá em File System (ou Sistema de Ficheiros). Veja que o disco que você acabou de conectar NÃO está lá.


O disco, para aparecer, precisa ser "criado". Assim, quando você escolher Criar, aparecerá uma pequena tela que mostrará o disco conectado:


Escolha o disco, crie o nome e formate em EXT4. Como tenho dois discos para backup, ficará assim: o disco do OMV será sda, o primeiro backup será sdb e o terceiro será sdc. Esse é um processo um pouco demorado, a depender do tamanho do disco. Tudo que está nos discos será apagado!

Um detalhe: se a ideia é fazer algum RAID com discos externos, esqueça! O OMV, ao contrário do FreeNAS, não permite!


Não é um grande problema, pelo menos não inicialmente. Posso colocar esses dois discos (ambos de 4TB) para gravarem sequencialmente, mais pra frente comprar um de 8TB para fazer isso também ou, também mais pra frente, comprar uma gaveta e colocar dois discos lá dentro do server. A ver.

Após a criação e formatação dos discos, vamos montá-los no sistemas. Tentei formatar os dois ao mesmo tempo, mas eles estavam sendo persistentemente excluídos. Assim, tirei os dois do computador, liguei um, formatei e montei, depois fiz a mesma coisa com o outro. Aí deu certo. Vejam:


São esses dois, BKP01 e BKP02.

O próximo passo é criar um usuário para acessar os discos e pastas para esses acessos compartilhados na rede.

Assim, vá em em "Gestão de Direitos de Acesso" --> "Utilizador" e crie quantos usuários forem necessários. Aqui eu criei alguns: um para mim e outro para a patroa (cada um terá uma pasta para fazer backup de seus arquivos); um para o Plex (onde vou colocar as mídias), outro para o Transmission. Se precisar, pode-se incluir ou excluir usuários.

Depois, vá em "SMB/CFS" --> "Definições" e ative o SMB em "Ativo" e então vá em "Partilhas" para criar a(s) pasta(s).

Aqui tem um ponto importante: qual o grau de acesso que você quer dar a quem tem acesso a sua rede? Eu escolhi a opção onde o administrador e os usuários cadastro leem e escrevem e os usuários não cadastrados podem apenas ler. Isso vai de acordo com seu interesse.


Se você descer mais as opções, poderá ativar a opção "Time Machine Support" para permitir que o Mac faça o Time Machine. Para isso, optei por criar uma pasta "Time Machine" no outro disco (BKP02).



Para acessar este disco, será pedido um login e senha - é o nome do usuário e senha que você cadastrou!

O próximo passo agora é configurar os backups. Como já fazia tudo pelo Carbon Copy Cloner, é só organizar o destino e mandar começar os backups.

Agora o TimeMachine está rodando e os backups também. E isso vai demorar algumas horas.

Se tudo ficar certinho, vai sair um próximo post para instalar o PlexServer, o Transmission, o OpenVPN e o Virtual Box.

Até o próximo!

sábado, 9 de janeiro de 2021

Atualizando o NextCloud no FreeNAS

 Pessoal,

Pequena nota sobre atualização do NextCloud no FreeNAS.

Dias atrás fui atualizar o NextCloud no FreeNAS e mandei direto pelo update do Jail. Travou numa tela de "Maintenance Mode":


Como o administrador do sistema sou eu mesmo, tive que me virar para resolver.

Já que não tenho dados sensíveis no NC, poderia simplesmente apagar tudo e reinstalar do zero, mas preferi fazer o mais difícil, claro.

O erro foi ter feito pela update do NC direto no FreeNAS. Deveria ter feito usando "./occ upgrade", mas não sabia. Nem que deveria ter feito assim nem como fazer assim...

A solução é bem simples.

Navegue até:

    /mnt/(jail pool)/iocage/jails/nextcloud/root/usr/local/www/nextcloud/config

Nesta pasta, procure o arquivo "CONFIG.PHP".

Abra ele com o comando "nano config.php" e procure pela linha" 'maintenance' => true," e troque o "true" por "false".

Depois saia com control+x, clique Y para confirmar a gravação no arquivo e recarregue a página do NextCloud.

Deve aparecer algo como isso:


Pelo que eu li, deveria ter dado certo fazendo isso, mas recebi o erro de "504 Gateway Time-out". Assim, reiniciei o jail e... nada! Deu o mesmo erro.

Ou seja, tenho que usar o ./occ mesmo.

Abri o jail do NextCloud no FreeNAS e abri o shell no jail.

$ cd /usr/local/www/nextcloud
$ su -m www -c /bin/sh
$ php ./occ maintenance:mode --off$ php ./occ upgrade

No shell do jail, ficou travado em uma mensagem: "Starting code integrity check...".

Voltei na tela do NC e mandei atualizar e, após vários updates de partes, apareceu a mesma mensagem e deu erro no final :(

Voltei à estaca zero.

Conclusão: vou apagar e reinstalar o NextCloud... 😒😕 Mais fácil.

ATUALIZAÇÃO!

Não vou mais instalar o NextCloud. Quando instalei, não estava nem usando, só ocupando espaço no disco. Como o disco é o mesmo do FreeNAS, é redundância besta.

Hoje uso o iCloud (200GB, compartilhados com a esposa), coloquei lá TUDO que preciso acessar em qualquer lugar e ainda está sobrando 100GB!

Obviamente não coloco fotos, videos e músicas. Mas faço backup de arquivos e documentos de trabalho e acesso no iPhone, iPad e qualquer um dos computadores. Minha esposa acessa no iPhone, no Mac dela e até no Windows daqui de casa e do escritório dela.

Além disso, ainda faço backup das coisas de trabalho no Dropbox e OneDrive. E copio todos pra HD externo e FreeNAS. Estou bem resolvido. Por enquanto.

domingo, 4 de outubro de 2020

NextCloud no FreeNAS

Oi pessoal,

Depois da surra que tomei com o PiHole (veja a atualização aqui, no final do post), deixei-o de lado por enquanto e vou instalar o NextCloud!

Bom, a instalação é tranquila mas demora bastante, uns 20 minutos pelo menos.

Vá em Plugins --> NextCloud e clique instalar. Pronto. Quase que só isso.

O ideal seria você colocar o ip desejado antecipadamente ou deixar o DHCP resolver isso para você. Para mim, o NAT aparecia marcado e só funcionou como ele marcado, senão dava erro lá no final da instação.

Depois de instalado, parei o Jail do NC, fui em Edit e mudei o IP para o que eu escolhi. Deu um pau, fácil de resolver. A mensagem era que o domínio não era confiável e era necessário corrigir o arquivo "config.php". Mas onde está este maldito arquivo?



O manual do NC não especifica onde está isso. Dando um pesquisada, achei um post que falava onde estava:


Ótimo! Só que não. No meu NC, pelo menos na versão que estou usando, não tem essa pasta "pbi"...

Bom, fui no Shell do FreeNAS e dei os comandos:

    jls #(para listar os jails e ver qual o número do jail do NC)

    jexec 12 csh #(para entrar como root no shell do NC - que no meu caso está no jail 12)

    ls #(para ver as pastas e ter uma ideia do que fazer)

Aí apareceu "/usr"; entrei nela e vi "local"; entrei e vi "www"; entrei e vi "nextcloud"; entrei e vi "config"; entrei e vi o "config.php" (ou seja: /usr/local/www/nextcloud/config).

    vi config.php #(para editar o arquivo)

Fui até "Trusted domains" e estava troquei o IP que a instalação definiu pelo que eu queria.

Para lembrança futura: no VI, para editar a gente aperta "i", vai até onde que editar e escreve por cima; se errar, tem que sair com "ESC", apertar "x" que apaga a letra errada. Para sair, dê um :wq (grava e sai do VI). Resumindo: um saco!

Depois, parei e reiniciei o jail do NC, abri o navegador e digitei o IP! Tudo funcionando.

Quando abrir a primeira vez, você pode ir em Plugins, clicar no plugin instalado do NC, seta para baixo e clique em "Post Install Notes". Os nomes de usuário e senha do NC estão aí. Copie e inicie o NC!

Pronto! Agora a gente entra e coloca esse username (administrador) e a senha e entra no NC. Mude a senha do adm e crie um usuário e experimente para ver se a nova senha e o novo usuário estão ok.

Agora precisamos terminar de configurar o NC.

Vá no Shell do FreeNAS e entre no shell do NC. Navegue até /usr/local/etc/nginx/conf.d e digite:

    vi nextcloud.conf

Agora, no primeiro "Server", edite para ficar assim:

 server {
listen 80; server_name _; return 301 https://$server_name:443$request_uri; }

Isso faz o NC reponder pelo ip que escolhemos para ele e direciona alguma requisição pela porta 80 (http, sem segurança) para a porta 443 (https, com segurança).

Crie outro "server" abaixo e coloque:

server { listen 443 ssl http2; server_name _l; ssl_certificate /usr/local/etc/ssl/mycert.crt; ssl_certificate_key /usr/local/etc/ssl/mycert.key;
}

Agora a gente vai usar as dicas deste site aqui para criar o certificado ssl através do "openssl".

Vá para a pasta "/usr/local/etc/ssl". Esta é a pasta onde ficará o certificado ssl.

Dê um:

    openssl req -newkey rsa:4096 -x509  -sha256 -days 1825 -nodes -out mycert.crt -keyout mycert.key

Aqui ele criou o certificado SSL! E vamos reiniciar o servidor com:

    service nginx start

Pronto! Serviço reiniciado e, se tentarmos acessar com o "http://<seu_ip>" vamos ter esse erro aqui:


Isso é exatamente o que a gente quer: forçar o serviço a ser acessível via "https" com certificado SSL!

Quando você digitar usando o https, pode ser que dê o mesmo erro. Neste caso, como você criou o certificado, o navegador pode não confiar e pedir para que você autorize. Se for seu caso, vá em "ver o certificado" e veja se as informações batem com o que você criou. Se estiver tudo certo, vá "visitar este site", autorize e siga em frente.

Pronto! Quase tudo feito!

Se você tiver um equipamento com iOS/Android/Windows/Mac, baixe os aplicativos para acesso remoto.

Outra coisa é acessar remotamente, de fora da rede local. Até aqui, tudo está pela rede local. A gente até tem como acessar isso pela rede. Mas, pra mim, paro por aqui. Neste post aqui mostrei como criar uma VPN com o PiVPN e deixar ela rodando no Raspberry Pi (dá até para colocar no FreeNAS, porque ele tem um plugin do OpenVPN). Assim, se precisar acessar remotamente, de fora da minha rede local, conecto o equipamento na internet, abro a VPN e acesso o NC, pelo aplicativo ou pelo site. Muito, muito mais seguro!

Este site tem boas dicas de como configurar seu NextCloud.

E aqui e aqui têm dois bons vídeos, bem passo a passo!

Outra opção, não utilizando o FreeNAS, é utilizar o Docker para instalar o NextCloud, usando o OpenMediaVault. Veja como aquiaqui. Este vídeo aqui ensina a instalar o Ubuntu Server rapidinho, a base para usar o OMV e o NextCloud.

Até mais, pessoal!

sábado, 3 de outubro de 2020

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.

domingo, 30 de agosto de 2020

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.