O openssh recebe patches periodicamente, pois novas falhas e formas de ataque são descobertas.
O ssh abreto apra qualquer ip na rede pública não é uma idéia saudavel.
Pelo menos restrinja a faixa de ips que podem conextar.
[TÓPICO DEDICADO] Redes Modulares, Roteadores e mini roteadores de Alta Performance - NanoPi, Raspberry Pi, Orange Pi, Banana Pi, x86 e etc.
- Iniciador de Tópicos xShARkx
- Data de Início
O ssh abreto apra qualquer ip na rede pública não é uma idéia saudavel.
Pelo menos restrinja a faixa de ips que podem conextar.
Eu costumo atualizar meu sistema semanalmente, então acho que as chances de acesso por falha são pequenas.
Mas vou restringir a faixa de IPs sim, não é como se eu acessasse de fora do país de todo jeito.
Sim, E boa parte dos ataques/scans vem de ips do oriente ( china etc )
Sim e é por isso que eu falei que um ban ip ajustadinho bloqueia 99% kkkk Só bloquear a china.
Dica simples para os neuróticos: knockd
[OpenWrt Wiki] Port knocking server knockd
Pessoal, comprei um mini pc inspirado no modelo comprado pelo @RiX inclusive na mesma loja que aparece no print dele, no dia 14/02 e até agora, 4 dias depois, ainda não foi enviado. Estou pensando em cancelar e comprar de outro fornecedor. Vocês que compram esse tipo de equipamento usualmente no aliexpress, é normal essa demora para envio de mini pc? Quando compro produtos normais, como cabos, carregadores, etc, o envio costuma ocorrer no dia seguinte.
Eu e o @Arris compramos um NanoPi e o cara demorou quase uma semana para postar.
Vai depender de vendedor para vendedor, igual comprar no MercadoLivre.
Eu não sei porque os vendedores estão demorando para enviar coisas eletrônicas desse tipo, talvez seja devido a escassez de eletrônicos que temos enfrentado? O meu ax3600 demorou 14 dias corridos para o vendedor na china postar ele.
O jeito é esperar e mandar mensagem para o vendedor depois de 5 dias uteis e ver o que ele fala.
Última edição:
Comprei um swtich também esses dias e demoraram para postar, essas ultimas semanas estão assim mais demorado mesmo
É porque esperam juntar uma certa quantidade para realizar a coleta.
Grandes vendedores tem coletas diárias, ai é aquele china que voce compra hoje, 4 horas depois já está despachado.
Ainda analisando se vale a pena ficar com dois links, claro+ provedor de quintal.
Por enquanto conectei tudo LAN, WAN, modem Claro e provedor local em um HUB de 8 portas não gerenciável e direcionei o tráfego dos downloads via VPN para a Claro nas static routes do openwrt.
Tentei criar umas macvlans, mas não funcionou.
Por enquanto conectei tudo LAN, WAN, modem Claro e provedor local em um HUB de 8 portas não gerenciável e direcionei o tráfego dos downloads via VPN para a Claro nas static routes do openwrt.
Tentei criar umas macvlans, mas não funcionou.
E aí, alguma novidade do seu nanopi? O meu foi liberado hoje da aduana sem taxa
Friendlywrt já instalado no SD e apenas aguardando para plugar no bicho
No site do correios consta que só foi recebido, porém no site do ali fala assim "Processo de desembaraço aduaneiro iniciado".E aí, alguma novidade do seu nanopi? O meu foi liberado hoje da aduana sem taxa
Friendlywrt já instalado no SD e apenas aguardando para plugar no bicho
Como está o rastreamento pelo Aliexpress:
No site do correios:
Na hora que liberar é rápidão, a fonte de 5V 4A chegou em 4 dias após a liberação da Aduana.
Por volta de abril então teremos o openwrt 22.0X:
Portanto nessa versão 22.0X o NanoPi R4S vai adentrar a versão estável do openwrt e com isso quem quiser vai poder fazer a build da stable para o R4S direto do source do openwrt, ou seja, build 100% limpa e 100% customizada do jeito que a pessoa quiser(pacotes, patchs, drivers e afins).
Digo build limpa pois a build da friendly arm que é o friendly wrt é estável, porém, vem com várias coisas que acabam não sendo usadas, pelo menos não por mim! Como aqueles trocentos pacotes de linguagens, drivers para placas de rede wifi usb e outro pacotes do tipo.
OpenWrt 22.0X release plan
lists.openwrt.org
Portanto nessa versão 22.0X o NanoPi R4S vai adentrar a versão estável do openwrt e com isso quem quiser vai poder fazer a build da stable para o R4S direto do source do openwrt, ou seja, build 100% limpa e 100% customizada do jeito que a pessoa quiser(pacotes, patchs, drivers e afins).
Digo build limpa pois a build da friendly arm que é o friendly wrt é estável, porém, vem com várias coisas que acabam não sendo usadas, pelo menos não por mim! Como aqueles trocentos pacotes de linguagens, drivers para placas de rede wifi usb e outro pacotes do tipo.
Vi muitos usuários no reddit recomendando essa build ao invés da friendlyarm
github.com
GitHub - quintus-lab/openwrt-rockchip: OpenWRT Official master source code + CTCGFW & Lean's packages code
OpenWRT Official master source code + CTCGFW & Lean's packages code - GitHub - quintus-lab/openwrt-rockchip: OpenWRT Official master source code + CTCGFW & Lean's packages code
github.com
Shark, de novo, vou aproveitar o gancho...
Estou usando o Nano com OpenWrt mas fiquei interessado no pfSense pelo firewall e plugins de segurança, pelo que eu pesquisei pfSense usa mais processador e o suporte Cake não é tão bom.
Pensei em pegar o x86 e cascatear, deixar o X86 pro pfSense como firewall e o Nano com Cake ou você teria alguma sugestão?
sempre fui interessado no pfsense, mas nao tenho o hardware.
Quais plugins do pfsense vc se refere?
Liberou o meu às 18:53 hoje sem o cafezinho pro presidente rsrs, acho que até sexta feira chega.E aí, alguma novidade do seu nanopi? O meu foi liberado hoje da aduana sem taxa
Friendlywrt já instalado no SD e apenas aguardando para plugar no bicho
Sei la para ser sincero rsrsrs
No meu caso eu não vejo a necessidade disso! Para mim o firewall do openwrt é excelente + adicionando um banip bem configuradinho me parece ser bem mais do que suficiente no caso se a rede for doméstica já que com o banip vc facilmente bloqueia 99% dos ips de onde vem grande parte dos ataques na internet... E também existem trocentos outros pacotes que complementam o firewall no openwrt como aqueles de analise de pacotes em tempo real entre outros com outras funções como foi falado aqui.
Fora que eles estão mudando o firewall do openwrt do "firewall3" para o "firewall4", ou seja, estão saindo do iptables e indo para o nftables na versão 22.0X e é por isso que no momento eu ficou usando ou a build da friendly arm ou a build do https://github.com/anaelorlinski/OpenWrt-NanoPi-R2S-R4S-Builds, ao invés das snapshots com openwrt ''limpo'' pois tem que fazer certas edições para voltar ao firewall3 pois tem muito pacote incompatível com o firewall4 ainda. Fora que snapshot não é para ser estável é build de dev. No caso da build do anaelorlinski, eu estou editando um fork para a minha necessidade, ou seja, adicionando mais pacotes e agora vou adicionar alguns patchs tbm. Só fiz coisa básica até agora
No caso eu tenho 2 cartões SD aqui, essa é a beleza de um dispositivo como nano que usa cartão SD, tu simplesmente pode ter um cartão SD configuradinho e redondinho e um cartão SD para tu brincar com outras builds, patchs, pacotes e afins, sem se preocupar em fuder algo, brickar algo, ter que refazer config do zero e etc! Ou seja, fez o swap do cartão sd? Tudo volta como era antes em menos de 1 min, recomendo a galera ter sempre um cartão SD extra como copia do seu principal depois que tu reconfigurar ele! Pois assim nunca mais tu tem que reconfigurar algo do zero caso de alguma merda, basta fazer o swap de cartão sd kkkk
Eu acho que dois dispositivos desse naipe(ou seja, ambos os sistemas são excelentes) na mesma rede para cuidar de uma coisa só cada um, me parece ser "overkill"! Porém, se um só não está te atendendo ou caso vc veja necessidade ou só porque vc quer mesmo, então vai fundo e seja feliz
Eu sei que se eu visse a necessidade de tal conjunto, ou se eu simplesmente eu quisesse ter os dois ou mexer no pfsense também, eu iria fundo. 
Agora com eu falei, x86 para mim é o suprassumo dos roteadores e um roteador x86 vai ser o meu proximo roteador! Só não peguei um a invés de NanoPi R4S devido ao excelente CxB do nano + testes que vi + a minha necessidade atualmente e a médio prazo... Ou seja, o nano está sobrando aqui.
Sei la, essa build é abandonada rsrs... Vc checou as datas dos posts no reddit? Pois pelo o que eu pude ver, essas builds do quintus eram populares devido a elas serem a unica alternativa a build do fabricante do nano na epoca em que ele foi lançado e antes do commit para o master branch do openwrt do R4S.Vi muitos usuários no reddit recomendando essa build ao invés da friendlyarm
GitHub - quintus-lab/openwrt-rockchip: OpenWRT Official master source code + CTCGFW & Lean's packages code
OpenWRT Official master source code + CTCGFW & Lean's packages code - GitHub - quintus-lab/openwrt-rockchip: OpenWRT Official master source code + CTCGFW & Lean's packages code
Se vc tem curiosidade de testar essa build dele, então eu iria de https://github.com/anaelorlinski/OpenWrt-NanoPi-R2S-R4S-Builds, pois é baseada na build do quintus porém, com o desenvolvimento ainda ativo.
OBS: A build da friendly arm não é ruim, muito pelo contrário é muito boa e estável, porém, eu prefiro ter uma coisa mais limpa e configurada com a necessidade daquilo que eu preciso do que uma build feita para o publico em geral que contem coisas que eu não irei utilizar e é por isso que eu aguardo ansiosamente a versão 22.0X do openwrt, que ai a gente vai ter acesso a estável do openwrt oficialmente para o R4S.
Queria muito era ver o desempenho desse Pi aqui:
BananaPi BPI-M2S with Amlogic A311D/S922x，support 2 gigabit network port-Banana Pi open source hardware community,Single board computer, Router,IoT,STEM education
BananaPi BPI-M2S new design with Amlogic A311D Quad core ARM Cortex-A73 and dual core ARM Cortex-A53 CPU ,ARM G52 MP4(6EE) GPU,NPU for AI at 5.0 TOPS, support Camera and MIPI-CSI interface ,HDMI output,2 Gigabit port . 4G RAM and 16 GB eMMC flash
www.banana-pi.org
Bate fácil o R4S com esse CPU ai. Imagina 4 cores a73 para IRQ + queues e 2 cores A53 para docker? Top demais.
E queria que a friendly arm fizesse um Pi com esse CPU, pois entre os fabricante de Pi a friendly arm parece ser a que mais capricha no seu hardware junto com as cases de metal de alta qualidade e além de ter um preço razoável.
Última edição:
Eu recebi aqui o nanopi e achei que a interface esta meio diferente do que vi em alguns prints sei lá.
Ativei o sqm qos na eth0 que é a wan. Está correto?
Configurei a entrada e saída porém a conexão de download ficou capada em 300 e poucos mb
Mais tarde continuo fazendo testes pra tentar resolver isso
Também achei estranho que fica ali um aviso ATUALIZANDO pra sempre...
Ativei o sqm qos na eth0 que é a wan. Está correto?
Configurei a entrada e saída porém a conexão de download ficou capada em 300 e poucos mb
Mais tarde continuo fazendo testes pra tentar resolver isso
Também achei estranho que fica ali um aviso ATUALIZANDO pra sempre...
Então o luci que é a interface do openwrt suporta temas:
Basta it em system -> software e dar um update lists
Depois disso tu filtra por luci-theme, só que no caso do tema argon vc tem que baixar no github os ipk(do tema e de config do tema) e instalar eles usando o botão upload package igual eu destaquei no print acima.
GitHub - jerrykuku/luci-theme-argon: Argon is a clean and tidy OpenWrt LuCI theme that allows users to customize their login interface with images or videos. It also supports automatic and manual switching between light and dark modes.
Argon is a clean and tidy OpenWrt LuCI theme that allows users to customize their login interface with images or videos. It also supports automatic and manual switching between light and dark mod...
github.com
Tenta deixar no ETH1 para ver. Tira um print do setup tbm.Ativei o sqm qos na eth0 que é a wan. Está correto?
Configurei a entrada e saída porém a conexão de download ficou capada em 300 e poucos mb
Mais tarde continuo fazendo testes pra tentar resolver isso
No topo direito? No caso ele está dando refresh na interface
Última edição:
Então o luci que é a interface do openwrt suporta temas:
Basta it em system -> software e dar um update lists
Depois disso tu filtra por luci-theme, só que no caso do tema argon vc tem que baixar no github os ipk(do tema e de config do tema) e instalar eles usando o botão upload package igual eu destaquei no print acima.
GitHub - jerrykuku/luci-theme-argon: Argon is a clean and tidy OpenWrt LuCI theme that allows users to customize their login interface with images or videos. It also supports automatic and manual switching between light and dark modes.
Argon is a clean and tidy OpenWrt LuCI theme that allows users to customize their login interface with images or videos. It also supports automatic and manual switching between light and dark mod...
Tenta deixar no ETH1 para ver. Tira um print do setup tbm.
No topo direito? No caso ele está dando refresh na interface
Parece estar topando o cpu1 usando eth0. Sem link layer adaptation
Eth1 sem link layer adaptation
Eth1 com link layer adaptation
Configurei pra 450M/35M Link 500/35. Porém ainda está bem forte o bufferbloat e um dos núcleos está batendo 90% de uso durante o teste, não esperava por isso...
Última edição:
Não, está certo não...Parece estar topando o cpu1 usando eth0. Sem link layer adaptation
Eth1 sem link layer adaptation
Não cheguei a usar essa ultima build do friendly wrt não, deixa eu fazer uns testes aqui com a afinidade do cpu com essa ultima build. Pois no primeiro teste ele está saturando apenas um dos núcleos a53 com a queues e o IRQ.
eu postei mais um teste ali pra vc ver no post antigo.
Mesmo colocando no eth1 no teste do bufferbloat bate 90%
Vou instalar aquele outro do github que você disse ali. Talvez resolva.
Testei aqui e tive o mesmo resultado que vc, ou seja, o cpu affinity está cagado nessa ultima build deles, seja por alguma coisa que eles fizeram ou devido a um update no pacote do sqm.
Joguei as queues nos nucleos A72 e ficou bom:
#eth0 queue no cores A72
echo 30 > /sys/class/net/eth0/queues/rx-0/rps_cpus
#eth1 queue nos cores A72 cores
echo 30 > /sys/class/net/eth1/queues/rx-0/rps_cpus