
A vida de um engenheiro de rede era feliz e despreocupada até que um gateway de criptografia certificado apareceu. Concordo, lidar com soluções projetadas para criptografar canais de transmissão de dados de acordo com GOST não é uma tarefa fácil. É bom se esses produtos forem bem conhecidos e compreensíveis. Lembremos o mesmo "S-Terra" (já escrevemos sobre seu "S-Terra Gateway" ). Mas o que fazer com soluções mais exóticas baseadas em seus próprios protocolos de criptografia, por exemplo, "Continent" (de "Security Code") ou ViPNet Coordinator HW (de "Infotex")? Neste artigo, tentarei facilitar a imersão no mundo da ViPNet (também falaremos sobre o Continente algum dia) e contarei quais problemas eu mesmo enfrentei e como os resolvi.
Vou fazer uma reserva imediatamente que falaremos da versão 4.2.1 certificada pelo FSB e FSTEC para hoje. Nas versões atuais 4.3.x, muitas coisas interessantes apareceram, por exemplo, DGD (Dead Gateway Detection) e um mecanismo de clustering modificado, que fornece comutação quase contínua, mas por enquanto este é o futuro. Não vou mergulhar profundamente nos comandos e arquivos de configuração, concentrando-me nos comandos e variáveis principais, e uma descrição detalhada dessas "chaves" pode ser encontrada na documentação.
Primeiro, vamos descobrir como tudo funciona. Portanto, um coordenador da ViPNet desempenha várias funções. Primeiro, é um gateway criptográfico (CG), que permite tanto Site a site quanto RA VPN. Em segundo lugar, é um servidor-roteador de envelopes contendo dados de serviço criptografados (diretórios e chaves) ou dados de aplicativos clientes (troca de arquivos, correio comercial). A propósito, é nos diretórios que são armazenados os arquivos que contêm informações sobre os objetos da rede ViPNet, incluindo seus nomes, identificadores, endereços, conexões. O coordenador também é uma fonte de informações de atendimento para seus clientes.
Além disso, ele pode encapsular o tráfego de computadores da rede onde o software ViPNet não está instalado. A propósito, as pessoas que trabalham com essa solução costumam se referir a hosts abertos como “túneis” em vez de “nós em túnel”. Isso pode ser confuso para engenheiros que estão acostumados com outras soluções VPN, onde um túnel significa uma conexão PtP entre KSH.

