Jefferson, 26 de novembro de 2021, Redes, vpn Este texto vai servir de suporte a outros textos que estou preparando sobre o OpenVPN.
O Easy-RSA pode ser baixado e instalado como um programa independente ou como parte de uma instalação completa do OpenVPN para Windows. Se instalou junto com o OpenVPN, mova a pasta C:\Arquivos de Programas\OpenVPN\easy-rsa para c:\easy-rsa. Isso é necessário porque Easy-RSA tem um bug que o faz falhar se o caminho tiver espaços. Se esta pasta não existir, você provavelmente não escolheu todas as opções na instalação customizada do OpenVPN. Esta pasta é instalada ao habilitar a opção “Easy RSA 3 Certificate…”.
A máquina onde são criados os certificados pode ser completamente distinta da que vai usá-los. Eu poderia criar aqui e passar para qualquer um que pedisse, que funcionaria do mesmo jeito.
O arquivo vars
Ainda usando o explorer, renomeie o aquivo “vars.example” como “vars” (remova a extensão)
Esse arquivo possui a configuração que vai ser usada por Easy-RSA para gerar os certificados. Você não precisa mexer em nada se não quiser mudar o default. Vale a pena dar uma olhada nele com um editor compatível com quebras de linhas unix (como o Notepad++) para ver as opções disponíveis. Duas configurações candidatas a personalização são os prazos de validade, mas você não precisa realmente alterar nada para que funcione para o propósito deste texto.
# In how many days should the root CA key expire?# In how many days should the root CA key expire?
#set_var EASYRSA_CA_EXPIRE 3650
# In how many days should certificates expire?
#set_var EASYRSA_CERT_EXPIRE 825
Você precisa remover o # do início de cada linha que você editar.
Criando os certificados
Abra um prompt de comando como administrador e execute EasyRSA-Start.bat. Nos meus testes clicar com o botão direito no .bat e pedir pra executar como administrador não bastou (o programa pisca e fecha). Foi preciso abrir um prompt primeiro.
No shell que se abre você vai executar os seguintes comandos em sequência:
./easyrsa init-pki
./easyrsa build-ca
./easyrsa build-server-full nome_do_certificado_servidor
./easyrsa build-client-full nome_do_certificado_cliente
./easyrsa gen-dh
Mas você vai ter que responder algumas perguntas durante o processo, por isso vou mostrar passo a passo tudo o que acontece e onde você precisa responder. Vamos supor que o certificado servidor tenha o nome “servidor-vpn” e que o cliente tenha o nome “cliente-vpn”. Os comandos ficam assim:
./easyrsa init-pki
./easyrsa build-ca
Se ocorrer o erro “extra arguments given” após digitar a senha duas vezes, você provavelmente não seguiu minha recomendação de mover a pasta para c:\easy-rsa.
A digitação de senhas em todos os passos é feita às cegas. Parece que o programa está travado, mas não está.
./easyrsa build-server-full servidor-vpn
./easyrsa build-client-full cliente-vpn
./easyrsa gen-dh
Feche o prompt de comando.
Copie os certificados criados (em c:\easy-rsa\pki\issued\*.crt)
e suas chaves (em c:\easy-rsa\pki\private\*.key) exceto a chave do certificado CA, que nunca deve ser divulgada.
Você precisa copiar também ca.crt e dh.pem. Ambos de C:\easy-rsa\pki\.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 26 de novembro de 2021, Redes, vpn Este texto servirá de suporte a outros textos que estou elaborando e meu foco é a implementação de VPNs (realmente) particulares e gratuitas. Não vou tratar aqui de serviços profissionais pagos.
Considere que este texto está em rascunho. Muita coisa pode mudar por estar errado, incompleto, ou eu decidir redigir de outra forma; mas eu tentarei avisar sobre as mudanças nos comentários.
Meu primeiro contato com VPNs foi com um cliente que comecei a atender em 2019. A empresa tinha a matriz com todos os servidores em uma cidade e a filial em outra. Em cada ponta uma conexão com a internet e um computador rodando PFsense que agia como gateway VPN. Havendo internet nas duas pontas as máquinas PFsense estabeleciam um “túnel” ligando as redes das duas localidades, para todos os efeitos práticos como se existisse um cabo realmente longo ligando as duas. Isso permitia coisas interessantes, sem que nenhuma aplicação tenha sido feita com isso em mente:
- Os “busca preço” (aqueles terminais com leitor de código de barras disponibilizados para clientes) na loja obtinham o preço atualizado de cada produto consultando no servidor na outra cidade;
- Cada funcionário do administrativo trabalhava o dia inteiro no servidor remoto, cada um usando uma conexão RDP;
- De qualquer uma das pontas eu podia administrar roteadores e outros dispositivos de rede da outra simplesmente digitando o endereço IP correspondente no navegador.
Nesse ponto você pode estar pensando: “não preciso de VPN para fazer nada disso”. Não, não precisa mesmo. Você pode criar acessos individuais para cada um desses usos e encaminhar portas no roteador para eles. Mas além de você precisar saber precisamente que portas precisa encaminhar em cada aplicação (que porta o busca preço usa?), rapidamente fica muito inconveniente administrar isso. Por exemplo, cada interface web de roteador e impressora de rede por default usa a porta 80, mas você não pode ter duas aplicações usando a mesma porta de entrada no roteador. Para poder ter acesso simultâneo a cada um dos dispositivos precisa arbitrar novas portas e encaminhar de acordo*. Por exemplo, dispositivos que você acessaria assim de qualquer lado de uma VPN:
- http://10.129.40.100
- http://10.129.40.130
- http://10.129.40.147
- http://10.129.40.168
- …
Sem VPN vai continuar acessando assim localmente mas vai ter que acessar da ponta remota com algo assim (um encaminhamento diferente no roteador para cada):
- http://matriz-olinda.dyndns.org
- http://matriz-olinda.dyndns.org:3070
- http://matriz-olinda.dyndns.org:3071
- http://matriz-olinda.dyndns.org:3072
- …
E o problema se repete na outra direção.
(*) Se seu roteador suportar uma porta externa diferente da interna no encaminhamento. Se não suportar você vai ter que mudar as portas default nos dispositivos e aí a complicação sobe a outro nível.
Ainda temos o problema da segurança. Qualquer indivíduo fazendo um portscan no endereço IP referente a matriz-olinda.dyndns.org vai eventualmente encontrar as portas abertas por mais que você tente obfuscar usando números de porta incomuns (só existem 65536 possibilidades). Além do fato de que o provedor de acesso em cada ponta pode bisbilhotar todo o tráfego que não seja naturalmente criptografado.
Quando você usa uma VPN apenas uma porta precisa ser encaminhada no roteador. Dentro do túnel suas aplicações podem usar as portas que queiram sem você estar nem ciente de quais são. E mesmo que você não criptografe o túnel, bisbilhotar no seu tráfego ou fazer um portscan para saber que portas estão abertas requer outro nível de conhecimento e acesso à sua rede.
E quando eu finalmente entendi como a configuração OpenVPN nos PFSense funcionava, a flexibilidade alcançou outro nível. Instalei clientes OpenVPN no meu desktop em casa e no notebook e com dois cliques eu podia estabelecer uma conexão de onde eu estivesse e trabalhar como se estivesse dentro da empresa. Administrar a coisa toda ficou muito mais fácil. Eu pude até desenvolver um software de consulta de preços acessando o servidor Winthor do cliente como se ele estivesse na minha casa.
Então só tem vantagens?
Não. A principal desvantagem é a complexidade para instalar e configurar a VPN (pelo menos usando opções gratuitas). Começa apenas “bem pouco amigável” e vai crescendo em complicação dependendo do seu objetivo. Uma vez que você consiga, basta salvar as configurações das duas pontas que refazer se torna muito fácil. Mas chegar a esse ponto pode ser uma luta. Eu pretendo criar uma série de textos explicando como fazer isso para diversos cenários, detalhando as armadilhas em que caí no caminho.
Por que não usar software de controle remoto como Anydesk e Teamviewer?
VPN e controle remoto resolvem problemas distintos e na maioria das vezes você vai usar ambos. Implementar uma VPN não vai necessariamente fazer você deixar de precisar do controle remoto.
Vantagens da VPN:
- Para monitorar de casa quem está conectado ao roteador Wi-Fi da empresa, por exemplo, com o Anydesk você precisa fazer uma conexão Anydesk a uma das máquinas da empresa que ninguém esteja usando, abrir um navegador e acessar a Web UI do roteador. Com uma VPN estabelecida você pode ter o endereço do roteador na empresa como um favorito no seu navegador em casa e clicar nele. E isso fica muito mais ágil mesmo em conexões lentas porque o que está trafegando pela internet até sua casa são as páginas do roteador e não a imagem do computador remoto;
- Também com o anydesk você pode acessar um computador remoto para trabalhar nele, mas outra pessoa não pode fazer isso ao mesmo tempo. Usando uma VPN você pode em muitas situações levar o seu computador da empresa para casa, estabelecer a conexão com o servidor no escritório e trabalhar como se não tivesse saído de lá. Isso nem sempre é verdade pois aplicações que fazem uso desleixado dos recursos de rede podem ficar extremamente lentas se o tráfego tiver que ocorrer via internet;
- Dá medo pensar no desastre global que seria se um dia um zeroday for descoberto no anydesk/teamviewer que permita login sem precisar da senha. Até descobrirem e disponibilizarem um patch (e todo mundo aplicar) o estrago vai ser grande;
- Você não depende de que mais um serviço de terceiros esteja funcionando. Eu já precisei ter que esperar os servidores anydesk voltarem a funcionar para poder fazer um acesso remoto;
- Os softwares de controle remoto somente são gratuitos de verdade para uso doméstico. E o custo só é realmente barato num aplicação “um para muitos” (uma pessoa apenas acessando muitos computadores).
Vantagens do controle remoto:
- Como o próprio nome diz, VPN não é para controle remoto. Você não pode ver o que outro usuário está fazendo ou mostrar a ele como se faz algo usando (apenas) uma VPN;
- A facilidade com que você instala e usa o anydesk/teamviewer é extraordinária;
- Você pode transferir arquivos entre máquinas com extrema facilidade.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 15 de novembro de 2021, Redes O papelão com o Intelbras SF800 VLAN Ultra me lembrou que já havia passado da hora de me familiarizar com VLANs. Procurando opções de switch gerenciável (normalmente o tipo de switch que suporta VLANs) no ML me deparei com um anúncio por um preço surpreendentemente baixo para as características do produto, pois enquanto a maioria dos switchs gerenciáveis de 24 portas custa mais de R$1000, este estava custando apenas R$436 com NFe (você encontra mais barato sem nota) e ainda tinha quatro portas gigabit (total de 28 portas). A existência de portas gigabit era um diferencial grande, que me permitiria aproveitar o switch em mais aplicações.
Quando pesquisei sobre o modelo na internet descobri a razão do preço baixo: o modelo saiu de linha há anos e provavelmente era um produto usado sendo vendido como novo. Não é novidade mas parece ter acontecido muito mais ultimamente.
Como o ML oferece uma garantia de devolução de sete dias para eletrônicos decidi arriscar. Estava preparado para examinar o switch com uma lupa, procurando pelos sinais de uso como poeira e oxidação nas portas. Não estava preparado para o que recebi.
O switch não podia ser mais novo. Caixa original em papelão branco plastificado, com a marca linksys, brilhando de nova. Switch com aquele cheiro de plástico novo. Todos os acessórios…
Deu até vontade de comprar outro (o vendedor ainda tem sete hoje) mas estou me segurando para não fazer despesas à toa.
Sobre a possível idade do switch
Esta página sugere que o modelo foi vendido pela última vez pelo fabricante em abril de 2018. “Apenas” três anos. Porém esta página sugere que foi fabricado antes de 2010, porque a versão do firmware instalada pelo usuário na época, 1.2.1b, é igual à minha. Aí o switch já tem pelo menos 11 anos. Isso é corroborado pelo documento da Cisco (que comprou a Linksys) 75335-SRW224G4-248G4_V1.1_Firmware_V1.2.3.0.pdf, disponível nesta página, que informa que a versão mais recente do firmware foi lançada em 25/11/2008. Então ou switch passou pelo menos 13 anos guardado em um depósito ou foi propositalmente fornecido com uma versão mais antiga do firmware e nesse caso pode ter apenas três anos mesmo. O que faz sentido, já que o documento informa que a versão mais recente do firmware tem um monte de bugs. Não parece ser prudente atualizar para ela.
O que aprendi sobre o switch até agora
- Consumo de energia: 13.8W (9.9kwh mensais) com tráfego leve. Medido com um PMM2206. Para se ter uma idéia, eu tenho um switch vagabundo de oito portas aqui que consome 1.9W (1.4kwh mensais) nas mesmas condições. Pode ser tolice deixar um switch desses ligado na sua casa “só porque está disponível” pois em um ano a diferença na conta de luz paga por um switch comum de oito portas;
- Possui ventilador interno, ligado permanentemente, que é audível à distância em ambiente silencioso. Como estou testando em casa, no escritório/oficina, o ruído é evidente;
- Versão do firmware 1.2.1b;
- Compatível com rack padrão. Apesar da foto, vem com os suportes laterais já instalados;
- Alimentação 110-220V automática;
- As portas gigabit funcionam como um switch gigabit de 4 portas. Na prática o switch tem 28 portas;
- Tem duas portas miniGBIC (fibra óptica) compartilhadas com as portas G3 e G4. Mas é altamente improvável que eu use isso;
- Portas gigabit sinalizam conexão 1000Mbps com cor de LED diferente;
- Quaisquer portas podem ser agrupadas para criar uma porta que tem a soma das capacidades individuais. Por exemplo, você pode agrupar 4 portas de 100Mbps para ter uma conexão de 400Mbps com outro switch. E aparentemente isso serve para oferecer redundância também (se uma porta ou cabo do grupo falhar, as outras mantém o link, embora mais lento);
- Se tem uma bateria interna, possivelmente está morta a esta altura. Se eu configuro a data e hora nele, isso se perde ao desligar a energia;
- IP default 192.168.1.254. Você pode configurar para DHCP depois;
- Credenciais default: admin/
- Configuração via interface web compatível apenas com Internet Explorer e provavelmente foi projetado para uso com o IE8. Para a configuração funcionar no IE11 basta adicionar o IP do aparelho na lista de compatibilidade;
- Leva cerca de 1 minuto para dar boot. Apesar dos LEDs correspondentes a cada porta acenderem segundos depois de ligado, só há conectividade quando o boot termina;
- Gerenciamento por linha de comando via console serial com conector DB9. Mas só me parece realmente necessário usar essa porta se você esquecer a senha ou IP do aparelho e precisar resetá-lo. Todas as funções do dia a dia estão disponívels via Web-GUI; Uma das versões do firmware tem um bug que, até onde pude entender, impede você de usar algumas funções da web GUI se o único usuário for o admin. É bom criar logo um novo usuário;
- Ao criar um novo usuário, o usuário admin é apagado automaticamente, por isso certifique-se de que sabe a senha que está configurando;
- A proteção contra loops (STP) funciona, se habilitada;
- Alterar certas configurações, como STP, faz com que a conectividade de todo o switch seja paralisada por vários segundos;
- A CISCO parece ter apagado tudo o que havia de suporte para o aparelho em seu site. Você depende de quem tem o aparelho e escreveu sobre ele para tirar suas dúvidas.
Minhas notas sobre o recurso VLAN
Tenha em mente que ainda estou aprendendo a usar isso e o que vou escrever aqui pode nem fazer sentido.
Conceitos
- Access Port – Só pode fazer parte de uma VLAN e esta tem que ser untagged;
- Trunk port – Pode fazer parte de mais de uma VLAN e precisa usar tags para a identificação;
- General port – Pode fazer parte de mais de uma VLAN. Ainda não estou certo de qual a diferença para o modo Trunk.
- VLAN de gerenciamento – A VLAN que dá acesso à configuração do switch. Por default é a VLAN 1 e todas as portas fazem parte dela.
No momento em que você atribui uma porta no modos Access ela é apagada da VLAN de gerenciamento, por isso cuidado ao mexer na porta que você está usando para acessar o switch.
Isso também pode tornar inviável a administração remota do switch. Normalmente, o acesso à internet vai estar numa VLAN separada, então nenhuma máquina que tenha acesso à internet vai ser capaz de acessar o gerencimento do switch.
Ao colocar uma VLAN no modo Trunk e atribuir a uma segunda VLAN ela não deveria ser apagada da VLAN de gerenciamento, até mesmo porque ao adicionar VLANs à porta só deveria estra disponível a opção “tagged”, mas aconteceu com a primeira porta que configurei de a primeira VLAN adicionada ser “untagged”, o que removeu a porta da VLAN1. Talvez a primeira porta trunk criada precise não fazer parte da VLAN1.
Como é uma característica do uso de VLANs que usando-as você pode restringir o acesso à configuração do próprio switch e o usuário anterior pode ter restringido o acesso à VLAN de gerenciamento a apenas uma porta que você não sabe qual é, tentar adivinhar o IP em que o switch está configurado pode ser absoluta perda de tempo se não estiver configurado para DHCP.
Se você apagar uma VLAN, todas as portas associadas a ela passam a fazer parte da VLAN1 se não forem membros de outra.
Apenas portas no modo Trunk e General podem fazer parte de mais de uma VLAN. E apenas em uma ela pode ser Untagged.
Para mudar o modo da porta entre Acces, Trunk e General: VLAN Management -> Port Setting
Para incluir uma porta em uma VLAN existem dois caminhos:
- Vlan Management -> Ports to Vlan -> Escolha a VLAN e mude a configuração de “Exclude” para “Untagged”
- Vlan Management -> VLAN to Ports -> Escolha a porta e clique em Join VLAN
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 18 de outubro de 2021, Redes, WTF Mais um exemplo de como equipamentos vagabundos podem “inovar”… na produção de dores de cabeça para o suporte.
O cliente estava sem acesso à rede em uma seção da empresa que era conectada a um certo switch. Tudo parece normal, os computadores acusam estar conectados ao switch, os respectivos LEDs no switch piscam indicando algum tipo de tráfego, mas não há conectividade entre as portas. Já era a segunda vez que isso acontecia na empresa e na vez anterior o problema pareceu ter sido resolvido ao trocar o switch.
Não era uma tempestade de pacotes (loop) porque o resto da rede operava normalmente e os LEDs do switch não piscavam de forma frenética.
Na minha experiência defeitos em switches são raros. E encontrar o mesmo defeito em dois switches na mesma empresa, na mesma seção da rede e com intervalo de menos de 30 dias é suspeitíssimo, mesmo considerando que eram usados e da mesma marca e modelo.
A causa era o roteador INOVA ROU-6004. Quando o cabo que ia até ele era conectado ao switch a conectividade desaparecia (meu PING de teste parava de funcionar). inicialmente eu achei que fosse algum problema exótico com o cabo, porque ao verificar o roteador este pareceu desligado. Esse roteador só é usado pelo contador da empresa e só quando este está em visita. Como ele não estava presente eu não achei estranho o roteador estar “desligado”. Foi só depois de testar o cabo com o testador mais rigoroso que tenho e não encontrar nada de errado com ele que constatei que o roteador estava quente embaixo, apesar de estar com todas as luzes apagadas. Estava travado. Após desligá-lo da tomada e ligar novamente as luzes acenderam e o problema sumiu.
O “fabricante” aparentemente não dá suporte para seus produtos. Só parece interessado em vender. É melhor evitar todos os produtos dessa marca.
Até esse evento eu achava que nada que você pudesse fazer em uma porta de switch pudesse afetar as outras portas do (e apenas do) mesmo switch. O que danado esse roteador estava fazendo ainda é um mistério para mim.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 29 de junho de 2021, celulares, Redes Isso aconteceu ontem. Apareceu uma mensagem da Samsung avisando que havia mais uma atualização e eu deixei rolar. Achei que fosse mais uma atualização de segurança. Ao pegar no telefone de novo achei algo estranho no visual e perceptivelmente mais lento ao fazer uma busca de apps. A lista de apps recentes demora a aparecer e o teclado virtual demora tanto que dá impaciência. Depois foi que notei outras coisas diferentes, fui olhar a versão e constatei que o telefone, que veio de fábrica com a versão 10, agora estava com a versão 11.
E outra coisa estranha foi provocada pela atualização que me fez parar tudo o que eu estava fazendo para investigar: hoje eu fui auditar minha rede e encontrei um dispositivo desconhecido, possivelmente wi-fi (ping alto) com IP atribuído, mas o netscan não me dizia qual o fabricante. como o meu arquivo oui.txt podia estar desatualizado eu fui conferir em um serviço online e acusou que o fornecedor “D2-1B-BF” não estava cadastrado (para todos os efeitos é um MAC falso).
Então fui olhar na lista de clientes DHCP no meu roteador e lá estava ele: o meu Galaxy A11 aparecia com dois IPs atribuídos para dois MACs diferentes, sendo um deles esse começando por “D2-1B-BF” e o outro era o MAC da Samsung.
Fui conferir de novo o MAC do meu telefone no aparelho e lá encontrei a explicação. Ao tocar em Advanced eu encontrei uma nova configuração chamada MAC Address Type, que estava configurada para Randomized MAC. E de fato, após desligar e ligar novamente o aparelho, este apareceu com outro IP e outro endereço MAC na lista do meu roteador.
Entendi que essa deve ser uma nova configuração de privacidade, mas como eu não consigo ver nenhuma razão para desejar isso e, ao contrário, inviabiliza a auditoria da minha rede, escolhi a outra opção: Phone MAC.
Essa configuração parece ser por access point e não por servidor DHCP. Aqui em casa eu tenho apenas um servidor DHCP e todos os meus roteadores estão configurados para operar como access point (Servidores DHCP desligados. Todo mundo pega endereço IP no mesmo roteador, não importando por onde conecta) e eu tive que mudar essa configuração em cada um deles. Isso eu achei positivo. Na minha rede eu configuro tudo como “Phone MAC” para poder auditar e em qualquer outra que o meu telefone vier a se conectar irá apresentar um MAC aleatório.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 02 de junho de 2021, CFTV, Redes Este texto pode parecer declarar o óbvio, mas é necessário para dar suporte a um texto mais longo em que estou trabalhando.
Com a popularização das câmeras de vigilância IP 4K, o fato de ser conveniente usar a infraestrutura de rede já existente para criar ou expandir seu sistema de vigilância pode criar problemas inesperados se você não ficar atento. Isso já era um problema com câmeras 1080p em empresas, mas com 4K pode virar um problema até em residências.
Segundo esta calculadora, enquanto uma câmera 1080p numa dada qualidade requer 3.5Mbps de banda, uma câmera 4K nas mesmas condições requer 18Mbps. Com apenas quatro câmeras você já precisa de 72Mbps de banda. São 72% de uma rede de 100Mbps comprometidos ininterruptamente, 24×7. E dependendo de como as coisas estiverem conectadas até para navegar na internet você vai estar limitado a 28Mbps, não importando o que você contratou com a operadora. É preciso organizar sua rede de forma que o caminho entre as câmeras e o NVR não compartilhe o mesmo segmento de rede que você precisa para acessar a internet. Usando rede gigabit você não precisa se preocupar com isso.
Observe o diagrama abaixo, que é mais apropriado para representar uma pequena empresa, mas que não está muito longe da situação na minha residência. Suponha que os switches sejam de 100Mbps.
Com o NVR ligado ao switch A, o segmento de rede F fica ocupado com um fluxo contínuo de 72Mbps, sobrando apenas 28Mbps de banda para os computadores C, D e E acessarem a internet, o servidor e o próprio NVR (playback das gravações). Note que esse é um exemplo arbitrário. Com outra combinação de equipamentos você poderia facilmente saturar os 100Mbps da sua rede. A solução mais simples para o problema do exemplo é trazer o NVR para o switch B. Assim todo o tráfego das câmeras fica restrito ao switch B e o segmento de rede F fica com 100Mbps livres. Uma segunda solução é trocar o switch B por um modelo gigabit e uma terceira seria acrescentar um switch só para as câmeras e lançar outro cabo de rede até o switch A.
Como se pode ver, é um problema contornável. Às vezes pode levar mais tempo para você se dar conta de que tem o problema do que o tempo necessário para corrigi-lo.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 28 de maio de 2021, Redes Um amigo me pediu ajuda porque após a chuva torrencial do fim de semana o link que ele tinha entre a casa e o escritório deixou de funcionar. Ambos ficam na mesma rua, a uma distância em linha reta de aproximadamente 55m e a ligação é feita por cabo ethernet que faz a maior parte do caminho pelo ar. Ele diz que foram gastos 150m de cabo nessa ligação, o que está bem acima do limite de 100m estabelecido pelo padrão, mas o link funcionava há mais de uma década.
A primeira coisa que fiz, a pedido dele, foi recrimpar os conectores. Em seguida fiz o teste com o testador vagabundo de cabos (aquele barato que tem um LED para cada fio) e o cabo estava OK. Mas eu quis testar também com o medidor de comprimento de cabos, porque queria saber se aquele cabo tinha mesmo 150m e o medidor também é útil para sinalizar problemas mais sutis. Para minha surpresa, o medidor acusou todos os pares em curto. Eu testei duas vezes. A única situação em que vi isso acontecer antes é se a outra ponta estiver ligada a um switch e eu me certifiquei de que na outra ponta só houvesse o “wiremap adapter”.
No escritório dele o cabo é ligado a um roteador. O diagnóstico do roteador dizia que a porta WAN estava “unplugged” mesmo com o cabo conectado. Colocamos o cabo diretamente na placa de rede de um computador e o link funcionou aparentemente de forma normal. Coloquei um switch em vez do roteador e também funcionou de forma aparentemente normal.
Concluí que a porta WAN estava danificada. Tentei usar o roteador como um AP, desligando o DHCP e plugando o cabo em uma porta LAN. Também não funcionou.
Condenei o roteador. Meu amigo comprou outro, segundo ele do mesmo modelo (TP-LINK TL-WR849N) e ao instalar teve uma surpresa: o mesmo problema. Nada de a porta WAN funcionar.
Então ele teve a idéia de testar ambos na casa dele. Os dois funcionaram lá.
Ele me chamou de novo. Levei uns seis roteadores diferentes para testar, mas logo o primeiro que coloquei funcionou na hora: um D-LINK DIR905L, que nem é grande coisa. O teste de velocidade alcançou uns 85Mbps.
Conclusão até agora: com as chuvas o cabo se deteriorou, provavelmente no trecho do escritório onde ele passa enterrado, e o TP-LINK TL-WR849N (dois testados) é incapaz de distinguir o sinal que outros equipamentos baratos (uma placa de rede, um switch e um roteador) conseguem.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 09 de setembro de 2020, Redes Na verdade, dois links. Instalados pela Vivo recentemente nas empresas de dois de meus clientes. Eu só posso usar 100Mbps na rede cabeada (os 150Mbps estão disponíveis pelo Wifi do roteador da Vivo) porque os switches dos clientes não são gigabit, mas transferir arquivos entre empresas a uma velocidade sustentada de 11MiB/s já é fantástico. É quase como uma rede local com 11 quilômetros entre os nós.
Quase mesmo. Entre os dois links o ping varia de 3 (sim, três) a 38ms fora do horário de expediente.
Da minha casa para um deles varia de 30 a 34ms.
E com um custo de apenas R$150 mensais com plano de telefonia fixa com ligações ilimitadas para o Brasil inteiro incluso. Ô inveja…
Como o link da minha casa é de 25Mbps simétrico eu pelo menos posso transferir dados com esses clientes a 2.1MiB/s (testado). O que também é muito bom.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 09 de setembro de 2020, Redes, WTF É fácil, mas eu levei uma surra.
Quando eu abri a configuração do roteador e olhei o menu achei que isso fosse obviamente configurado em “Firewall”
Mas essas duas regras que você vê aí criadas não funcionaram. Também senti falta de uma opção para criar uma DMZ. Após horas quebrando a cabeça e muito preocupado porque eu precisava fazer esse acesso funcionar e não podia trocar esse roteador eu desisti e fui em Jogos e Aplicativos e escolhi opções cujas portas eu conhecia:
“HTTP” usa a porta 80 TCP e “CuSeeMe” usa as portas 7648 e 7649 TCP. Bastou configurar minha aplicação para usar essas portas e finalmente funcionou. Problemático mesmo seria se minha aplicação tivesse que usar uma porta especifica e eu não encontrasse nenhuma na lista que usasse a mesma.
Dias depois, quando estava olhando outra coisa, descobri isso:
O que danado “DMZ”, “Redirecionar Portas”, “UPNP” e “DDNS” estão fazendo em “Rede Local”?
Criei uma regra em Redirecionar Portas e funcionou como esperado. O campo “porta interna” não permite definir uma faixa de portas mas basta indicar a primeira porta que a faixa é atribuída corretamente.
(Prefira clicar em "Responder" se estiver comentando um comentário)
Jefferson, 03 de julho de 2020, Redes Desde que a VIVO comprou a GVT anos atrás todos os projetos de expansão tinham sido paralisados. A GVT tinha acabado de passar um cabo de fibra óptica na frente da minha rua quando foi adquirida e desde então nada foi oferecido no meu bairro. Mas esta semana um de meus clientes empresariais que também dependia de “internet de bairro” para ter algo decente pois lá só chegava ADSL da OI de 15Mbps (creio que 500Kbps de upload), recebeu uma ligação da VIVO oferecendo um plano de 100Mbps simétrico por R$150 mensais. Ele, que pagava R$450 por um quarto disso abraçou na hora. Fizeram a instalação no outro dia. Eu fiz a configuração do GPON ontem e é coisa “de outro mundo” poder fazer uploads a 90Mbps.
(Prefira clicar em "Responder" se estiver comentando um comentário)
|
|
Jeff, por favor pode dar um exemplo de que aplicação tem criar esses certificados?
Só quando os textos sobre VPN começarem a sair.