search

activecm / ipfix-rita

Collect IPFIX / Netflow v9 Records and Ship them to RITA for Analysis
https://www.activecountermeasures.com/
10 stars 1 forks source link

Reinstall May Change Docker Network #71

Closed Zalgo2462 closed 5 years ago

Zalgo2462 commented 5 years ago

Currently, when we reinstall IPFix-RITA or install a new version of IPFix-RITA, we wipe everything except the configuration files. However, the config file is often set up to talk to the docker host over the ipfix_rita_default docker network. Unfortunately, when ipfix-rita down is ran, the ipfix_rita_default network is destroyed. When ipfix_rita up --no-start is called in the install script, the ipfix_rita_default network is re-created. Unfortunately, we cannot guarantee the new network is mapped to the same subnet. If the subnet changed, the converter will repeatedly crash after the installer finishes. The` user must then change their config file to use the new subnet. Additionally, they likely need to change their /etc/mongod config,

The solution is to use docker rm on each of the containers rather using docker down. This prevents the deletion of the ipfix_rita_default network.

ethack commented 5 years ago

I don't have any opinion on how you do this, but I wanted to throw out another possible option in case it would help.

Manually specify the network range for the default docker-compose network. Just put this networks block in your docker-compose yaml files and change the range to whatever you want. You don't even need user-defined networks for this as the default block is telling docker-compose to change the settings on its builtin network.

version: "3"

networks:
  default:
    ipam:
      config:
        - subnet: 172.20.0.0/16
Zalgo2462 commented 5 years ago

That would make things rather easy!

Do you think we might run into an issue where that subnet is already in use on a client system. Is it an issue we should worry about?

ethack commented 5 years ago

Lol, that's actually how I discovered this. Short answer: no more worry than the default settings conflicting.

Longer answer: The default range docker picked happened to coincide with the network used for VPN users. This only inconvenienced me as the customer was accessing it locally. But I couldn't talk to the host system at all because of the default route docker put in for that network range. Anything trying to go back to me on the VPN network would get diverted into the docker network and disappear. My fix was to add the block above and change the range to something else.