OpenWrt: horário de verão novo

Mais um artigo da série sobre o OpenWRT/LEDE.

Senta que lá vem a história... (se quiser só a parte técnica, pule para o final)

Era uma vez, em uma terra sombria, existiam computeiros que sofriam todos os anos do mesmo mal: horário de verão. Não por acordar mais cedo, que geralmente também é verdade, mas pelo trabalho de reconfigurar dezenas, centenas, milhares de equipamentos com uma regra de mudança de horário mais volúvel que uma pluma ao vento. E pior, era definido em cima da hora. Parecia algo insolúvel, digno dos teoremas de Fermat. Porém, quando todos já haviam perdido a esperança, surge do alto do seu cavalo branco um ser iluminado que define uma regra fixa! Eureka! E todos viveram feliz para sempre... até este ano. A partir deste ano, o horário começa na primeira semana de novembro. E talvez mude de novo no próximo ano, e de novo....

Mas para que mexer?! Bem, existe uma lenda de um estado chamado Acre. Eles usam um horário com 2 horas a menos que Brasília. Com o horário de verão, esta diferença fica de 3 horas. E eu com isso?! Veja bem, a cada quatro anos, temos eleições nacionais. E para não influenciar os que ainda estão votando, não são divulgados os resultados parciais até o horário de encerramento da votação. Lembra do Acre? Eles também votam para presidente! Então, no primeiro turno, a primeira parcial nacional divulgada é às 19 horas (Brasília). Já no segundo turno, com o Acre ainda mais atrasado (no horário!), eles votam até às 20 horas (bem, tem mais brasileiro no exterior que no Acre e que ainda estarão votando... mas não vem ao caso). Depois de três horas do fim da votação, quase todos os votos já foram totalizados e, normalmente, temos uma boa ideia do resultado final. Uns dizem que isso traz ansiedade à sociedade. Outros que pode passar a ideia que estão "modificando o resultado". Tem até gente que diz que "perde a graça", meio como "ejaculação precoce".

Em resumo: para não influenciar os eleitores do Acre mas ainda divulgar o resultado às 19h, mudaram o início do horário para o primeiro domingo depois das eleições (ou primeiro domingo de novembro). Valeu Temer! Ótimo trabalho! Dane-se o custo de reconfigurar milhões de dispositivos, dane-se quem já planejava eventos anuais para não coincidir com a troca (ENEM?), dane-se quem vai perder uma hora de sono com trocas antecipadas do horário, DANE-SE TUDO! Eu acho que é mais importante saber o resultado PARCIAL das eleições nacionais uma hora antes. Eu quero e pronto!

Pergunta para qualquer um se eles querem ser acordados por engano uma hora antes ou ter o resultado parcial das eleições nacionais uma hora antes? Se já sabe a resposta, era só seguir. Isso é mais ou menos o que seria uma tal de democracia.

Só uma observação: no Acre temos 547.680 eleitores. Se eles votarem de forma bem distribuída ao longo das 10 horas de votação, a divulgação às 19h de Brasília poderia influenciar 10% do eleitorado, ou 54.768 eleitores. Se descontar os históricos 30% de brancos, nulos e abstenções, seriam um pouco mais de 38.000 eleitores! Agora pense quantos destes mudariam o voto sabendo da PARCIAL nos outros estados. Se for uns 20%, são míseros 7.667 eleitores. TUDO ISSO PARA ISSO?!

Início parte técnica

Mas voltando ao OpenWrt, ele não usa banco de dados de horário. A configuração do fuso já incluí o horário de verão.

# uci show system.@system[0].timezone

system.cfg01e48a.timezone='BRT3BRST,M10.3.0/0,M2.3.0/0'

Se você configurou pela interface web (Luci) o fuso de São Paulo, ele tem um banco de dados com essas regras e preenche para você. Se você estiver como Luci atualizado, este banco está atualizado. Porém, ele é usado apenas durante a mudança de configuração pelo Luci. Se mudar a regra, ele não vai automaticamente trocar a configuração.

Para resolver:

# uci set system.@system[0].timezone='BRT3BRST,M11.1.0/0,M2.3.0/0'

# uci commit

# reboot

Também pode trocar o fuso pela interface web ou editar o /etc/config/system. Fica a gosto do cliente.

O formato da configuração é bem simples. Nota-se que o retorno está definido no terceiro domingo de fevereiro. E não é que temos uma exceção? Essa regra quebra se a volta for no carnaval (algo raro). Para não dar mais uma hora de folia, adia-se o final para o próximo final de semana.

Então é isso. Bom sono a todos. Até a próxima.

OpenWrt: atualizando para a versão 18.06

Mais um artigo da série sobre o OpenWRT/LEDE.

No post anterior, comentei sobre o lançamento do OpenWrt 18.06. Agora vamos instalá-lo.
Sim, este artigo repete diversos pontos do artigo da versão LEDE 17.01 e a anteanterior. 

Só um aviso: já foi lançada a versão 18.06.1 devido a uma vulnerabilidade no kernel.

96,72% dos problemas com instalação/atualização com OpenWrt/LEDE que ajudo é em relação a escolha incorreta da imagem da firmware. Como sempre, recomendo a versão squashfs, que possui modo de recuperação. A variante jffs2 e ext4 nem estão mais disponível por padrão para a maioria dos dispositivos. Pegue o arquivo no download da última versão estável e nunca em um endereço qualquer, mesmo que seja na wiki do OpenWrt. Normalmente a wiki referência a versão em desenvolvimento, que não é a que você quer. As versões dentro de "(stables) releases", exceto as com o rc (release candidate) são estáveis. Pegue preferencialmente a mais nova (com número maior). Evite qualquer firmware que tenha no caminho palavras como "trunk", "snapshot" ou "rc1", "rc2"... exceto se estiver testando algo. As versões estáveis também mencionam a respectiva versão do OpenWrt no nome do arquivo como em "openwrt-18.06.1-ar71xx-generic-archer-c7-v4-squashfs-sysupgrade.bin", ao contrário da versão instável/em desenvolvimento "openwrt-ar71xx-generic-archer-c7-v4-squashfs-sysupgrade.bin".

