Arquivo mensal: maio 2020

Alcatel NM 5620 e XDMCP no Linux

Por questões de trabalho eu utilizava um estação Sun Ultra 5, já obsoleta, mas era uma das poucas opções para acesso a uma plataforma de gerência Alcatel NM 5620 (também obsoleta, veja só!).

A Sun tomava espaço na mesa, tinha uma fonte com um cooler de barulho particularmente irritante. Detestava ter que usá-la.

Olhando os scripts que iniciavam o programa de gerenciamento eu vi que utilizava protocolo XDMCP para a parte gráfica (o servidor em si estava em outra localidade). Pensei de imediato: vou configurar isso no Linux e posso usar uma estação mais moderna ou uma máquina virtual, para liberar espaço.

O primeiro sinal que não ia ser tão simples era a janela de login, o texto estava com fontes maiores. Mas se fosse só estético, sem problemas.

Depois a tela de abertura, onde o texto estava cortado. Mas era só estética…

E o tiro de misericórdia: a tela de busca de nós de gerência perdia o botão Make List, que iniciava a busca e a coluna de Admin Status não aparecia. A janela tinha tamanho fixo, não permitia o reposicionamento.

Sem isso era inútil prosseguir. Quando tinha um tempo livre experimentava usar diferentes gerenciadores Gnome, LXDE, LightDM, distribuições (Ubuntu, Arch, Mint). Sem sucesso.

Depois de meses vi que tinha máquinas virtuais do Sun Solaris 10, bem mais modernos que a versão que eu usava (tão antiga que até esqueci). Baixei as VMs de 32bits e 64 bits para poder usar nas versões de Windows disponíveis que aparecessem.

Comecei com a VM de 32 bits, configurei, criei os scripts e os testes foram perfeitos, já poderia aposentar a estação. Não do jeito que eu queria, mas estava valendo.

Como já tinha acertado a versão de 32 bits rapidamente coloquei os scripts na de 64 bits. Resultado? As mesmas telas com distorções de fontes que havia encontrado no Linux…

Não fazia sentido. As duas versões possuem exatamente o mesmo conjuntos de fontes.

Usei o comando xset -q, retorna alguns parâmetros, como as fontes em uso:

Além de informar as fontes que o servidor X11 está utilizando ele mostra a ordem em que elas são buscadas!

Mudei a ordem das fontes com o comando xset +fp, fiz uma nova conexão com a VM de 64 bits e a gerência apresentava todas as janelas corretamente, com todos os botões e campos.

Eu não esperava que as fontes pudessem ter uma ordem correta, mas acabei encontrado uma discussão na Internet onde alguém explicava que o SunX (servidor X11 do Solaris) ao encontrar uma referência à uma fonte varre todos os diretórios de fontes até encontrar a fonte de nome exato, apenas quando a fonte é inexistente substitui por uma compatível. O Xorg (servidor X11 do Linux e das versões mais moderanas do Solaris também) utiliza a primeira fonte compatível que encontrar, caso a fonte compatível esteja disponível antes da fonte desejada será utilizada. Isso explicava todos os problemas de apresentação, apesar das fontes adequadas estarem disponíveis.

Resolvido na VM de 64 bits, foi sor seguir o mesmo raciocínio nas máquinas Linux (e Free BSD que alguém usava).

Assim após acertar a ordem das fontes a janela de login apresentava as fontes menores que estávamos acostumados:

A tela de abertura não cortava o texto:

E, o mais importante, a janela de gerência tinha o botão Make List e todos os campos presentes, incluindo o Admin Status:

Para não ter que acertar manualmente a ordem das fontes, no Linux basta criar o seguinte arquivo com a ordem desejada das fontes /usr/share/X11/xorg.conf.d/10-fonts.conf com o seguinte conteúdo:

# Fontes extras para acesso a estacao X11 remota

Section "Files"

FontPath	"/usr/share/fonts/X11/misc:unscaled"
FontPath	"/usr/share/fonts/X11/75dpi:unscaled"
FontPath	"/usr/share/fonts/X11/100dpi:unscaled"
FontPath	"/usr/share/fonts/X11/TrueType"
FontPath	"/usr/share/fonts/X11/Type1"
FontPath	"/usr/share/fonts/X11/Type1/sun/"
FontPath	"/usr/share/fonts/X11/F3bitmaps:scaled"
FontPath	"/usr/share/fonts/X11/misc:scaled"
FontPath	"/usr/share/fonts/X11/75dpi:scaled"
FontPath	"/usr/share/fonts/X11/100dpi:scaled"

EndSection

Problemas com VPN IPsec com cliente strongSwan – MODp_2048 e Windows

A utilização de acesso remoto por VPNs é cada vez mais comum (e agora em tempos de COVID19, praticamente inevitável).

Há algum tempo atrás instalei um firewall que utilizava pfsense (ótimo firewall para quem precisa de uma proteção mais sofisticada para sua rede) e comecei a utilizar seus recursos e foi quando configurei uma VPN com IPsec, pela facilidade de configuração e já existir um cliente nativo desde o Windows 7.

Como utilizo um celular android procurei um cliente IPsec e utilizei o strongSwan, que também a passei a utilizar no Linux. Tudo funcionava bem até o strongSwan chegar na versão 4.4, quando passou a forçar a utilização de chaves de 2048 bits (DH group 14).

Não conseguia mais acesso via android ou Linux. Com Windows estava tudo funcionando.

Observando os logs do pfsense encontrava esse alerta nas tentativas falhas com cliente strongSwan:

[IKE] DH group MODP_2048 inacceptable, requesting MODP_1024

Pesquisei e vi que era por conta da mudança. A primeira coisa foi adequar o pfsense e forçar a utilização do grupo DH-14 (anteriormente estava utilizando DH-2, 1024 bits), nas opções de Fase 1 do algoritmo de encriptação. No menu do pfsense o caminho é VPN / IPsecMobile / Clients / Edit Phase 1.

Pronto, os clientes strongSwan voltaram a funcionar perfeitamente. Os clientes Windows é que deixaram de funcionar. 😦

Mas no próprio site do strongSwan havia a descrição do problema: o cliente IPsec Windows é capaz de trabalhar com o grupo DH-14, porém vem com essa funcionalidade desabilitada.

Para habilitar basta a criar uma chave DWord no registry com o valor 1:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters\NegotiateDH2048_AES256

Após essa alteração voltei a ter conectividade em todos os clientes.

No caso do Windows 7 há um procedimento especial para importar certificados privados que sejam utilizados em conexões IPsec:

- Clicar 2 vezes no seu certificado Meu_certificado.crt
- Clicar no botão Instalar Certificado
- Avançar
- Colocar todos os certificados no repositório a seguir
- Clicar em Procurar
- Marcar “Mostar Repositórios Físicos”
- Selecionar “Autoridades de Certificação Raiz Confiável” e dentro desta chave “Computador Local”
- Selecionar OK
- Avançar
- Concluir
- OK

Matt's Entropy

... seeding /dev/random, one blog post at a time.

Maravilhoso Mundo Novo

De volta ao Paraíso

androideia

Idéias e Android, necessariamente não nessa ordem.

Another Airgun Blog

Idéias e Android, necessariamente não nessa ordem.

Armas de Pressão - Modificações e afins

Metade da graça em atirar está em fazer ajustes na arma.