模拟主机无法访问 - 如何实现/实现

发布于 2024-10-22 05:20:19 字数 413 浏览 4 评论 0原文

这是我的场景:

A 是配置服务器,B 是客户端。每当 B 的设置发生任何更改时,它都会将适当的配置文件上传到 A。

我正在作为自动化工程师来实现它的自动化。其中一种场景是断开 A 与网络的连接或停止服务器 A。对 B 进行一些更改,并确保 B 无法将文件上传到配置服务器 A。

要实现自动化,可以停止服务器 A 并执行以下操作:适当的行动。

由于 A 和 B 也被其他方用于其他目的,所以我无法断开 A 或 B 与网络的连接或停止 A 处的服务器。

因此,我期待任何解决方案,以便我可以模拟主机(配置服务器) ) 无法到达的场景。因此,当 B 向 A 发送更新时,它将失败,但实际上 A 照常运行。

请建议我一些方法来实现它。

我使用 Perl 作为编程语言,但如果有其他语言的解决方案,我也很好。

Here is my scenario:

A is a provisioning server and B is an client. Whenever there is any change in B's setup, it uploads the appropriate config file to A.

I am working as an automation engineer to automate it. One of the scenario says to disconnect A from network or stop the server A. perform some changes to B and make sure that B failed to upload the files to provisioning server A.

To automate it, the simple way to stop the server A and do the appropriate actions.

Since A and B are also used for other purposes by other parties so I can not either disconnect A or B from network OR stop the server at A.

So, I am looking forward for any solution so that I can simulate the host (provisioning server) unreachable scenario. So when B will send an update to A it will fail but in actual A is running as usual.

Please suggest me some way to achieve it.

I am using Perl as a programming language but I am fine if solution is available in other language.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

吹梦到西洲 2024-10-29 05:20:19

我在使用空路由之前已经完成了此操作。最好使用 ip 命令从 shell 完成此操作。

# 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

根据您的使用案例,无法访问的路由可能会工作得更好,因为它返回 ICMP 无法访问而不是丢弃数据包,尽管它们往往具有相同的效果。

ip route add unreachable 192.168.2.1

为了彻底起见,如果您确实想模拟主机无法访问的情况(相对于网络无法访问的情况),则必须在防火墙级别执行此操作。

# 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

I've done this before using a null route. This is something that best done from the shell with the ip command.

# 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

Depending on your use case, an unreachable route may work better, as it returns ICMP-unreachable instead of discarding the packets, although they tend to have the same effect.

ip route add unreachable 192.168.2.1

And for thoroughness, if you really wanted to simulate a host-unreachable situation (vs a network-unreachable), you would have to do that at the firewall level.

# 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
空气里的味道 2024-10-29 05:20:19

另一个可能更简单的选择是在执行测试时更改 B 上的配置,使 A 具有虚假的 IP 地址(例如 192.0.2.0)。

Another, perhaps easier option is to change the configuration on B to have a bogus IP address for A (e.g. 192.0.2.0) when performing the test.

撩动你心 2024-10-29 05:20:19

Test::MockObject::Extends - 非常适合修改模块的小部分以创建特定的测试场景。对于您无法很好测试的事情非常有效,因为它们会影响生产中的事情或您无法控制的地方。

#!/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";
}

Test::MockObject::Extends - great for modifying small parts of modules to create specific testing scenarios. Works great for things that you can't test well because they affect things in production or in places that you don't control.

#!/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";
}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文