A nomeclatura da versão é adota o formato: ano.mês.correção. O ano/mês se referem ao momento que foi criado um ramo nos fontes para o lançamento da nova versão e não propriamente quando o lançamento final ocorreu. Já o último número é apenas um sequencial de correção. Então, para quem usa uma versão 18.06.x, a próxima 18.06.x+1 deverá conter apenas bugs resolvidos (em especial, os de segurança) e deve ser considerada como recomendada. Estas versões de correção são lançadas com certa frequência. É bom acompanhar (e atualizar).

Em downloads, navegue para releases, a versão desejada (ex: 18.06.x), a "arquitetura alvo" em uso no seu roteador. Se você já é um usuário do OpenWRT, você pode vê-la olhando o arquivo /etc/openwrt_release:

root@router:~#  grep _TARGET /etc/openwrt_release 

DISTRIB_TARGET='ar71xx/generic'

Ou:

root@router:~# grep _BOARD /etc/os-release

LEDE_BOARD="ar71xx/tiny"

OK, chegamos a uma lista enorme de firmwares! Vamos entender o que significa cada parte do nome do arquivo. Tomemos por exemplo "openwrt-18.06.1-ar71xx-generic-archer-c7-v4-squashfs-sysupgrade.bin":

• openwrt é o sistema operacional que você está instalando ;-)
• 18.06.1 é a versão do openwrt. Em firmwares instáveis, este campo não existe!
• ar71xx é a família do SoC (chip) do seu dispositivo. Você descobre isso na wiki do projeto ou abrindo o seu roteador e lendo os CI.
• generic é o subtipo do layout da flash. Normalmente será o "generic", exceto para casos especiais como roteadores com 4 MB que agora usam "tiny".
• archer-c7-v4 este é o modelo do seu roteador. Observe em especial a versão do HW (v4) pois ela pode mudar completamente o dispositivo, inclusive de família do SoC e se é suportado pelo OpenWrt.
• squashfs é o tipo do armazenamento da imagem. Nesta, existe uma cópia imutável dos arquivos (ROM) e o resto da flash é usada para, de forma transparente, guardar as modificações (overlay). Tudo parece editável para o usuário. A diferença é que você pode, a qualquer momento, apagar as diferenças e restaurar o sistema pós-instalação. Pode existir também o formato jffs2. Neste, não existe uma ROM e tudo pode ser realmente apagado. Alterou o arquivo errado? Vai ter que recuperar pela serial, JTAG ou arrancando a flash. Não recomendo!
• sysupgrade é a função da firmware. Esta é para atualizar de um OpenWrt/LEDE para outro (e, em alguns casos, de outros firmwares alternativos como DD-WRT). Porém, não deve ser reconhecido pela firmware original do roteador. Para primeira instalação, ainda com a firmware original, use a variante "factory".

Finalmente, é muito importante ler a wiki do seu roteador independente se ele já funcionava na versão anterior! São poucos minutos de leitura que podem salvar horas de trabalho ou mesmo seu roteador.

Bem, se eu simplesmente ir na interface, fornecer a nova imagem, ele vai funcionar? Provavelmente, mas talvez não é a maneira que dê menos trabalho. A atualização pode preservar as configurações mas não os programas instalados. Se você tem raiz expandida em unidade externa, a encrenca é ainda maior.

Mas eu nunca instalei um programa! OK, use a interface web e provavelmente todas as configurações serão migradas sem problemas. Já testei isto em mais de um roteador e funcionou sem problemas. Mas faça o backup antes! Caso tenha instalado algum pacote, continue lendo.

Em primeiro lugar, precisamos do plano de retorno caso a nova versão não se comporte como o esperado. Faça sempre um backup geral do seu sistema. No processo de upgrade, eu sugiro que sejam feitas as três formas diferentes de backup que eu comento no artigo sobre o tema: backup gerado pelo sistema, lista de pacotes instalados e todos os arquivos do overlay. Este último serve apenas para o plano de retorno caso algo importante não funcione para você na nova versão (e para recuperar algo que não entrou no backup do sistema).

Eu fiz uma proposta de melhoria do backup do OpenWrt para simplificar este processo. Vamos ver como será a aceitação. Mais abaixo mostro como usá-la.

Agora, finalmente, você está pronto para enviar a nova firmware. Se você usa um armazenamento externo para expandir a raiz, leia até o final deste post antes de iniciar o processo! Faça o upgrade pela interface web ou pelo terminal. Inclusive, você pode baixar o arquivo diretamente no roteador. Só cuidado ao colar a URL. O downloads.openwrt.org usa HTTPS por padrão mas o "wget" do OpenWRT não tem suporte para HTTPS (por padrão). Se tiver problemas, remova o "s" de "https".

E pode fazer pela Wifi? Os fabricantes não recomendam usar sempre um computador "conectado por cabo"? Sim, e já tive problemas com atualização a partir da firmware do fabricante por não escutar isto. Mas não com OpenWRT. Se estiver atualizando (e não instalando a primeira vez!), pode fazer pela Wifi sem problemas. Quando a gravação for iniciada, todo o processo já está independente do computador cliente. Só não pode faltar energia ;-)

E depois do "Enter"/"Gravar", é a hora que você reza. Sempre dá um frio na barriga.