IPlir, também desenvolvido pela Infotex, é usado como protocolo de criptografia em ViPNet. Para encapsular o tráfego, os protocolos de transporte são IP / 241 (se o tráfego não sair do domínio de broadcast), UDP / 55777 e TCP / 80 (se UDP não estiver disponível).
O conceito de construção de conexões seguras é baseado nas chamadas "conexões", que são de dois tipos. Os primeiros (no nível do nó) são necessários para construir uma conexão segura entre os nós, os últimos (no nível do usuário) são necessários para a operação dos aplicativos clientes. Mas há uma exceção: os nós do administrador ViPNet requerem ambos os tipos de comunicação.
O que pode dar errado neste esquema? Como mostra a prática, há realmente muitas peculiaridades de trabalho, e nem todos os problemas podem ser resolvidos intuitivamente, sem “a ajuda do público”, mas algo precisa ser dado como certo.
Coordenador indisponível
“Não temos coordenador / cliente / túnel disponível. O que fazer?" - a pergunta mais frequente que os novatos fazem ao configurar o ViPNet. A única ação correta em tal situação é ativar o registro de todo o tráfego nos coordenadores e examinar o log de pacotes IP, que é a ferramenta mais importante para solucionar todos os tipos de problemas de rede. Este método economiza em 80% dos casos. Trabalhar com o log de pacotes IP também ajuda a entender melhor os mecanismos de operação dos nós da rede ViPNet.
Envelope não entregue
Mas o log de pacotes IP é, infelizmente, inútil quando se trata de envelopes. Eles são entregues usando um módulo de transporte (mftp), que tem seu próprio diário e sua própria fila. Por padrão, os envelopes são enviados para o "próprio" coordenador do cliente (ou seja, aquele no qual o nó está registrado) e, em seguida, através dos canais entre servidores que são configurados entre os coordenadores (ou seja, não diretamente por um canal seguro). Isso significa que se você quiser enviar uma carta pelo correio comercial, o cliente a embalará em um envelope e enviará primeiro ao seu coordenador. Mais adiante, pode haver vários outros coordenadores, e só depois disso o envelope chegará ao nó do destinatário.
Duas conclusões decorrem disso. Em primeiro lugar, a comunicação entre clientes não tem de ser verificada (premindo F5 e o ícone correspondente no menu) para a entrega dos envelopes. Em segundo lugar, se a conexão entre eles ainda estiver verificada, isso não garante a entrega, uma vez que o problema pode ser em um dos canais entre servidores.
Em casos não óbvios, é possível diagnosticar a passagem de envelopes por canais interservidores ou entre um cliente e um coordenador usando o diário e a fila de envelopes, bem como registros do coordenador. Além disso, o módulo de transporte do cliente ViPNet pode ser configurado para entrega direta de envelopes, entrega por meio de uma pasta compartilhada ou SMTP / POP3 (mas esta é uma opção completamente exótica). Não vamos mergulhar nessas configurações.
Consequências de piscar
Pode ser problemático atualizar para a versão atual de peças antigas de hardware que estão em uso por muito tempo, por exemplo, como uma peça sobressalente. No processo, um erro de "hardware não suportado" pode aparecer, o que indica que você realmente tem uma plataforma de hardware não suportada da linha G1 desatualizada (estes são HW100 E1 / E2 e HW1000 Q1), ou sobre problemas na configuração do BIOS ou informações incorretas embutidas no DMI. Se é para gerir o DMI por conta própria, cada um decide por si, pois corre-se o risco de transformar o equipamento num "tijolo" inútil. Com o BIOS, é um pouco mais fácil: as configurações incorretas do sistema estão na função HT (Hyper Threading) desabilitada ou no modo ACHI (Advanced Host Controller Interface) desabilitado para HDD. Para não adivinhar qual é exatamente o problema, consulte a unidade flash USB a partir da qual o firmware está sendo produzido.Arquivos com informações de diagnóstico são criados nele, em particular, todas as plataformas suportadas são listadas no arquivo verbose.txt com o resultado da verificação com o seu. Por exemplo, o erro cpu :: Vendor (# 3) == 'GenuineIntel' 24 vezes => [Falha] provavelmente indica que o HT está desativado. By the way, flashing é frequentemente confundido com atualização, mas esses são processos diferentes. Durante a atualização, todas as configurações são salvas e os parâmetros descritos acima não são verificados. E ao fazer o reflash, você retorna às configurações de fábrica.Durante a atualização, todas as configurações são salvas e os parâmetros descritos acima não são verificados. E ao fazer o reflash, você retorna às configurações de fábrica.Durante a atualização, todas as configurações são salvas e os parâmetros descritos acima não são verificados. E ao fazer o reflash, você retorna às configurações de fábrica.
Configurações não informativas
O arquivo de configuração principal do HW é "iplir.conf", mas nem sempre reflete as configurações atuais. O fato é que no momento de carregar o driver IPlir, esta configuração é interpretada de acordo com a lógica configurada, e nem todas as informações podem ser carregadas no driver (por exemplo, se houver conflitos de endereço IP). Os engenheiros que trabalharam com o coordenador de software Linux provavelmente estão cientes do comando "iplirdiag", que exibe as configurações de nó atuais carregadas no driver. No HW, este comando também está presente no modo "escape admin".
As saídas mais populares são:
iplirdiag -s ipsettings --node-info <id do nó> ## exibe informações sobre um nó
iplirdiag -s ipsettings --v-tun-table ## exibe todos os túneis carregados no driver
Vamos nos deter um pouco no modo "escape admin". Na verdade, esta é uma saída do shell ViPNet para o bash. Aqui concordo com o fornecedor, que recomenda usar este modo apenas para diagnóstico e fazer quaisquer modificações apenas sob a supervisão do suporte técnico do fornecedor. Este não é o seu Debian usual, aqui qualquer movimento descuidado pode desabilitar o sistema operacional, os mecanismos de proteção que irão perceber sua "iniciativa" como uma ameaça potencial. Em conjunto com o BIOS bloqueado por padrão, isso condena você a reparos fora da garantia (leia-se "caros").
(Des) tunelamento dividido
Outro fato que nem todos sabem: por padrão, o cliente ViPNet trabalha em modo de túnel dividido (quando você pode especificar qual tráfego envolver no túnel e qual não). ViPNet possui a tecnologia "Open Internet" (posteriormente renomeada para "Protected Internet Gateway"). Muitas pessoas atribuem erroneamente essa funcionalidade ao coordenador e não ao cliente. Em um cliente registrado com um coordenador com esta função, dois conjuntos de filtros predefinidos são criados. O primeiro permite interação apenas com o próprio coordenador e seus túneis, o segundo - com outros objetos, mas nega o acesso ao coordenador OI e seus túneis. Além disso, de acordo com o conceito do fornecedor, no primeiro caso, o coordenador deve encapsular o servidor proxy ou ser ele próprio um servidor proxy. Tráfego do serviço, bem como recepção e transmissão de envelopes (ambos os serviços,e aplicativos) funcionam em qualquer configuração.
TCP-
Uma vez me deparei com um aplicativo que não queria funcionar de forma alguma por meio do coordenador. Foi assim que fiquei sabendo que o coordenador possui portas de serviço pelas quais o tráfego não criptografado é bloqueado sem a possibilidade de qualquer configuração. Isso inclui UDP / 2046,2048,2050 (serviços ViPNet básicos), TCP / 2047,5100,10092 (para ViPNet Statewatcher) e TCP / 5000-5003 (MFTP). Aqui eu resumi as funções do túnel TCP. Não é segredo que os ISPs adoram filtrar portas UDP altas, então os administradores, em um esforço para melhorar a disponibilidade de seus CNs, habilitam o recurso de túnel TCP. Nesse caso, os recursos na DMZ (por meio da porta do túnel TCP) ficam indisponíveis. Isso se deve ao fato de que a porta do túnel TCP também se torna um serviço, e não há mais regras de firewall e regras NAT (Network Address Translation). É difícil diagnosticar o fato de queque esse tráfego não está sendo registrado no log de pacotes IP como se não estivesse lá.
Substituindo o coordenador
Mais cedo ou mais tarde surge a questão de substituir o coordenador por uma opção mais produtiva ou temporária. Por exemplo, substituindo HW1000 por HW2000 ou coordenador de software por PAK e vice-versa. A dificuldade reside no fato de que cada performance tem sua “função” própria no NCC (Network Control Center). Como mudar corretamente o papel sem perder a coesão? Primeiro, no NCC mudamos a função para uma nova, diretórios de formulário, mas não os enviamos (!). Em seguida, liberamos um novo arquivo DST no UCC e inicializamos o novo Coordenador. Em seguida, fazemos a reposição e, depois de nos certificarmos de que todas as interações estão funcionais, enviamos os livros de referência.
Clustering e falha de nó
Uma reserva ativa é obrigatória para qualquer site grande, portanto, um cluster de modelos mais antigos (HW1000, HW2000, HW5000) sempre foi adquirido deles. No entanto, a criação de um cluster a partir de gateways de criptografia mais compactos (HW50 e HW100) foi impossível devido à política de licenciamento do fornecedor. Como resultado, os proprietários de pequenos sites tiveram que pagar caro demais e comprar o HW1000 (bom ou sem tolerância a falhas). Este ano, o fornecedor finalmente fez licenças adicionais para modelos de coordenador júnior. Portanto, com o lançamento das versões 4.2.x, tornou-se possível agrupá-los em um cluster.
Ao configurar um cluster pela primeira vez, você pode economizar muito tempo não configurando interfaces no modo de assistente ou usando comandos CLI. Você pode inserir imediatamente os endereços necessários no arquivo de configuração do cluster (edição de configuração de failover), mas não se esqueça de especificar as máscaras. Quando o daemon de failover é iniciado no modo de cluster, ele atribuirá endereços às interfaces correspondentes por si mesmo. Ao mesmo tempo, muitos têm medo de parar o daemon, supondo que os endereços sejam alterados para endereços passivos ou de modo único. Não se preocupe: as interfaces manterão os endereços que estavam no momento em que o daemon foi interrompido.
Na versão do cluster, há dois problemas comuns: reinicialização cíclica do nó passivo e sua falha ao alternar para o modo ativo. Para entender a essência desses fenômenos, vamos entender o mecanismo de operação do cluster. Assim, o nó ativo conta os pacotes na interface e, se não houver pacotes no tempo alocado, envia um ping para testip. Se o ping for aprovado, o contador será reiniciado; se não for, uma falha de interface será registrada e o nó ativo será reinicializado. Ao mesmo tempo, o nó passivo envia solicitações ARP regulares em todas as interfaces descritas em failover.ini (o arquivo de configuração do cluster, que contém os endereços que os nós ativos e passivos recebem). Se o registro ARP de pelo menos um endereço desaparecer, o nó passivo muda para o modo ativo.
Voltemos aos problemas de cluster. Vou começar com um simples - não alternar para o modo ativo. Se não houver um nó ativo, mas seu endereço mac ainda estiver presente no passivo na tabela ARP (inet show mac-address-table), você precisará ir aos administradores do switch (o cache ARP está configurado dessa maneira ou é algum tipo de falha ) O recarregamento cíclico do nó passivo é um pouco mais complicado. Isso ocorre devido ao fato de que o passivo não vê o registro ARP ativo, entra no modo ativo e (atenção!) Pesquisa o vizinho através do link HB. Mas nosso vizinho está no modo ativo e tem mais tempo de atividade. Nesse momento, o nó passivo percebe que algo está errado, pois um conflito de estado surgiu, e faz uma reinicialização. Isso continua indefinidamente. Se esse problema ocorrer, você precisará verificar as configurações de endereço IP em failover.ini e a comutação.Se todas as configurações do coordenador estiverem corretas, é hora de conectar os engenheiros de rede à questão.
Endereços de cruzamento
Em nossa prática, frequentemente encontramos a interseção de endereços em túnel atrás de diferentes coordenadores.

É para esses casos que há virtualização de endereços nos produtos ViPNet. A virtualização é um tipo de NAT sem monitorar o estado de uma conexão um-para-um ou intervalo a intervalo. Por padrão, esta função está desabilitada nos coordenadores, embora você possa encontrar endereços virtuais potenciais em iplir.conf na linha "túnel" após "para" nas seções dos coordenadores vizinhos. Para habilitar a virtualização globalmente para toda a lista, na seção [visibilidade], altere o parâmetro "tunneldefault" para "virtual". Se você deseja habilitar para um vizinho específico, você precisa adicionar o parâmetro "tunnelvisibility = virtual" em sua seção [id]. Também vale a pena verificar se o parâmetro tunnel_local_networks está definido como "on". Para editar endereços virtuais, o parâmetro tunnel_virt_assignment deve ser definido para o modo "manual".No lado oposto, você precisa realizar ações semelhantes. Os parâmetros "usetunnel" e "exclude_from_tunnels" também são responsáveis pelas configurações do túnel. O resultado do trabalho realizado pode ser verificado usando o utilitário "iplirdiag", que mencionei acima.
Obviamente, os endereços virtuais trazem alguns inconvenientes, então os administradores de infraestrutura preferem minimizar seu uso. Por exemplo, quando as organizações se conectam aos sistemas de informação (SI) de algumas agências governamentais, essas organizações recebem um arquivo DST com um intervalo fixo de túneis do plano de endereços de SI. Como podemos ver, os desejos da pessoa que faz a conexão não são levados em consideração. Como se encaixar nessa piscina, cada um decide por si. Alguém migra estações de trabalho para um novo endereçamento e alguém usa SNAT no caminho dos hosts para o coordenador. Não é segredo que alguns administradores usam SNAT para contornar as restrições de licenciamento de plataformas inferiores. Não nos comprometemos a avaliar a ética de tal "life hack", mas não se esqueça que o desempenho das próprias plataformas ainda tem um limite,e quando sobrecarregado, a qualidade do canal de comunicação começará a piorar.

Incapacidade de trabalhar GRE
Obviamente, cada solução de TI tem suas próprias limitações nos casos de uso com suporte, e o Coordenador ViPNet não é exceção. Um problema bastante irritante é a incapacidade de trabalhar o GRE (e os protocolos que o utilizam) de várias fontes para o mesmo destino via SNAT. Considere, por exemplo, um sistema cliente-banco que configura um túnel PPTP para o endereço público de um banco. O problema é que o protocolo GRE não usa portas, então depois que o tráfego passa pelo NAT, o socketpair desse tráfego torna-se o mesmo (temos o mesmo endereço de destino, o protocolo é o mesmo e acabamos de traduzir o endereço de origem em um endereço). O coordenador reage a isso bloqueando o tráfego no fundo do erro 104 - Conexão já existe. Se parece com isso:

Portanto, se você estiver usando várias conexões GRE, deve evitar aplicar o NAT a essas conexões. Como último recurso, execute a transmissão 1: 1 (embora, ao usar endereços públicos, essa seja uma solução pouco prática).

Não se esqueça do tempo
Continuamos o tópico de bloqueio com o evento número 4 - tempo limite do pacote IP. Tudo é banal aqui: este evento ocorre quando há uma discrepância entre o tempo absoluto (excluindo fusos horários) entre os nós da rede ViPNet (coordenadores e clientes ViPNet). Nos coordenadores de HW, a diferença máxima é de 7200 segundos e é definida no parâmetro "timediff" do arquivo de configuração IPlir. Não considero os coordenadores de HW-KB neste artigo, mas é importante notar que na versão KB2 o timediff é 7 segundos por padrão, e no KB4 é 50 segundos, e o evento pode ser gerado não 4, mas 112, o que pode ser confuso um engenheiro acostumado a HW "normal".
Tráfego não criptografado em vez de criptografado
Pode ser difícil para iniciantes entender a natureza do evento 22 - Pacote IP não criptografado do nó da rede - no log do pacote IP. Isso significa que o coordenador esperava tráfego criptografado desse endereço IP, mas veio tráfego não criptografado. Na maioria das vezes, acontece assim:
- ViPNet-, , . IPlir , , , . , : ViPNet-, – . , , , . , , , ViPNet-, . , ViPNet-, ;
- . , , ( ). , , , ;
- . , . , «» . , , , 22 .
(ALG)
Muitos firewalls, incluindo ViPNet Coordinator, podem ter problemas com SIP passando por NAT. Dado que os endereços virtuais são NAT interno, o problema pode ocorrer mesmo quando explicitamente o NAT não é usado e apenas endereços virtuais são usados. O coordenador possui um módulo de processamento de protocolo de aplicação (ALG) que deve solucionar esses problemas, mas nem sempre funciona como desejado. Não vou me alongar sobre o mecanismo do ALG (um artigo separado pode ser escrito sobre esse tópico), o princípio é o mesmo para todos os ITUs, apenas os títulos do nível de aplicativo mudam. Para o correto funcionamento do protocolo SIP por meio do coordenador, você precisa saber o seguinte:
- ALG deve ser habilitado ao usar NAT;
- ao usar endereçamento virtual, ALG deve ser habilitado em ambos os nós que participam da interação (coordenador-coordenador, coordenador-cliente), mesmo se a visibilidade virtual for configurada em apenas um lado;
- ao usar visibilidade real e não houver NAT, você deve desligar o ALG para que não interfira com o SIP;
- As linhas ALG 3.xe 4.x são incompatíveis (estritamente falando, na linha 3.x não havia nenhuma maneira de controlá-lo). Em tal cenário, o fornecedor não pode garantir o funcionamento correto do SIP.
O módulo é controlado pelos comandos do grupo "módulo alg" do modo privilegiado (habilitar).
Finalmente
Procurei considerar os problemas mais urgentes, identificar suas raízes e conversar sobre soluções. Claro que estão longe de ser todas as funcionalidades da ViPNet, então recomendo não ser tímido - contate o suporte e peça conselhos na comunidade (no fórum do vendedor, no canal de telegramas, nos comentários deste post). E se você não quer mergulhar em todas as dificuldades de trabalhar com ViPNet ou é muito trabalhoso, então você sempre pode deixar o gerenciamento de sua rede ViPNet nas mãos de profissionais.
Autor: Igor Vinokhodov, engenheiro da 2ª linha de administração, Rostelecom-Solar