Coloque o gateway VPN ao lado do Windows XP, não dentro dele

Em algum lugar do edifício está uma máquina que executa uma aplicação que ninguém pode substituir, sobre um sistema operativo que não deveria ser ligado a nada. Sair do adaptador de rede desse host é a forma mais rápida de ver onde o túnel deve estar. Na maioria dos desenhos, não pertence ao host de todo. Mova-o um salto para fora, para um gateway mantido, e o problema antigo encolhe de volta à aplicação com que começou.

Comece pelo adaptador do host, não por um cliente VPN

Abra as propriedades do adaptador e dê ao host um endereço fixo num pequeno segmento dedicado, com o gateway como a sua rota predefinida. O host deixa de precisar de cliente de túnel, credenciais de túnel ou entradas da tabela de rotas para a rede corporativa mais ampla. Se a aplicação precisar de uma única sub-rede remota, acrescente exatamente essa única rota.

C:\> route add 10.20.30.0 mask 255.255.255.0 192.168.50.1 -p

Esse comando fixa um único destino ao gateway e deixa todo o resto sem rota, e é essa a forma pretendida. Confirme o resultado com route print em vez de confiar no código de saída. Depois verifique se a aplicação ainda resolve o nome do seu servidor, porque um host antigo com um resolver avariado parece exatamente uma falha de rede, e reparar o resolver é um trabalho de cinco minutos enquanto reconstruir uma aplicação após uma alteração de rede errada não é. Cada destino que o host não alcança é uma coisa menos a que uma pilha de rede antiga pode ser persuadida a atacar.

Coloque o túnel em hardware que possa atualizar

O gateway quer duas interfaces: uma virada para o segmento do host e outra virada para onde vive a aplicação, com o túnel a terminar na segunda. Esse dispositivo pode receber atualizações de firmware, substituir a sua configuração criptográfica e registar fluxos sem que ninguém toque na máquina antiga. O fornecedor também fornece correções para a implementação do túnel, que o host nunca receberá. Duas máquinas e um prazo não são razão para copiar uma receita de segredo estático de uma publicação de fórum.

Dê a cada gateway a sua própria identidade de par em vez de clonar uma configuração de cliente por toda uma frota. Quando uma unidade é substituída, revogue a identidade antiga no mesmo momento em que coloca a nova online, ou fica com duas cópias não controladas a autenticar no mesmo extremo. Guarde as chaves onde o plano de gestão do gateway as espera, trate uma cópia de segurança da configuração como um segredo e reveja quem pode enviar essa configuração, porque agora é isso que decide a que o host antigo pode chegar.

Permita serviços, não redes

Escreva a política em termos de protocolo, porta e direção entre as duas ligações. Uma única porta permitida para um único endereço de aplicação é a resposta habitual, e um caminho administrativo através de um host de salto cobre o resto.

A administração remota do host antigo não deve seguir a mesma regra da aplicação, e testar a recusa importa tanto como escrever a regra. Envie um pedido do host para um destino que espera ser recusado e confirme que a recusa vem da política e não de uma rota em falta. Registe os fluxos que permite enquanto o desenho é novo, para ver o que a aplicação realmente usa e não o que a sua documentação afirma. Fundir duas sub-redes porque um tutorial com bridge parecia mais curto é como um segmento antigo se torna silenciosamente num trampolim.

Não exponha o antigo listener diretamente à internet como atalho em torno do gateway. Mantenha o caminho administrativo separado do caminho da aplicação para que o compromisso de um não entregue o outro. Uma regra que nunca é exercida é uma regra que ninguém verificou, e por isso o destino negado pertence à execução de aceitação.

A recuperação tem de funcionar sem o túnel

Decida quem atualiza e recupera o gateway antes da primeira interrupção e garanta que essa pessoa lhe consegue chegar sem o túnel que ele termina. Acesso por consola, uma porta de gestão local ou um caminho fora de banda contam todos como respostas. Um gateway que só pode ser configurado através do túnel que fornece é uma armadilha que espera pacientemente por um mau envio de firmware.

Escreva o runbook para a falha que realmente vai encontrar: túnel em baixo, gateway morto, disco do host desaparecido. Mantenha a imagem de recuperação do host ao abrigo de qualquer acordo de suporte que ainda exista, e lembre-se de que um restauro também restaura o estado do software e as credenciais dentro dessa imagem. Restaure primeiro no segmento isolado, confirme que a aplicação arranca e só depois volte a ligar algo; quando o gateway mudar, atualize o runbook e o inventário na mesma sessão.

Certificados, relógios e avisos de assinatura

A expiração do certificado de um instalador não prevê por si só o que uma verificação de assinatura dirá hoje. As orientações da Microsoft sobre carimbos de tempo Authenticode explicam que um carimbo de tempo pode manter uma assinatura verificável depois de o certificado de assinatura expirar, e a validação continua a depender da assinatura, da cadeia de confiança e do verificador que faz o trabalho. Duas máquinas com armazenamentos de confiança diferentes podem, por isso, discordar sobre o mesmo ficheiro. Um signatário expirado não é prova de que um binário seja malicioso, e uma assinatura válida não é prova de que o software seja mantido.

Não recue o relógio do sistema nem desative as verificações de assinatura para fazer um instalador antigo funcionar. Obtenha um artefacto autorizado junto de quem ainda suporta a aplicação e deixe que digam o que a plataforma aceita. Trate as publicações que afirmam que uma determinada compilação foi a última para XP como história, não como alvo de instalação, porque o requisito real depende da aplicação; se o trabalho de preservação for realmente necessário, mantenha-o num segmento isolado longe do acesso de produção e documente porque existe.