Se optar por preservar as configurações, tudo que seria guardado em um backup do sistema (listado pelo "sysupgrade -l") será restaurado. Se você instalou algum pacote e guardou a lista do que foi instalado (lembra que eu sugeri há alguns parágrafos atrás?), esta é a hora que você reinstala os pacotes desejados. Se for instalar manualmente, procure instalar os pacotes de mais alto nível (ex: "luci-app-minidlna" antes de "minidlna"), pois eles irão, por dependência, baixar os pacotes necessários. No final do processo, é bom refazer a listagem do que está instalado e comparar com o que você tinha na versão anterior.

Podem ser criados arquivos sufixados com "-opkg" em /etc/. Este são arquivos de configuração originais do pacote e são criados pois você modificou algo na configuração. Sugiro que verifique se não existe alguma coisa introduzida neste pacote que deveria ser adicionada no seu arquivo de configuração. Eu gosto do diff ou do "vim -d" para este trabalho comparando o arquivoconf com arquivoconf-opkg. Ao final do processo, eu gosto de apagar qualquer -opkg para deixar claro que apliquei tudo que queria.

As atualizações de segurança serão disponibilizadas por meio de atualização de pacotes (exceto as que exijam mudar o kernel). Para listar os pacotes atualizáveis:

# opkg update
# opkg list-upgradable

O maior problema é que estas atualizações de segurança, quando de pacotes embutidos oriundos na firmware instalada, ocuparão o espaço duas vezes no roteador pois ao substituir arquivos existentes na firmware inicial, ainda será preservado a versão em somente leitura para recuperação. Se for um problema para seu caso, a alternativa é esperar a próxima versão com a correção ou gerar uma nova firmware com o pacote atualizado.

Por fim, faça um novo backup geral. É sempre bom preservar o seu trabalho.

Se estiver familizarizado com um terminal, você pode experimentar os novos modos de backup que eu comentei anteriormente. As novas opções são:

• '-u': salva tudo da /overlay, exceto aquilo que vem dos pacotes, mas inclui os arquivo de configuração modificados e os listados em /etc/sysupgrade.conf
• '-o': ignora os arquivos que são idênticos ao /rom (já estavam assim na firmware)
• '-k': inclui uma lista de pacotes instalados para reinstalação

Isso simplifica em muito as instalações mais complexas, com arquivos e pacotes extra. O resultado final é próximo ao que você tem em uma atualização de distribuição no Linux, onde os arquivos são preservados e os pacotes reinstalados:

# cd /tmp

# wget http://luizluca.github.io/sysupgrade

# chmod +x ./sysupgrade

# ./sysupgrade -o -k -u -b backup.tgz

# wget https://downloads.openwrt.org/releases/.../openwrt....bin

# sysupgrade -f backup.tgz openwrt...-sysupgrade.bin

<agora ele reinicia>

# opkg update

# grep "\toverlay" /etc/backup/installed_packages.txt | cut -f1 | xargs -r opkg install

# rm /etc/backup/installed_packages.txt

# reboot

Se precisar retornar a versão anterior do OpenWRT, realize a gravação da firmware antiga, entre no modo de recuperação e restaure a overlay.

Se você não usa uma unidade externa para expandir o espaço interno, seu trabalho acabou. Para os demais, o processo é um pouco mais complicado... Ao atualizar o sistema, você terá um kernel novo que é incompatível com os módulos de kernel ou mesmo com as bibliotecas existentes na unidade externa, que ainda pertencentes à versão anterior. Você precisaria reinstalá-los. Esta é a sugestão de como proceder:

Em primeiro lugar, gere todos os backups sugeridos anteriormente. É importante preservar seu trabalho anterior. Ainda sem instalar a nova firmware, reinicie o sistema sem a unidade externa. Se você seguiu minha sugestão de manter uma configuração básica na flash interna, você ainda terá um ambiente funcional. Com isto, ele vai usar somente a flash interna (com a configuração que você tinha antes de usar a unidade externa).

Ainda com a unidade externa desconectada, faça o procedimento de atualização descrito neste artigo para quem não usa raiz expandida, inclusive com a etapa de backups. Você terá que preservar os dois conjuntos de backups: com e sem a unidade externa em uso. Ao final do processo, você deverá ter a sua configuração básica restabelecida. Caso tenha optado por não preservar as configurações na gravação, você pode aproveitar o backup gerado quando a unidade externa estava desconectada (o segundo) para restaurar as configurações.

Neste momento, a unidade externa ainda está com os programas da versão anterior, que são geralmente incompatíveis com a nova versão (os módulos de kernel sempre o são). Por isto, precisamos nos livrar de todos os arquivos da versão anterior do OpenWRT presentes na unidade externa. Na unidade externa, na partição usada como overlay, remova todo o conteúdo ou mova tudo para um subdiretório (ou para outra unidade se não estiver com espaço livre) afim de que este não seja usado. Como sugestão, crie um "openwrt-versao-xxx" e mova tudo para lá. Refaça a configuração de uso de uma unidade externa (que no mínimo será reinstalar os pacotes necessários). Reinicie o sistema. Você deve estar agora com mais espaço na raiz.

Neste ponto, você ainda terá as mesmas configurações que tinha quando usou o sistema sem a unidade externa. Envie o primeiro backup da versão anterior feito com a unidade externa conectada (primeiro backup). Na sequência, reinstale os pacotes extras, assim como é feito para ambientes sem a raiz expandida. Complete o trabalho com aquele backup final.

Espero que apreciem a nova versão. De agora em diante, vou apenas focar em configurações específicas para OpenWrt 18.06, que ainda podem funcionar nas versões LEDE 17.01, OpenWRT 15.05, 14.07, 12.09 e 10.03.1.

Se pintar um problema, tem sempre o fórum deste blog. Até a próxima.

OpenWrt: Lançada a versão 18.06!

Mais um artigo da série sobre o OpenWRT.

