Is it possible to make a program lose and get back it's internet connection by some other means than disconnecting/connecting the cable or putting the interface down/up?

That would be necessary in order to see how that program reacts to such situation.

In this case, it's one program's behaviour that I am interested in, so it would be enough to have just that one application lose its connection, but on the other hand, a solution that causes all programs to lose their connections is fine too.

A non-programmatic example of what I would like to emulate is when you have a switch between the computer and "whatever where the internet comes from" and you disconnect the cable between the internet and the switch. In that case, the computer loses it's connection but there is no way for that computer or the application to detect what exactly happened.

  • 2
    One possibility is running this in a separate namespace, and disabling traffic from flowing out that namespace to the external network. – muru Dec 9 '20 at 7:28
  • One way of realizing @muru 's suggestion can be found here. I.e. you run the command under no-internet-group ID and en/disable iptable rules for processes of said group. – FelixJN Dec 9 '20 at 10:53

If you can know the IP address(es) and port number(s) the program is supposed to communicate with, one possible solution might be using local firewall rules to either DROP all network packets related to the application, or to REJECT them using a custom --reject-with type according to the exact type of outage you wish to simulate.

In the below examples, I'll be using iptables terminology, which should be essentially applicable to firewalld also without major changes, but the same concepts should be applicable to nftables or really any firewall management system.

  • just DROP everything: simulates a network breakage somewhere beyond the local gateway (i.e. connection to the local network segment & gateway still works, but no packets from outside that area are reaching the system at all. This causes network connections to time out. In a real failure situation, once the routers etc. start detecting the failure, this might eventually change into...

  • REJECT using --reject-with icmp-[host|net]-unreachable: the same as before, but now simulating that a router has detected the connection loss and is reporting the error to any host attempting to connect across the failing link. This should cause the application to detect the loss of connection and report an error to the user faster than the timeout case. (Of course, someone might have blocked ICMP error responses between the supposed fault location and your system, so all the connection failures will look like the "DROP everything" case.)

Other possible scenarios:

  • DROP any responses (both TCP and UDP) incoming from port 53 of configured DNS resolver server(s): this simulates a DNS server failure. Existing connections will work, and connections to known IP addresses will still work, but connections by hostname will fail.

  • on TCP ports relevant to the application: REJECT using --reject-with tcp-reset simulates a situation where the service needed by your application is not running on the remote host, but the remote host itself is otherwise working fine. (In other words, this simulates the remote host being rebooted or undergoing maintenance of some sort and having its application-relevant services down.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.