Pon a pasarela VPN ao lado de Windows XP, non dentro

Nalgún lugar do edificio hai unha máquina que executa unha aplicación que ninguén pode substituír, sobre un sistema operativo que non debería conectarse a nada. Saír do adaptador de rede dese host é a forma máis rápida de ver onde pertence o túnel. Na maioría dos deseños non pertence ao host en absoluto. Móveo un salto cara a fóra, a unha pasarela mantida, e o problema antigo redúcese á aplicación coa que comezou.

Comeza polo adaptador do host, non por un cliente VPN

Abre as propiedades do adaptador e dálle ao host un enderezo fixo nun segmento pequeno e dedicado, coa pasarela como a súa ruta predeterminada. O host xa non necesita cliente de túnel, credenciais de túnel nin entradas da táboa de rutas cara á rede corporativa máis ampla. Se a aplicación necesita unha única subrede remota, engade exactamente esa única ruta.

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

Ese comando fixa un único destino á pasarela e deixa todo o demais sen ruta, que é a forma que se busca. Confirma o resultado con route print en lugar de confiar no código de saída. Despois comproba que a aplicación segue resolvendo o nome do seu servidor, porque un host antigo cun resolvedor roto parece exactamente un fallo de rede, e arranxar o resolvedor é un traballo de cinco minutos mentres que reconstruír unha aplicación tras un cambio de rede equivocado non o é. Cada destino ao que o host non pode chegar é unha cousa menos á que se pode persuadir unha pila de rede antiga de atacar.

Pon o túnel en hardware que poidas actualizar

A pasarela quere dúas interfaces: unha fronte ao segmento do host e outra fronte a onde vive a aplicación, co túnel terminando na segunda. Ese dispositivo pode recibir actualizacións de firmware, substituír a súa configuración criptográfica e rexistrar fluxos sen que ninguén toque a máquina antiga. O seu provedor tamén publica correccións para a implementación do túnel, que o host nunca recibirá. Dúas máquinas e unha data límite non son razón para copiar unha receita de segredo estático dunha publicación de foro.

Dálle a cada pasarela a súa propia identidade de par en lugar de clonar unha configuración de cliente por toda unha frota. Cando se substitúe unha unidade, revoga a identidade antiga no mesmo momento en que poñes a nova en liña, ou acabarás con dúas copias sen control que se autentican no mesmo extremo. Garda as claves onde as espera o plano de xestión da pasarela, trata unha copia de seguridade da configuración como un segredo e revisa quen pode enviar esa configuración, porque agora decide a que pode chegar o host antigo.

Permite servizos, non redes

Escribe a política en termos de protocolo, porto e dirección entre as dúas conexións. Un só porto permitido cara a un só enderezo de aplicación é a resposta habitual, e unha ruta administrativa a través dun host de salto cobre o resto.

A administración remota do host antigo non debería ir pola mesma regra que a aplicación, e probar o rexeitamento importa tanto como escribir a regra. Envía unha petición desde o host a un destino que esperes que se rexeite e confirma que o rexeitamento vén da política e non dunha ruta ausente. Rexistra os fluxos que permites mentres o deseño é novo, para ver que usa realmente a aplicación e non o que afirma a súa documentación. Fusionar dúas subredes porque un titorial ponteado parecía máis curto é como un segmento antigo se converte silenciosamente nun trampolín.

Non expoñas o receptor antigo directamente a internet como atallo arredor da pasarela. Mantén a ruta administrativa separada da ruta da aplicación para que o compromiso dunha non entregue a outra. Unha regra que nunca se exerce é unha regra que ninguén verificou, e por iso o destino denegado pertence á execución de aceptación.

A recuperación ten que funcionar sen o túnel

Decide quen actualiza e recupera a pasarela antes do primeiro corte e asegúrate de que esa persoa poida chegar a ela sen o túnel que termina. O acceso por consola, un porto de xestión local ou unha ruta fóra de banda contan todos como respostas. Unha pasarela que só se pode configurar a través do túnel que proporciona é unha trampa que espera pacientemente un mal envío de firmware.

Escribe o manual para o fallo que atoparás de verdade: túnel caído, pasarela morta, disco do host perdido. Mantén a imaxe de recuperación do host baixo o acordo de soporte que aínda exista, e lembra que unha restauración tamén restaura o estado do software e as credenciais dentro desa imaxe. Restaura primeiro no segmento illado, confirma que a aplicación arrinca e só entón volve conectar algo; cando cambie a pasarela, actualiza o manual e o inventario na mesma sesión.

Certificados, reloxos e avisos de sinatura

A caducidade do certificado dun instalador non predí por si soa o que dirá hoxe unha comprobación de sinatura. A guía de Microsoft sobre selos de tempo de Authenticode explica que un selo de tempo pode manter verificable unha sinatura despois de que caduque o certificado de sinatura, e a validación segue dependendo da sinatura, a cadea de confianza e o verificador que fai o traballo. Dúas máquinas con almacéns de confianza distintos poden, por tanto, discrepar sobre o mesmo ficheiro. Un firmante caducado non é proba de que un binario sexa malicioso, e unha sinatura válida non é proba de que o software se manteña.

Non atrases o reloxo do sistema nin desactives as comprobacións de sinatura para que funcione un instalador antigo. Obtén un artefacto autorizado de quen aínda lle dea soporte á aplicación e deixa que digan que acepta a plataforma. Trata as publicacións que afirman que unha compilación concreta foi a última para XP como historia, non como obxectivo de instalación, porque o requisito real depende da aplicación; se o traballo de preservación é realmente necesario, manteno nun segmento illado lonxe do acceso de produción e documenta por que existe.