Em , falei sobre a história da criação da Veliam e sobre a decisão de sua distribuição através do sistema SaaS. Neste artigo, vou contar o que foi necessário fazer para que o produto deixasse de ser local e se tornasse público. Sobre como começamos a distribuição e quais problemas enfrentamos.
Planejamento
A parte atual do servidor para os usuários estava em Linux. Quase toda organização possui servidores Windows, o que não se pode dizer sobre o Linux. O principal ponto forte da Veliam é o acesso remoto a servidores e equipamentos de rede por trás de NAT. Mas essa funcionalidade estava muito rigidamente atrelada ao fato de o roteador ter que ser obrigatoriamente um MikroTik. E isso claramente não satisfaria muitos. Eu inicialmente comecei a pensar em adicionar suporte a roteadores dos fornecedores mais comuns. Mas eu entendia que seria uma corrida sem fim para expandir a lista de empresas suportadas. Além disso, mesmo aquelas que já eram suportadas poderiam ter um conjunto diferente de comandos para modificar as regras de NAT de modelo para modelo. A única solução viável parecia ser o VPN.
Como decidimos distribuir o produto, mas não como open source, não podíamos incluir várias bibliotecas com licenças abertas como a GPL. Esse é um tema à parte; após a decisão de vender o produto, tivemos que reavaliar metade das bibliotecas porque eram GPL. Quando estávamos desenvolvendo para uso próprio, isso era aceitável. Mas não serve para distribuição. O primeiro VPN que vem à mente é o OpenVPN. Mas ele é GPL. Outra opção seria usar o SoftEther VPN japonês. Sua licença permitia incluí-lo no nosso produto. Após alguns dias de testes para integrar isso de maneira que o usuário não precisasse configurar nada ou saber sobre o SoftEther VPN, conseguimos um protótipo. Estava tudo como deveria estar. Mas, por alguma razão, essa abordagem ainda nos incomodava e, no final, decidimos abandoná-la. Mas, naturalmente, fizemos isso apenas depois de encontrar outra solução. No final, tudo foi feito com conexões TCP comuns. Parte das conexões funciona através de um coordenador, parte diretamente através da tecnologia Nat Hole Punching (NHP), que também foi implementada em Free Pascal. Devo dizer que eu nunca tinha ouvido falar de NHP antes. Não conseguia imaginar que poderia conectar dois dispositivos de rede, ambos atrás de NAT, diretamente. Estudei o tema, compreendi o princípio de funcionamento e comecei a programar. O que foi planejado foi realizado; o usuário se conecta a um dispositivo atrás do NAT com apenas um clique através de RDP, SSH ou Winbox, sem inserir senhas ou configurar VPN. Grande parte dessas conexões passa direto pelo nosso coordenador, o que beneficia a latência e o custo de manutenção dessas conexões.
Migração da parte do servidor de Linux para Windows
Houve vários problemas ao fazer a transição para o Windows. O primeiro foi que o wmic embutido no Windows não permite fazer consultas WQL. E no nosso sistema, tudo já estava baseado nisso. Havia também outra questão, mas agora não consigo lembrar o motivo pelo qual decidimos abrir mão de seu uso. Talvez as diferenças entre as versões do Windows. E o segundo problema foi a multitarefa. Não encontrando uma boa ferramenta de terceiros com uma licença 'aceitável' para nós, reiniciei o IDE Lazarus e escrevi a ferramenta necessária. O input é uma lista de objetos e as consultas que precisam ser feitas, e em resposta recebo os dados. E tudo isso em modo multitarefa. Excelente.
Depois que configurei pthreads para PHP no Windows, pensei que tudo funcionaria perfeitamente, mas não foi bem assim. Após algum tempo de depuração, percebi que o pthreads parecia funcionar, mas especificamente em nosso sistema, não funcionava. Ficou claro que havia alguma particularidade no funcionamento do pthreads no Windows. E era isso mesmo. Li a documentação e lá estava escrito que, para o Windows, o número de threads é limitado, e, pelo que me lembro, isso não estava explícito. Isso se tornou um problema. Quando comecei a reduzir o número de threads em que o aplicativo funcionava, ele executava as tarefas muito lentamente. Novamente, abri a IDE e na mesma utilidade, foi adicionado um recurso para pings multithread de objetos. E para completar, também adicionei a varredura de portas. Na verdade, depois disso, a necessidade do pthreads para PHP desapareceu, e ele passou a não ser mais utilizado. Em seguida, essa utilidade recebeu mais algumas funcionalidades e permanece em uso até hoje. Depois disso, foi criado um instalador para Windows que incluía Apache, PHP, MariaDB, o próprio aplicativo PHP e um conjunto de utilitários para interação com o sistema, escritos em Free Pascal. Quanto ao instalador, pensei que resolveria essa questão rapidamente, pois é algo extremamente comum e necessário para praticamente todo software. Ou eu não procurei da maneira certa, ou algo assim. Mas eu constantemente encontrava produtos que eram ou pouco flexíveis, ou caros e também inflexíveis. E ainda assim, encontrei um instalador gratuito que permite prever qualquer necessidade. Esse é o InnoSetup. Estou escrevendo sobre isso aqui porque tive que pesquisar, talvez eu possa economizar tempo de alguém.
Abandono do plugin em favor do meu cliente
Eu escrevi anteriormente que a parte cliente era um navegador com um "plugin". Houve tempos em que o Chrome atualizava e o layout ficava um pouco desorganizado, ou então o Windows atualizava e o esquema de URI personalizado se perdia. Não queria ter esse tipo de surpresas na versão pública do produto. Além disso, o URI personalizado começou a se perder após cada atualização do Windows. A Microsoft simplesmente removia todos os seus ramos na seção necessária. Além disso, o Google Chrome agora não permite salvar a escolha de abrir ou não o aplicativo a partir do URI personalizado, e faz essa pergunta a cada clique no objeto de monitoramento. De modo geral, era necessário ter uma interação normal com o sistema local do usuário, algo que o navegador não oferece. A solução mais simples nessa situação parecia ser criar o próprio navegador, como muitos estão fazendo agora através do Electron. Mas muitas coisas já haviam sido escritas em Free Pascal, incluindo a parte do servidor, então decidimos fazer o cliente na mesma linguagem, em vez de criar um 'zoológico' de tecnologias. Assim foi escrito o cliente com Chromium a bordo. Depois disso, ele começou a se expandir com diversas funcionalidades.
Lançamento
Finalmente escolhemos um nome para o sistema. Passamos por várias opções enquanto fazíamos a transição da versão local para o SaaS. Como inicialmente planejávamos expandir para além do mercado interno, o principal critério para a escolha do nome foi a disponibilidade de um domínio livre ou não muito caro na extensão “.com”. Algumas funções/módulos ainda não haviam sido portados da versão local para o Veliam, mas decidimos que lançaríamos com a funcionalidade atual, com o resto sendo adicionado em atualizações futuras. Na primeira versão não havia HelpDesk, Veliam Connector, não era possível alterar os limites de acionamento dos gatilhos de notificação e muito mais. Compramos um Certificado de Assinatura de Código e assinamos as partes do cliente e do servidor. Criamos um site para o produto e iniciamos os processos de registro de software, marca registrada, etc. Enfim, estamos prontos para começar. Uma leve euforia pela trabalho realizado e pelo fato de que, possivelmente, alguém poderia usar seu produto, embora não tivéssemos dúvidas sobre isso. E então, parámos. O parceiro disse que não poderíamos entrar no mercado sem notificações nos mensageiros. Poderíamos deixar muita coisa de lado, mas não isso. Após discussões breves, foi adicionada a integração com o Telegram, que nos satisfez. Entre os mensageiros atuais, este é o único que oferece acesso à sua API gratuitamente e sem burocracias complicadas. O próprio WhatsApp sugere que se entre em contato com provedores que cobram uma quantia considerável por seus serviços, todos os e-mails solicitando acesso direto foram ignorados. Quanto ao Viber... Não sei quem ainda o utiliza, pois o spam e a publicidade lá são excessivos. No final de dezembro, após uma série de testes internos e testes entre amigos, abrimos o registro para todos e disponibilizamos o software para download.
Início da disseminação
Desde o início, entendíamos que precisaríamos de um pequeno fluxo de usuários do sistema para que eles testassem o produto em um ambiente real e nos dessem algum feedback inicial. Alguns posts pagos no VK trouxeram resultados. Começaram as primeiras inscrições.
Aqui é importante dizer que entrar no mercado sem um nome famoso e, ao mesmo tempo, fornecer uma funcionalidade de monitoramento sem agente, na qual é necessário inserir credenciais de seus servidores e estações de trabalho, é muito difícil. Isso assusta muitas pessoas. Desde o início, entendemos que enfrentaríamos problemas e estávamos prontos para isso, técnica e moralmente. Todas as conexões remotas, embora RDP e SSH já sejam criptografados por padrão, são adicionalmente criptografadas pelo nosso software com padrão AES. Todos os dados dos servidores locais são enviados para a nuvem via HTTPS. As credenciais são armazenadas de forma criptografada. As chaves de criptografia para todos os subsistemas de todos os clientes são individuais. Para conexões remotas, são utilizados chaves de criptografia de sessão.
Tudo o que podemos fazer nesta situação para tranquilizar as pessoas é ser o mais transparentes possível, trabalhar na segurança e não nos cansar de responder às preocupações delas.
Para muitos, a conveniência e a funcionalidade do software superam o medo, e eles acabam se registrando. Algumas pessoas em postagens publicadas no VK escreveram que este software não deve ser utilizado, pois é um coletor de senhas e uma empresa completamente desconhecida. É preciso dizer que essa opinião não era isolada. Muitos simplesmente não entendem que, ao instalar outro software proprietário no servidor, que opera como um serviço, ele tem plenos direitos no sistema e não precisa de credenciais para realizar ações ilícitas (é claro que é possível alterar o usuário a partir do qual o serviço é iniciado, mas aqui também, qualquer conta de usuário pode ser inserida). Na verdade, as preocupações das pessoas são compreensíveis. Instalar software em um servidor é algo comum, mas inserir credenciais já é um pouco assustador e íntimo, já que boa parte das pessoas usa a mesma senha para todos os serviços, e criar uma conta separada mesmo para testes dá preguiça. Mas atualmente, existem muitos serviços nos quais as pessoas confiam suas credenciais e não apenas isso. E buscamos tornar-nos um deles.
Muitos comentários foram nesse sentido, de que nós teríamos roubado isso de algum lugar. Isso nos surpreendeu um pouco. Bem, é a opinião de uma pessoa, mas esse tipo de comentário apareceu em várias publicações de diferentes pessoas. Inicialmente, não sabíamos como reagir a isso. Se ficávamos tristes pelo fato de algumas pessoas acharem que na Rússia ninguém pode fazer nada por conta própria, mas só pode roubar, ou se tínhamos que nos alegrar por acreditarem que algo assim só pode ser roubado.
Agora concluímos o processo de obtenção do Certificado de Assinatura de Código EV. Para obtê-lo, é necessário passar por uma série de verificações e enviar uma série de documentos da empresa, alguns dos quais precisam ser autenticados por um advogado. Obter o certificado de assinatura de código EV durante a pandemia é, na verdade, um tópico à parte para um artigo. O processo se arrastou por um mês. E foi um mês de solicitações constantes de documentos adicionais, não de espera. Pode ser que a pandemia não tenha nada a ver com isso, e todos estejam passando por um processo tão longo? Compartilhe.
Alguns dizem que não vamos usar porque não temos o certificado do FSTEK. Precisamos explicar que não podemos obtê-lo e não vamos, porque para conseguir esse certificado, a criptografia precisa estar de acordo com o GOST, e planejamos distribuir o software não apenas na Rússia e usamos AES.
Todos esses comentários geraram uma certa insegurança sobre a possibilidade de promover um produto que exige a inserção de contas, sem estar em evidência. Mesmo considerando que sabíamos que haveria aqueles que seriam muito negativos a respeito disso. Após o número de registros ultrapassar mil, paramos de pensar nisso. Especialmente depois que, além das críticas de quem nem sequer experimentou o produto, começaram a surgir resenhas muito positivas. É importante mencionar que essas avaliações positivas são o maior motivador para o desenvolvimento do produto.
Adição de funcionalidade de acesso remoto para funcionários
Uma das tarefas frequentes dos clientes é "fornecer ao Vanya acesso ao computador dele de casa". Configuramos um VPN no Mikrotik e criamos contas para os usuários. Mas isso realmente se torna um problema. Os usuários não conseguem seguir o manual e realizar o passo a passo para se conectar via VPN. Existem diferentes versões do Windows. Em um Windows tudo conecta bem, em outro é necessário um protocolo diferente. E, no geral, isso sempre esteve relacionado à reconfiguração do equipamento de rede que atuava como servidor VPN, e nem todos os funcionários têm acesso a ele, o que se torna inconveniente.
Mas já temos conexões remotas a servidores e equipamentos de rede. Por que não aproveitar o transporte pronto e criar uma pequena utilidade que possa ser simplesmente fornecida ao usuário para conexão? A ideia era apenas fazer com que o usuário não precisasse inserir informações complexas. Apenas um botão "conectar". Mas como essa utilidade saberá para onde conectar, se só tiver um botão? Tinha a ideia de construir online o aplicativo necessário em nossos servidores. O administrador do sistema clica no botão "baixar atalho", e um comando é enviado para o nosso cloud para compilar um binário individual com as informações de conexão para o servidor ou computador necessário via RDP. Em geral, isso poderia ser feito. Mas leva tempo, o administrador teria que esperar primeiro o binário ser compilado e depois baixá-lo. Claro, poderíamos simplesmente adicionar um segundo arquivo com a configuração, mas seriam 2 arquivos, e para simplicidade, o usuário precisa de um só. Um arquivo, um botão e nenhum instalador. Depois de ler um pouco na vastidão do Google, cheguei à conclusão de que, se adicionar alguma informação ao final do "exe" compilado, ele não se danifica (quase). Pode-se até adicionar "Guerra e Paz", e ele funcionará normalmente. Seria um desperdício não aproveitar isso. Agora podemos descompactar o aplicativo, que aliás se chama Veliam Connector, diretamente no cliente e simplesmente adicionar ao final as informações necessárias para a conexão. E o próprio aplicativo sabe o que fazer com isso. Por que escrevi "quase" entre parênteses? Porque essa conveniência tem um custo: o aplicativo perde sua assinatura de certificação digital. Mas, neste estágio, acreditamos que esse é um pequeno preço a pagar por uma conveniência tão grande.
Licenças de módulos de terceiros
Eu já mencionei acima que, após decidirmos tornar o produto de acesso público, em vez de apenas para uso interno, tivemos que trabalhar bastante e procurar alternativas para alguns módulos que não permitiam sua inclusão em nosso produto. Mas, logo após o lançamento, descobrimos um problema bastante desagradável. No Veliam Server, que estava do lado do cliente, havia um banco de dados MariaDB. E ele tem a licença GPL. A licença GPL exige que o software seja open source, e se nosso produto inclui o MariaDB, que possui essa licença, então nosso produto também deve estar sob essa licença. Mas, felizmente, a finalidade dessa licença é o código aberto, e não punir judicialmente aqueles que cometem um erro acidental. Se o detentor dos direitos apresentar uma reclamação, ele deve notificar o infrator por escrito e este deve corrigir a violação dentro de 30 dias. Nós mesmos descobrimos nosso erro e não recebemos cartas e imediatamente começamos a considerar opções para resolver o problema. A saída se tornou óbvia — a migração para SQLite. Este banco de dados não tem restrições de licenciamento. A maioria dos navegadores modernos utiliza SQLite, assim como uma série de outros programas. Encontrei na internet informações de que o SQLite é considerado o banco de dados mais amplamente utilizado no mundo, justamente por causa dos navegadores, mas não busquei provas, então essa informação pode não ser precisa. Comecei a estudar o que a migração para SQLite pode acarretar.
Isso se torna uma tarefa não trivial quando há várias centenas de servidores com MariaDB instalados nos clientes e dados neles. Alguns recursos do MariaDB não estão disponíveis no SQLite. Por exemplo, no código, utilizamos consultas do tipo
Select * FROM `table` WHERE `id`>1000 FOR UPDATE
Essa construção não apenas realiza uma seleção da tabela, mas também bloqueia as linhas de dados. E várias outras construções também precisaram ser reescritas. Mas além de ter que reescrever muitas consultas, também tivemos que inventar um mecanismo que, ao atualizar o Veliam Server no cliente, portasse todos os dados para o novo banco de dados e removesse o antigo. Além disso, as transações não funcionavam no SQLite, e isso era um problema real. Mas, depois de ler sobre isso na vasta rede mundial, encontrei sem problemas que as transações no SQLite podem ser habilitadas, passando um simples comando ao se conectar.
PRAGMA journal_mode=WAL;No fim, a tarefa foi concluída e agora a parte do servidor dos clientes funciona em SQLite. Não notamos mudanças na operação do sistema.
Novo HelpDesk
Era necessário portar o sistema HelpDesk da versão interna para a versão SaaS, mas com algumas alterações. A primeira coisa que queríamos fazer era a integração com o domínio do cliente no que diz respeito à autorização transparente dos usuários no sistema. Agora, para acessar o HelpDesk e deixar um pedido, o usuário simplesmente clica no atalho na área de trabalho e o navegador se abre. O usuário não insere nenhuma credencial. O módulo para Apache SSPI, que faz parte do Veliam Server, autoriza automaticamente o usuário com a conta de domínio. Para deixar um pedido no sistema, quando o usuário está fora da rede corporativa, ele clica em um botão e recebe um link por e-mail, pelo qual ele se autentica no sistema HelpDesk sem senhas. Se o usuário for desativado ou removido do domínio, a conta no HelpDesk também deixará de funcionar. Assim, o administrador do sistema não precisa monitorar as contas tanto no domínio quanto no HelpDesk. Se um funcionário se demitir, ele desativa a conta no domínio e pronto, ele não conseguirá acessar o sistema nem da rede corporativa, nem pelo link. Para implementar essa integração, o administrador do sistema precisa criar uma GPO que e .
A segunda coisa que consideramos extremamente necessária para sistemas HelpDesk, pelo menos para nós mesmos, é a conexão com o solicitante diretamente do pedido com um clique. Além disso, as conexões devem ser possíveis mesmo que o administrador do sistema esteja em outra rede. Para terceirização, isso é essencial, e para administradores de sistema internos, muitas vezes é também muito necessário. Já existem vários produtos que lidam muito bem com a tarefa de conexões remotas. E decidimos fazer integrações para eles. Atualmente, fizemos uma integração para VNC e no futuro planejamos adicionar Radmin e TeamViewer. Usando nosso transporte de rede para conexões remotas à infraestrutura, tornamos possível que o VNC se conecte a estações de trabalho remotas por trás de NAT. O mesmo será feito para Radmin. Agora, para se conectar a um usuário, basta clicar no botão “conectar ao solicitante” na própria solicitação. O cliente VNC se abre e se conecta ao solicitante, independentemente de você estar na mesma rede ou em casa de chinelos. Previamente, o administrador do sistema deve instalar o VNC Server em todas as estações de trabalho usando as ferramentas de GPO.
Atualmente, estamos migrando para um novo HelpDesk e utilizando a integração com o domínio e o VNC. Isso é muito conveniente para nós. Agora podemos evitar pagar pelo TeamViewer, que utilizamos por mais de três anos para o funcionamento do nosso suporte técnico.
O que planejamos fazer a seguir
Quando lançamos o produto, não criamos planos pagos, apenas limitamos o plano gratuito a 50 objetos de monitoramento. Cinquenta dispositivos de rede e servidores deveriam ser suficientes para todos, pensamos nós. E então começaram a chegar solicitações para aumentar o limite. Dizer que ficamos um pouco surpresos é pouco. Será que nosso software chamou a atenção de empresas com tantos servidores? Expandimos gratuitamente o limite para aqueles que fizeram tais solicitações. Em alguns casos, perguntamos em resposta ao pedido por que precisavam de tantos, será que tinham uma quantidade tão grande de servidores e equipamentos de rede? E descobrimos que os administradores de sistema começaram a usar o sistema de uma maneira que não planejamos de forma alguma. Tudo se revelou simples - começaram a monitorar não apenas servidores, mas também estações de trabalho. Daí vieram tantas solicitações para aumentar os limites. Agora já introduzimos planos pagos e os limites podem ser aumentados de forma autônoma.
Os servidores quase sempre operam com armazenamento em rede ou com discos locais em um array RAID. E nós inicialmente criamos o produto para eles. O monitoramento SMART não era interessante para essa tarefa. Mas considerando que as pessoas adaptaram o software para monitorar estações de trabalho, surgiram pedidos para implementar o monitoramento SMART. Em breve o implementaremos.
Com a chegada do Veliam Connector, não é mais necessário implantar um servidor VPN na rede corporativa, ou criar um RDGW, ou simplesmente encaminhar portas para as máquinas necessárias para conexão via RDP. Muitas pessoas utilizam nosso sistema apenas para essas conexões remotas. O Veliam Connector está disponível apenas para Windows, e alguns usuários de empresas se conectam a estações de trabalho ou terminais na rede corporativa de seus laptops pessoais com MacOS. E o resultado é que o administrador de sistema é forçado, por causa de alguns usuários, a voltar à questão do encaminhamento ou VPN. Portanto, já estamos finalizando a versão do Veliam Connector para MacOS. Usuários de sua querida máquina da Apple também terão a oportunidade de se conectar à infraestrutura corporativa com um clique.
Gosto muito do fato de que, tendo um grande número de usuários no sistema, não precisamos quebrar a cabeça sobre o que as pessoas precisam e o que seria mais conveniente. Elas mesmas escrevem suas solicitações, então há muitos planos de desenvolvimento para o futuro próximo.
Paralelamente, estamos planejando agora traduzir o sistema para o inglês e expandi-lo para o exterior. Não sabemos ainda como faremos a distribuição do produto fora do nosso país, estamos em busca de opções. Talvez mais tarde haja um artigo separado sobre isso. Pode ser que alguém que leu este artigo consiga sugerir a direção certa, ou que já saiba como fazer isso e ofereça seus serviços. Agradeceremos pela ajuda.
Fonte: habr.com