Enfim temos novamente uma nova versão do OpenWrt: a versão 18.06!

OpenWrt? E o LEDE? Para quem perdeu a novela, tem a versão "mais" "longa". Vai um resumo: os desenvolvedores do OpenWrt se estranharam com os "fundadores", criaram um novo projeto levando quase todo mundo. O LEDE se tornou um projeto vibrante enquanto o OpenWrt mor-ré-u de solidão. Diante da situação, os dois grupos conversaram e resolveram se unir novamente. Basicamente aproveitaram o nome do OpenWrt e todo o resto do LEDE (código, wiki, fonte, ...). Então, o OpenWrt 18.06 é muito mais próximo do LEDE 17.01 do que do OpenWrt 15.05. Independentemente se estava usando OpenWrt ou LEDE, a sua próxima versão será OpenWrt 18.06.

E o que temos de novidades? Sim! Como sempre, o kernel muitos softwares foram atualizados. Vamos aos destaques:

Dois kernels

Teremos alguns roteadores com o kernel 4.14 e outros com o 4.9:

• Kernel 4.9.111 for ar7, ar71xx, arc770, at91, brcm2708, brcm63xx, ixp4xx, lantiq, layerscape, mpc85xx, orion, rb532 and uml
• Kernel 4.14.52 for apm821xx, archs38, armvirt, ath25, bcm53xx, brcm47xx, cns3xxx, gemini, imx6, ipq40xx, ipq806x, kirkwood, malta, mediatek, mvebu, mxs, octeon, octeontx, omap, oxnas, pistachio, ramips, sunxi and x86

E isso importa para o usuário final? Sinceramente, geralmente não. Porém, o próximo item depende da versão do kernel.

Aceleração de fluxo de rede

Até agora, eu mencionava que uma das poucas desvantagens do OpenWrt é que ele tem um desempenho menor de NAT do que a firmware proprietária. Isso devido a uma gambi^H^H^H^H^H^H^H^H^H^H um "mecanismo de acelaração de NAT em hardware" existente somente nas firmwares proprietárias. Bem, desenvolveram uma solução equivalente e aceita pela comunidade Linux, com alternativa de aceleração tanto em software puro como com auxĩlio de hardware. Blah, blah, blah... o que significa tudo isso? Bem, antes um roteador "normal", (aquele que você deve ter em casa e não os multi-ultra-dual-core), conseguia rotear WAN entre LAN algo entre 200 Mbps e 400 Mbps, mesmo com ambas sendo GigabitEthernet. Agora, com a aceleração, é possível ver taxas próximas a velocidade do "fio" (1000Mbps) como transferência de 940 Mbps, mesmo em roteadores mais simples.

Mas tem um grande porém.... só vale para os roteadores cujo algo já utilizem o kernel 4.14. E grande parte dos vendidos no Brasil com suporte ao OpenWrt usam ar71xx.

Mas pera aí. É sério isso Luiz? Você realmente acha que conseguir rotear acima de 200 Mbps com um roteador caseiro vai mudar a vida de alguém no Brasil? Bem, ainda não. Mas quem sabe no futuro próximo poderemos ter internet de algumas centenas de Mbps pagável por pessoas que ainda usam roteadores "normais" com OpenWrt. Enfim, o destaque vale mesmo pelo fato de não ser mais um ponto negativo.

Atualização do CAKE

Para quem não conhece, um algoritmo de escalonamento de pacotes é o cara que controla a(s) fila(s) de pacotes entrando e saindo. O CAKE é um desses e busca preservar a latência sempre baixa, sem necessidade de qualquer configuração além de ativá-lo. Na atualização, ele consegue lidar melhor com pacotes que chegam no seu roteador (vindos da internet). Na prática, é o que mais sentimos e o mais difícil de controlar.

Para quem usa o QoS no roteador, será uma atualização bem vinda.

Aumento do tamanho da firmware

Isso é um problema a cada nova versão. O normal é que novas versões de programas ocupem mais espaço. Isso vale para os programas do OpenWrt. Então, a vida já difícil de quem tinha um roteador com 4 MBytes de flash se tornará ainda pior. Podem ter casos de ser tão pequeno o espaço livre que não será possível preservar as configurações. Se isso ocorrer com você, é bom abrir um bug.

Para minimizar isso, foi criada uma variante tiny (ex: ar71xx/tiny em oposição ao ar71xx/generic) que preserva as funcionalidades mas remove os símbolos do kernel, poupando alguns sagrados kbytes. Então, seu roteador TL-WR740ND v1 ainda pode ser usado (eu uso!).

Wireguard

O Wireguard não é propriamente uma novidade desta versão. Porém, é nela que começa a aparecer o suporte para valer no OpenWrt. Para quem não conhece, o Wireguard é uma nova solução de VPN que busca ser muito mais simples do que as "padrão de mercado", como o IPSec (se conseguir, fuja disso mais rápido que puder) e OpenVPN. Quem já configurou qualquer uma dessas e se deparar com uma configuração do wireguard irá se perguntar: "OK, só isso? Não pode já estar funcionado". O wireguard é tão bem vindo que o Linus, que tem mais coisa para fazer, se meteu no desenvolvimento de rede do Linux para aclamá-lo. Teve até carta de senador gringo para o NIST para recomendar sua avaliação como alternativa às VPN existentes (IPSec e OpenVPN). Mas isso fica para outro artigo.

________________________________________

Parece pouca novidade e nada que me interessa. E então, devo atualizar? Provavelmente sim. A versão 15.05 chegou ao seu fim de vida e a 17.01 caminha para o mesmo destino. Sem atualização, fatidicamente você estará no futuro exposto a alguma vulnerabilidade. Se ela for explorável remotamente, ela será, nem que seja para minerar bitcoin no seu roteador. Mas meu roteador é muito lento para minerar bitcoin! Sim, mas ele também pode injetar o minerador nas páginas que você acessar e quem vai minerar será seu computador, celular, TV...

