Simulando el host inalcanzable: cómo lograrlo/implementarlo

Question

Aquí está mi escenario:

A es un servidor de aprovisionamiento y B es un cliente. Siempre que haya algún cambio en la configuración de B, se cargará el archivo de configuración apropiado en A.

Estoy trabajando como ingeniero de automatización para automatizarlo. Uno de los escenarios indica desconectar A de la red o detener el servidor A. realizar algunos cambios en B y asegurarse de que B no pudo cargar los archivos en el servidor de aprovisionamiento A.

Para automatizarlo, la forma más sencilla de detener el servidor A y haga las acciones apropiadas.

Desde A y B también se utilizan para otros fines por otras partes, así que no puedo desconexión de A o B de la red o detener el servidor en A.

Por lo tanto, estoy deseando para cualquier solución para que Puedo simular el escenario host (servidor de suministro) inalcanzable. Entonces, cuando B enviará una actualización a A, fallará, pero en A real se está ejecutando como de costumbre.

Por favor sugiérame alguna forma de lograrlo.

Estoy usando Perl como lenguaje de programación pero estoy bien si la solución está disponible en otro idioma.

Answer 1

He hecho esto antes de usar una ruta nula. Esto es algo que se hace mejor desde el shell con el comando ip.

# blackhole all packets destined for 192.168.2.1 
ip route add blackhole 192.168.2.1 
# to delete the same route, replace add with del 
ip route del blackhole 192.168.2.1 

Dependiendo de su caso de uso, una ruta inalcanzable puede funcionar mejor, ya que vuelve ICMP inalcanzable en lugar de descartar los paquetes, a pesar de que tienden a tener el mismo efecto.

ip route add unreachable 192.168.2.1 

Y por la minuciosidad, si realmente quería para simular una situación de acogida-inalcanzable (vs una red inalcanzable), que tendría que hacer eso a nivel de cortafuegos.

# resond with icmp-host-unreachable for *any* outbound packet to 192.168.2.1 
iptables -I OUTPUT -d 192.168.2.1 -j REJECT --reject-with=icmp-host-unreachable 
# delete the same rule (without looking up the rule #) 
iptables -D OUTPUT -d 192.168.2.1 -j REJECT --reject-with=icmp-host-unreachable 

Answer 2

Otra opción, quizás más fácil es cambiar la configuración en B para tener una dirección IP falsa para A (por ejemplo, 192.0.2.0) cuando se realiza la prueba.

Answer 3

Test::MockObject::Extends: excelente para modificar partes pequeñas de módulos para crear escenarios de prueba específicos. Funciona muy bien para cosas que no puedes probar bien porque afectan cosas en producción o en lugares que no controlas.

#!/usr/bin/perl 

use strict; 
use warnings; 
use Test::MockObject::Extends; 

#Fake module that has your remote connect subroutine 
use Fake::Module; 

my $object = Fake::Module->new(); 

#replace your obj with a copy that Test::MO:E will let us mess with 
$object = Test::MockObject::Extends->new($object) 

#replace your connect function with a temp fake version 
$object->mock(
    'your_remote_connect_sub' => sub { 
     #Whatever data that should returned by your connect function if the server is unavailable 
     return undef; 
    }, 
); 

#test your sub now 
if (!defined($object->your_remove_connect_sub())) { 
    print "Remote server unavailable\n"; 
}