Re: Testing and emulation with network namespaces
"Tsaousis, Costa" <[email protected]>
| Newsgroups | gmane.comp.security.firewalls.firehol.user,gmane.comp.security.firewalls.firehol.devel |
|---|---|
| Message-ID | <CANL+VpYd3dHggeu-CgSMX+myDNp-BhAGR+T+T5WfoTEZFkSXQA@mail.gmail.com> |
Hi Phil, this is very nice. I have a few questions: 1. Can a physical lan be linked to a virtual switch? For example, I have two ethernet devices, can I link each of these to a different virtual switch with a different virtual gateway? 2. Can physical ethernet vlans join virtual switches? 3. Is QoS operational on the virtual ethernets? This opens a whole set of new possibilities for QoS. 4. Last time I checked, namespaces had an issue with logging, especially kernel logging. I was unable to monitor the iptables logs of the namespaces. Have you found any solution? Costa On Wed, Apr 1, 2015 at 12:49 AM, Phil Whineray <[email protected]> wrote: > Hi > > I've been on a bit of a mission trying to work out the best way of dealing > with mixed router/bridge configurations which took me down the path of > wanting to emulate complex network setups. > > Since linux 2.6.24 there has been support for network namespaces. These > are used in the firehol unit tests just to prevent messing with your normal > firewall set. > > Much more can be done though, see https://lwn.net/Articles/580893/ > for some info. I now have a script which can take a setup file with > a simple format and automate the setup of a virtual network of hosts > and switches of arbitrary complexity. See below for a complete setup. > > There is currenly no attempt to connect to the root namespace (and > hence the outside world) - that will need to be done manually if you > really need it. > > The question I have - is it useful enough to include in the firehol > tree, either as a testing helping tool or even main script? Also, has > anyone got a good name for it? > > Cheers > Phil > > > # This definition sets up a network according to the diagram below which > # covers a multitude of possible scenarios. > # > # Key: > # hostname > # [device] (hosts have just a [veth0] unless otherwise noted) > # (switch) > # > # host21 +- host01 host41 > # | | | > # | host22 +- host02 | host42 > # | | | (sw0) | | > # | | . . . . . . . . | . . . . . . . . . | | > # | | . [veth0] . | | > # +-----+----[vbr0eth2] | [vbr1eth4]----+-----+ > # (sw2) . | | fw | . (sw4) > # . + [vbr0]--+---[vbr1] + . > # (sw3) . | | | . (sw5) > # +-----+----[vbr0eth3] | [vbr1eth5]----+-----+ > # | | . [veth1] . | | > # | | . . . . . . . . | . . . . . . . . . | | > # | | | (<direct>) | | > # | host31 [veth0] | host52 > # | gw | > # host32 [veth1] [veth2] host51 > # (<direct>) / \ (<direct>) > # host11 host12 > # > # A network namespace is created for each host and switch to keep everything > # isolated. The name of the host or switch is the name used for the namespace > # making it easy to use "ip netns exec" to specify where commands should run. > # > # Examples: > # Tcpdump traffic passing through a switch > # sudo ip netns exec sw0 tcpdump -i switch -w capfile > # Tcpdump traffic seen by a device on a host > # sudo ip netns exec host12 tcpdump -i veth0 -w capfile > # Ping "from" host01 (10.0.0.1) to host12 via switch sw0 and hosts fw and gw: > # sudo ip netns exec host01 ping 192.168.2.12 > # Start netcat on port 23 of host52 to receive telnet: > # sudo ip netns exec host52 nc -l -p 23 > # telnet "from" host21 (10.0.0.1) to host52 via fw, switches and bridges: > # sudo ip netns exec host21 telnet 10.45.45.52 > # Panic firehol in fw host namespace (now previous commands are blocked): > # sudo ip netns exec fw sbin/firehol.in panic > # > # Note that there are no virtual machines in use, all processing is done > # on the host but with separate views of what the network looks like. > # > > host fw > dev veth0 10.0.0.254/24 > dev veth1 10.1.1.254/24 > dev vbr0eth2 > dev vbr0eth3 > dev vbr1eth4 > dev vbr1eth5 > bridgedev vbr0 vbr0eth2 vbr0eth3 10.23.23.254/24 > bridgedev vbr1 vbr1eth4 vbr1eth5 10.45.45.254/24 > route default via 10.1.1.253 > exec echo 1 > /proc/sys/net/ipv4/ip_forward > > host gw > dev veth0 fw/veth1 10.1.1.253/24 > dev veth1 192.168.1.254/24 > dev veth2 192.168.2.254/24 > route default via 10.1.1.254 > exec echo 1 > /proc/sys/net/ipv4/ip_forward > > host host01 > dev veth0 10.0.0.1/24 > route default via 10.0.0.254 > > host host02 > dev veth0 10.0.0.2/24 > route default via 10.0.0.254 > > host host11 > dev veth0 gw/veth1 192.168.1.11/24 > route default via 192.168.1.254 > > host host12 > dev veth0 gw/veth2 192.168.2.12/24 > route default via 192.168.2.254 > > host host21 > dev veth0 10.23.23.21/24 > route default via 10.23.23.254 > > host host22 > dev veth0 10.23.23.22/24 > route default via 10.23.23.254 > > host host31 > dev veth0 10.23.23.31/24 > route default via 10.23.23.254 > > host host32 > dev veth0 10.23.23.32/24 > route default via 10.23.23.254 > > host host41 > dev veth0 10.45.45.41/24 > route default via 10.45.45.254 > > host host42 > dev veth0 10.45.45.42/24 > route default via 10.45.45.254 > > host host51 > dev veth0 10.45.45.51/24 > route default via 10.45.45.254 > > host host52 > dev veth0 10.45.45.52/24 > route default via 10.45.45.254 > > switch sw0 > dev d01 fw/veth0 > dev d02 host01/veth0 > dev d03 host02/veth0 > > switch sw2 > dev d01 fw/vbr0eth2 > dev d02 host21/veth0 > dev d03 host22/veth0 > > switch sw3 > dev d01 fw/vbr0eth3 > dev d02 host31/veth0 > dev d03 host32/veth0 > > switch sw4 > dev d01 fw/vbr1eth4 > dev d02 host41/veth0 > dev d03 host42/veth0 > > switch sw5 > dev d01 fw/vbr1eth5 > dev d02 host51/veth0 > dev d03 host52/veth0 > _______________________________________________ > Firehol-support mailing list > [email protected] > http://lists.firehol.org/mailman/listinfo/firehol-support _______________________________________________ Firehol-support mailing list [email protected] http://lists.firehol.org/mailman/listinfo/firehol-support