Minha recomendação é "se o hardware não é um limitador, atualize". Se seu roteador não aguenta a nova versão (por questão de espaço), é bom avaliar o que é menos ruim: comprar um novo roteador de R$ 100,00 ou manter seu roteador antigo?

No próximo artigo, algumas dicas do procedimento de atualização. No fundo, o dito para o 17.01 ainda vale.

Se pintar um problema, tem sempre o fórum deste blog. Até a próxima.

OpenWrt: Configurando IPv6 (6 anos depois)

Mais um artigo da série sobre o OpenWrt/LEDE.

O que motivou iniciar o uso do OpenWrt não foi os inúmeros recursos a mais que você pode fazer com ele. O real motivador foi que eu queria usar IPv6 na minha rede. Escrevi sobre isso em 2012. Acho que cabe retomar o assunto.

Na época, o IPv6 no OpenWrt era opcional. As operadoras entregarem IPv6 era lenda urbana, quando não queriam te "vender" o pacote extra IPv6. O acesso IPv6 era coisa de universidade. A única alternativa era criar um túnel (lento) para um broker IPv6. De lá para cá, muita coisa mudou.

Hoje, todas as operadoras que se consideram minimamente significativas oferecem IPv6 a seus clientes. Então, se você não tem IPv6, já sabe o nível da sua operadora. As operadoras já estão com falta de IPv4 faz um tempo, tendo que apelar para técnicas como CGN (NAT na operadora) que, basicamente, coloca uma NAT na frente da sua NAT. O problema é que a sua NAT você tinha um certo nível de controle, podendo abrir/encaminhar portas. Já a NAT da operadora... Isso quebra um monte de coisas que iriam conectar na sua casa (ex: torrent, VPN, Câmera IP...). Se sua operadora tem que usar CGN, mas ao menos entrega IPv6, é a vida. Procure migrar suas coisas para IPv6. Se ela usa CGN mas não entrega IPv6... ela é incompetente. Procure trocar de operadora.

No mundo do OpenWrt, o IPv6 melhorou muito. Hoje em dia, ele vem autoconfigurado para IPv6. O normal é ele funcionando tão bem quanto IPv4, sem a necessidade de qualquer configuração. Não precisa de pacotes extras, ele simplesmente sai funcionando.

Vamos a um básico IPv6. Primeiro, o endereço. O IPv4 usava 32-bit, que dava um pouco mais de 4 bilhões de endereços (2^32). Deste tanto, tinha que tirar algumas faixas reservadas, um tanto para equipamentos intermediários, endereço de rede, broadcast. No fim, temos endereços para bem menos do que 4 bilhões de equipamentos. E com 7 bilhões de pessoas no planeta, isso era insuficiente. No IPv6, o pessoal exagerou e resolveu aumentar de 32-bit para 128-bit. Fica um trambolho deste tamanho:

2001:db8:85a3:8d3:1319:8a2e:370:7348

Cada conjunto separado por ":" tem 16-bit, ou 65536 variações. Com dois destes poderíamos colocar a internet IPv4 inteira (e temos 8 aqui). Como os números começaram a ficar grandes, resolveram usar notação hexadecimal, que inclui os algarismos normais e as letras de A até F. Isto permite usar endereços legíveis engraçadinhos. Caso tenha uma sequência de zeros, usa-se a notação "::", mas somente uma vez no endereço.

Existem variações para endereços especiais, como multicast, link-local, mas no caso geral, o endereço IPv6 pode ser dividido em duas partes, cada uma com 64-bit. No exemplo anterior, seriam as partes verdes e azul. A verde é seu prefixo de rede, que identifica uma rede IPv6 no mundo. A parte azul é o identificador da interface. Para fazer a analogia com  algo que todos têm familiaridade, seria algo assim no IPv4 privado da sua rede atual:

192.168.3.131/24

Então, com IPv4 você normalmente trabalha com redes /24 com 254 endereços "livres". Com IPv6, no mínimo temos 18.446.744.073.709.551.616 (2^64). Para quê tudo isso? Bem, assim você pode usar o endereço MAC da sua placa (48-bit) e obter automaticamente um endereço sem chance de conflito. Esse é o método de obtenção de endereços sem estado (SLAAC). Funciona assim:

equipamento: olá! tem um roteador aí? Eu preciso de uma rede!

roteador: Oi, eu sou o roteador no endereço fe80::1234:1234:3214:1234. Eu ofereço o prefixo de rede 2001:db8:85a3:8d3::/64

E o equipamento começa a usar 2001:db8:85a3:8d3:1319:8a2e:370:7348 usando fe80::1234:1234:3214:1234 como roteador padrão. Sem mais nenhum passo. Sem nenhuma negociação ou confirmação.

Este endereço, apesar de parecer "aleatório", será sempre igual, claro, se mantido o prefixo de rede. Equipamentos mais simples (IoT) podem só funcionar desta forma. E o DNS? Esse pode vir pelo serviço RDNSS, que vem junto com a resposta do roteador. Mas nem todos os clientes e roteadores suportam isso.

E não tem DHCPv6? Tem sim. Ele funciona de uma forma bem parecida com DHCPv4, mas pode tanto gerar os endereços dos clientes da mesma forma que o SLAAC ou da forma tradicional do IPv4: alocando de uma faixa de endereços (que podem ser fixados).

O prefixo de rede ainda pode ser dividido em duas partes: prefixo de roteamento e um identificador de subrede. O prefixo de roteamento é o que identifica todas as redes gerenciadas pelo seu roteador. Então, qualquer rede "acessível globalmente" no seu roteador compartilha essa parte inicial. O que sobra até atingir os 64-bit é usado pelo seu roteador para subdividir a rede em múltiplas redes locais. 

Vamos ao OpenWrt.

Ao ligar o OpenWrt, ele cria aleatoriamente um endereço de rede local (ULA). Sim, o recomendado é ser aleatório mesmo. Esse endereço é um /48 e sempre começa com "fd". Ex:

fdab:1234:1343::/48

Você pode ver (ou modificar) este endereço na aba "network/interfaces", lá no final. Isto seria equivalente a sua rede privada 192.168.1.0/24 do IPv4. Diferentemente do IPv4, eu não recomendo que mude este valor. 

O OpenWrt usa o "prefixo de roteamento" fdab:1234:1343:: e adiciona um identificador de subrede para formar uma rede final, normalmente de tamanho /64, mas pode ser modificado pela opção "ip6assign". E de onde ele pega identificador de subrede? Do campo "ip6hint". Se não definido, ele usa zero. Para o endereço anterior, ficaria:

fdab:1234:1343::/64

Mas é igual? Não! Agora tem um monte de zeros até chegar ao /64. De 48 para 64 são 16-bit ou 4 algarismos/letras em hexadecimal. Seria igual a isso:

fdab:1234:1343:0000::/64

Onde o magenta é o identificador da subrede. Se ele fosse "12", o resultado seria:

fdab:1234:1343:0012::/64

Simples? Por enquanto estamos só na rede local. O DHCPv6 pode ser configurado no mesmo local onde era configurado o IPv4, ao final da edição de cada interface. Lá você pode configurar se o roteador se anunciará como roteador (para SLAAC), se terá DHCPv6 e qual modo de endereços será distribuído pelo DHCPv6: SLAAC, por atribuição ou ambos. 

E como ficariam os endereços de rede? O OpenWrt normalmente usa o identificador de rede ::1 para si. Então, na subrede fdab:1234:1343:123A::/64, ele ficaria com:

fdab:1234:1343:0012::1/64

Mas o "::1" pode ser modificado pelo campo ip6ifaceid. E uma máquina na rede? Se ela tiver o endereço MAC 11:22:33:44:55:66, por SLAAC ela teria o endereço:

fdab:1234:1343:0012:1322:33ff:fe44:5566/64

Note que o MAC sofre uma pequena alteração, mas ele é visível no endereço. E se for por atribuição DHCPv6, será dinâmico (com relativa estabilidade) como no DHCPv4. E se eu quiser fixar? Assim como a interface tem o atributo "ip6ifaceid", a entrada DHCP onde você fixa o IPv4 terá um campo "hostid" (na interface WEB está como "IPv6-Suffix") onde você pode preencher o que quiser lá (até 64-bit ou 16 algarismos hexadecimais). Se for "cafe", o endereço ficaria:

fdab:1234:1343:0012::cafe/64

Pronto. Temos uma rede local que fala IPv6. Isto vai estar disponível em qualquer OpenWrt recente, mesmo que sua operadora não ofereça IPv6. Os endereços fd00::/8 não são (normalmente) roteáveis para a internet. Só devem ser usados dentro da sua rede doméstica ou corporativa.

Agora vamos falar com a Internet.

O básico de um roteador é ter uma interface WAN e uma ou mais LAN. Normalmente o endereço WAN IPv6 é obtido por DHCPv6 (ex: NetVirtua) ou por PPPoE/PPPoA (ex: Oi). Como é um protocolo diferente do IPv4, no OpenWrt é necessário usar uma segunda interface (ex: wan6) que utiliza o mesmo dispositivo físico da wan IPv4. Por padrão, ele já vem com uma wan6 configurada como DHCPv6, que resolve em grande parte dos casos.

O que muda do DHCPv4? Na requisição do DHCPv6, além de pedir um endereço para a interface WAN, existe um pedido de um campo adicional chamado de "prefixo de rede delegada" (Prefix Delegated - PD).  Você receberá da sua operadora um endereço WAN para seu roteador e um prefixo de rede com endereços reais (globais) para distribuir dentro da sua rede. O tamanho do prefixo solicitado pode ser modificado pelo campo "reqprefix", mas as operadoras não vão respeitar mesmo. Você receberá algo como:

IPv6 WAN: 2804:14d:baba:1000::17d7/64

IPv6 prefixo delegado: 2804:14d:baba:1f00::/56

Se a WAN IPv6 utilizar endereço IP fixo, você pode informar a rede delegada manualmente.

O que o OpenWrt faz com isso? O IPv6 WAN é usado para a interface WAN. Ele pode ser, inclusive um /128. Já o prefixo delegado é distribuído para todas as LANs internas. Da mesma forma que ocorreu com a  rede ULA, ele utilizará o prefixo roteado em conjunto com o identificador da subrede para criar prefixos de rede para cada rede interna. No exemplo, a operadora ofereceu um prefixo /56 (ex: Oi ADSL residencial), que permitiria subdividi-lo em 256 redes. É o suficiente para uma residência ou mesmo para um pequeno negócio.

( Bem, tem algumas operadoras que entregam apenas um /64 para seus clientes. Sim NetVirtua, estou apontando para você. Pode ser trauma da escassez de IPv4 mas não se justifica no mundo IPv6. Até a Oi, que normalmente não é usada como bom exemplo, oferece uma rede /56. Com uma rede /64, eu não tenho espaço para subdividir a rede em múltiplas redes LAN e ainda usar SLAAC. Isto quer dizer que não tenho como criar uma segunda LAN com IPv6. Mas quem precisa de duas LAN? Isso é coisa de empresa! Claro, o vizinho que eventualmente fez uma visita e precisou conectar na Wifi aqui em casa jamais irá enviar um vídeo por engano ao meu Chromecast, nem mesmo irá olhar sem querer na babá eletrônica... realmente a segunda rede é desnecessária. Não preciso dizer qual foi a resposta do Call Center da Net. Mas voltando... )

Com as redes do exemplo, a LAN do roteador passa a ter estes dois endereços:

fdab:1234:1343:0012::1/64

2804:14d:baba:1f12::1/64

E a máquina que tem o endereço MAC 11:22:33:44:55:66? Se usar tanto o SLAAC como o sufixo "cafe", teremos todos estes endereços configurados:

fdab:1234:1343:0012:1322:33ff:fe44:5566/64

fdab:1234:1343:0012::cafe/64

2804:14d:baba:1f12:1322:33ff:fe44:5566/64

2804:14d:baba:1f12::cafe/64

E para cada outra LAN no roteador, basta configurar o campo ip6hint dela com um identificador diferente das demais LAN e ela receberá seu cunhão de endereços automaticamente.

E se não tiver espaço para uma segunda LAN? O que posso fazer? E se minha operadora não entregar um prefixo delegado? Infelizmente, ainda temos a alternativa de usar NAT66 (NAT entre duas redes IPv6).

Beleza. Acabei de olhar a interface do meu computador e tem esses quatro endereços aí e mais um monte! Sim, temos ainda endereços usados apenas no contexto do enlace local (link-local), que começam com "fe80". Ele seria equivalente ao famigerado 169.254.0.0/24 do IPv4.

fe80::1322:33ff:fe44:5566/64

Este endereço normalmente nem responde aos serviços de rede normais. Ele é usado para as tarefas administrativas do IPv6, como encontrar um outro equipamento na mesma rede ou o seu roteador. É necessário.

Mas tenho muito mais endereços! Bem, o endereço MAC não é algo muito "mutável" nas máquinas. Como ele começou a fazer parte do endereço visível na internet, ficou fácil rastrear os equipamentos que usam SLAAC. Mesmo que você mude o prefixo, o final sempre será o mesmo. Com isso você obtem o MAC e individualiza o computador. Solução? Uma extensão de privacidade. Além de todos os endereços listados anteriormente, a máquina pode periodicamente criar novos endereços com o identificador de interface (parte verde) aleatória. Quando usada a extensão de privacidade, o endereço SLAAC fixo é usado para receber conexões que queiram se conectar no computador enquanto os endereços aleatórios são usados pelo computador para acessar serviços remotos. Depois de um tempo, o endereço aleatório é desativado e outro é criado. Com isso, o serviço remoto não tem como rastrear o equipamento apenas pelo endereço de origem. Se deixar um computador que usa a extensão de privacidade muito tempo ligado, é normal ver uma lista mais de uma dezena de endereços IPv6.

E tem mais assuntos IPv6? Tem! Firewall IPv6, NAT66 (sim, NAT para IPv6 as vezes é necessário), multihoming (duas WANs), VPN sobre IPv6, e assim por diante. Mas isso fica para outro artigo.

Se pintar uma dúvida, temos o fórum.

Até a próxima.

OpenWrt/LEDE: fazendo seus backups no roteador (e distribuindo-os): parte 3

Mais um artigo da série sobre o OpenWrt/LEDE. 

No primeiro artigo deste tema, comentei o que uma solução de backup deveria ter. Passei pela solução que usava anteriormente (crashplan) e uma brevíssima introdução aos recursos do borg. Depois apresentei a configuração do backup em um HD externo no seu roteador. Neste artigo, iremos implementar a sincronia entre repositórios.

Só relembrando, esse é o esquema do backup:

O computador roda o borg e copia os arquivos (amarelo) para um repositório no roteador. Esse repositório é acessado por CIFS e aponta para um HD externo conectado na USB. Em um segundo momento, um rsync sincroniza esse repositório com um destino remoto utilizando o rsync. O destino remoto também é um roteador com um HD externo conectado, mas poderia ser qualquer destino com suporte a rsync. A comunicação do rsync é feita dentro de uma VPN, que interliga o roteador de origem e destino do repositório.

Este artigo aborda a parte verde do diagrama.

Sincronizando repositórios

Já ouvi a estória do "eu tinha backup, mas perdi junto". Incêndio, roubo, descarga elétrica durante o backup, não são se preocupar em "não queimar" o HD externo do seu backup. E o backup parece ter um certo magnetismo que o atrai para próximo da fonte original da informação, em especial antes de eventos catastróficos.

Como já havia comentado na parte 1 deste assunto, distribuir geograficamente o backup de forma automatizada era um requisito. A opção foi utilizando o rsync sobre uma VPN, onde o repositório do backup, conectado no roteador (que sempre está ligado), é enviado lentamente para um outro armazenamento remoto, também conectado em outro roteador (que sempre está ligado).

A parte da VPN é assunto antigo. O rsync pode ser feito pelo SSH, com autenticação por chaves. Porém, isso exige um certo grau de confiança da ponta remota pois as mesmas chaves podem abrir uma sessão no roteador remoto. Outra opção é um serviço rsyncd. Apesar de não ter autenticação, você pode controlar pelo firewall e pela restrição do próprio rsyncd quem pode acessar esse serviço. Se somente o teu roteador puder conectar no roteador remoto, só você poderá apagar algo indevidamente.

No roteador que receberá a cópia:

roteador-remoto# opkg update

roteador-remoto# opkg install rsyncd

A configuração não foi UCIficada e deve ser feita diretamente em /etc/rsyncd.conf. Só adicionar:

/etc/rsyncd.conf:

(...)

[fulano@gmail.com]

path = /mnt/HD-externo-XYZ/backup/borg/fulano@gmail.com
read only = no
fake super = yes

O identificador fulano@gmail.com é arbitrário. Eu gosto de usá-lo pois o repositório normalmente terá mais de um cliente. E nada melhor do que o email para lembrar o nome do repositório. 

Agora, basta ativar e disparar o serviço:

roteador-remoto# /etc/init.d/rsyncd enable

roteador-remoto# /etc/init.d/rsyncd start

Opcionalmente, se já estiver usando o xinetd (por exemplo, para o scanner na rede - SANE), pode também usar o xinetd ao invés do serviço rsyncd:

service rsync 

{

disable = no

socket_type = stream

port = 873

protocol = tcp

wait = no

user = root

server = /usr/bin/rsync

server_args = --daemon

log_on_failure += USERID

}

E falta, agora, somente a rotina que envia do meu roteador-local para o roteador-remoto.

rsync --bwlimit=30k --partial --archive --delete --delay-updates --delete-after  /mnt/HD-externo-abc/borg/ roteador-remoto::fulano@gmail.com/

E se usar por cima do SSH:

rsync --bwlimit=30k --partial --archive --delete --delay-updates --delete-after  /mnt/HD-externo-abc/borg/ roteador-remoto:/mnt/HD-externo-XYZ/backup/borg/fulano@gmail.com/

A primeira opção --bwlimit limita a taxa de transferência para o rsync. Ajuste para sua realidade. Como eventualmente teremos múltiplos gigabytes para serem enviados, o processo pode durar dias. A recomendação é sempre deixar um tanto para outros fins. O --partial permite continuar o envio quando a conexão foi perdida. Eu gosto de usar o --delay-updates --delete-after para manter o repositório íntegro durante a cópia. Se espaço for um problema do outro lado e ele não aguentar armazenar a mais a diferença a ser enviada, pode usar o --inplace e --delete-before. E sempre, man é seu amigo.

Agora é só colocar na cron. Como o processo pode rodar "por dias", é importante que ele não volte a rodar se o rsync anterior ainda estiver em execução. Por isso, podemos melhorar o comando usando o comando "lock":

lock -n /tmp/rsync.lock && { bwlimit=30k --partial --archive --delete --delay-updates --delete-after  /mnt/HD-externo-abc/borg/ roteador-remoto::fulano@gmail.com/; lock -u /tmp/rsync.lock; }

Se rodar novamente este comando enquanto a execução anterior ainda estiver em curso, você vai receber um:

Can't lock /tmp/rsync.lock

E, como esperado, não teremos dois rsync em execução.

No OpenWrt, não temos os /etc/cron.* que usamos no Linux. Sendo assim, temos que usar o bom e velho 'crontab -e'. Para rodar todos os dias 1 AM:

0 1 * * * lock -n /tmp/rsync.lock && { bwlimit=30k --partial --archive --delete --delay-updates --delete-after  /mnt/HD-externo-abc/borg/ roteador-remoto::fulano@gmail.com/; lock -u /tmp/rsync.lock; }

Outra funcionalidade interessante é abortar o processo quando ele demorar muito tempo. Assim você pode manter a rotina apenas durante a madrugada. Todavia, isso só faz sentido se usar a opção "--partial". Bem, a partir deste ponto, a linha do comando vai ficar muito longa, mesmo por um costumas one-liner. É hora de fazer um script:

#!/bin/sh
# Sincroniza repositorio local com remoto
#
RSYNC_TIMEOUT=${1:?Informe o tempo maximo em segundos deste script}; shift
REPO_LOCAL=${1:?Informe o repositorio local}; shift
REPO_REMOTE=${1:?Informe o repositorio remoto}; shift
REPO_LOCK=/tmp/rsync-remote.lock

lock -n "$REPO_LOCK" || {
echo "Falha ao obter lock! Existe um rsync-backup rodando?" >&2
exit 1
}
trap "lock -u '$REPO_LOCK'" EXIT

rsync --archive --partial --delete --delay-updates --delete-after "$@" "$REPO_LOCAL" "$REPO_REMOTE" &
pid_rsync="$!"
(sleep $RSYNC_TIMEOUT; echo "Estouro de tempo ($RSYNC_TIMEOUT segundos)" >&2; kill -TERM $pid_rsync) &
pid_timeout="$!"
# Deveria ser kill -TERM -$pid_timeout... mas com o ash nao fuciona ainda
trap "lock -u '$REPO_LOCK'; kill -TERM $pid_timeout $pid_rsync 2>/dev/null" EXIT
wait $pid_rsync
err=$?
exit $err

Que ficaria na cron assim:

#  Roda todos os dias 1AM por 6 horas (21600 segundos)
0 1 * * * /caminho/para/rsync-backup.sh 21600 /mnt/HD-externo-abc/borg/ roteador-remoto::fulano@gmail.com/

E é isso. Agora você já tem um mecanismo de sincronia dos backups.

Recuperando dados

Primeiro, vamos imaginar o cenário onde você precisa recuperar os dados do repositório remoto. Você deve ter perdido os dados principais e também seu backup local. Nesta situação, é provável que você nem tenha mais o seu computador para recuperar os dados.

A primeira alternativa de recuperação é ir fisicamente onde o backup remoto está e copiar o repositório. O melhor seria primeiro reconstruir seu repositório local e depois recuperar o que você quiser com calma a partir dele.

Se o acesso físico for complicado, você pode simplesmente reconstruir seu repositório local fazendo um rsync inverso, como origem o repositório remoto e destino um caminho local. Vai demorar mas funciona.

Por fim, se precisar apenas de uma ou outra coisa, eu recomendaria testar a montagem remota em cima de rsync, como em fuse-rsync. Não testei mas deve funcionar perfeitamente.

Ah, e não se esqueça que você sempre precisa ter acesso a chave ou a senha usada na criação do repositório. E isso sem depender do próprio backup ;-)

Se pintar uma dúvida, tem sempre o fórum deste blog. Até a próxima.