Configure 2 NIC on the same subnet - networking

For debugging purpose I need to set up a MITM proxy between 2 devices.
All devices have static IP (example) and are directly connected each other:
Device 1 : 192.168.10.50
Device 2 : 192.168.10.60
Proxy computer have 2 nic on the same subnet and is between other devices :
D1 .50 <=> [.60 PROXY .50] <=> D2 .60
My problem is, from the proxy if one of the 2 nic is disabled, D1 or D2 can reach the proxy.
Once I bring up the 2 nic, no one can see any other device.
D1 and D2 ip can't be changed.
Proxy is linux centos 8.
Already tested :
adding log on iptables : if 2 nic are up no more input / output log
Drop all input / output then accept only right ip from right interface => no result
Changing arp_filter = 1 and arp_announce = 2 => no result
Testing multiple SO post about 2 nic on same subnet
If anyone can help.
Thanks .

I've found a solution which consist in creating a transparent proxy and intercept some packets.
1- Create a bridge with the 2 NIC :
nmcli connection add type bridge autoconnect yes con-name "br0" ifname "br0"
nmcli connection modify "br0" ipv4.addresses "192.168.10.10/24" ipv4.method manual
nmcli connection delete enp0s3
nmcli connection delete enp0s8
nmcli connection add type bridge-slave autoconnect yes con-name enp0s3 ifname enp0s3 master br0
nmcli connection add type bridge-slave autoconnect yes con-name enp0s8 ifname enp0s8 master br0
2 Add correct rules to intercept specific traffic
nft add table bridge mitm
nft add chain bridge mitm filter { type filter hook prerouting priority 0\; }
nft add rule bridge mitm filter tcp dport 10000 ip saddr 192.168.10.50 meta pkttype set host ether daddr set xx:xx:xx:xx:xx:xx # br0 mac address
nft add rule ip nat PREROUTING tcp dport 10000 ip saddr 192.168.10.50 dnat to 192.168.10.10
It worked for me.

Related

What is the relation between docker0 and eth0?

I know by default docker creates a virtual bridge docker0, and all container network are linked to docker0.
As illustrated above:
container eth0 is paired with vethXXX
vethXXX is linked to docker0 same as a machine linked to switch
But what is the relation between docker0 and host eth0?
More specifically:
When a packet flows from container to docker0, how does it know it will be forwarded to eth0, and then to the outside world?
When an external packet arrives to eth0, why it is forwarded to docker0 then container? instead of processing it or drop it?
Question 2 can be a little confusing, I will keep it there and explained a little more:
It is a return packet that initialed by container(in question 1): since the outside does not know container network, the packet is sent to host eth0. How it is forwarded to container? I mean, there must be some place to store the information, how can I check it?
Thanks in advance!
After reading the answer and official network articles, I find the following diagram more accurate that docker0 and eth0 has no direct link,instead they can forward packets:
http://dockerone.com/uploads/article/20150527/e84946a8e9df0ac6d109c35786ac4833.png
There is no direct link between the default docker0 bridge and the hosts ethernet devices. If you use the --net=host option for a container then the hosts network stack will be available in the container.
When a packet flows from container to docker0, how does it know it will be forwarded to eth0, and then to the outside world?
The docker0 bridge has the .1 address of the Docker network assigned to it, this is usually something around a 172.17 or 172.18.
$ ip address show dev docker0
8: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:03:47:33:c1 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 scope global docker0
valid_lft forever preferred_lft forever
Containers are assigned a veth interface which is attached to the docker0 bridge.
$ bridge link
10: vethcece7e5 state UP #(null): <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master docker0 state forwarding priority 32 cost 2
Containers created on the default Docker network receive the .1 address as their default route.
$ docker run busybox ip route show
default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 src 172.17.0.3
Docker uses NAT MASQUERADE for outbound traffic from there and it will follow the standard outbound routing on the host, which may or may not involve eth0.
$ iptables -t nat -vnL POSTROUTING
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- * !docker0 172.17.0.0/16 0.0.0.0/0
iptables handles the connection tracking and return traffic.
When an external packet arrives to eth0, why it is forwarded to docker0 then container? instead of processing it or drop it?
If you are asking about the return path for outbound traffic from the container, see iptables above as the MASQUERADE will map the connection back through.
If you mean new inbound traffic, Packets are not forwarded into a container by default. The standard way to achieve this is to setup a port mapping. Docker launches a daemon that listens on the host on port X and forwards to the container on port Y.
I'm not sure why NAT wasn't used for inbound traffic as well. I've run into some issues trying to map large numbers of ports into containers which led to mapping real world interfaces completely into containers.
You can detect the relation by network interface iflink from a container and ifindex on the host machine.
Get iflink from a container:
$ docker exec ID cat /sys/class/net/eth0/iflink
17253
Then find this ifindex among interfaces on the host machine:
$ grep -l 17253 /sys/class/net/veth*/ifindex
/sys/class/net/veth02455a1/ifindex

Configure LXC to use wireless hosted network

I found most of the configuration is for giving static or private network. But I want it to act as a different machine so it will get a separate IP address from the DHCP and I want to do it through nmcli.
Thanks in advance.
If you are using docker as tagged, rather than LXC, use pipework to map the wlan interface from the host to the container
pipework eth2 $CONTAINERID 10.10.9.9/24
or alternatively let the container do the dhcp negotiation for you
pipework eth1 $CONTAINERID dhclient
This setup is based on a macvlan interface so the same concept should work with LXC you just won't get the easy front end.
I'm confused if this is a docker question or an LXC question.
EDIT: as per the comments, wlan interface support in a bridge depends on the wlan vendor. It may work, or it may not work at all.
In any case, you should be able to create a bridge, add your wlan0 interface to the bridge, and then have your LXC container connect to this bridge directly. Then, when you run your DHCP client in the container, it will grab it from the wlan0 interface.
Configure bridge (manually for now)
# ifconfig wlan0 up
# brctl addbr br0
# brctl addif br0 wlan0
# ifconfig br0 up
# dhclient br0
Configure LXC configuration
If using traditional priviliged LXC, edit the container's config file at /var/lib/lxc/$NAME/config,
and update this value to point to your new bridge.
lxc.network.link = br0
Run DHCP in container
# lxc-attach -n $NAME
# dhclient eth0
# ip a
If the output to ip a shows the desired IP, you're all set!
If you want to make the configuration persistent, you'll have to add the bridge to your /etc/network/interfaces file.
IEEE 802.11 doesn’t like multiple MAC addresses on a single client, so bridge and macvlans are not the right solution here.
Use ipvlan in L2 mode.

openstack instance getting ip and not getting ip

I am new to openstack and I followed the installation guide of icehouse for ubuntu 12.04/14.04
I chose 3 node architecture. Controller, Nova, Neutron.
The 3 nodes are installed in VM's. I used nested KVM. Inside VM's kvm is supported so nova will use virt_type=kvm. In controller I created 2 nics. eth0 is a NAT interface with ip 203.0.113.94 and eth1 a host only interface with ip 10.0.0.11.
In nova there are 3 nics. eth0 NAT - 203.0.113.23, eth1 host only 10.0.0.31 and eth2 another host only 10.0.1.31
In neutron 3 nics. eth0 NAT 203.0.113.234, eth1 host only 10.0.0.21 and eth2 another hosty only 10.0.1.21 (during installation guide in neutron node i created a br-ex (and a port to eth0) which took the settings of eth0 and eth0 settings are:
auto eth0 iface eth0 inet manual up ifconfig $IFACE 0.0.0.0 up
up ip link set $IFACE promisc on
down ip link set $IFACE promisc off
down ifconfig $IFACE down)
Everything seemed fine. I can create networks, routers etc, boot instances but I have this error.
When I launch an instance it takes a fixed ip but when I log in into instance (cirros) can't ping anything. ifconfig with no ip.
I noticed that in demo-net (tenant network) properties under subnet in the ports field it has 3 ports. 172.16.1.1 network:router_interface active 172.16.1.3 network:dhcp active 172.16.1.6 compute:nova down
I searched for solutions over the net but couldn't find anything!
Any help?
Ask me if you want specific logs because I don't know which ones to post!
Thanks anyway!
Looks like you are using Fixed IP to ping..If so please assign floating IP to your instance, and then try to ping..
If you have already assigned floating IP and you are pinging using that IP..please upload log of your instance

How to forward packet from eth0 to a tun/tap device?

Here is the topo: HostA(eth0) ---- (eth0)HostB
I have created a tun/tap device on HostB, for say tun0 or tap0. When eth0 of HostB receives a packet from HostA, maybe a ICMPv6(NS, echo request, etc.) or a UDP/TCP packet(encapsulated with IPv6 header), I want to forward this packet from eth0 to tap0. After doing something to this packet, I also want to send a reply back to HostA, through tap0 and eth0.
I cannot find a way to do that, can some one help me or give some hints?
This is an extremely basic routing question, probably unsuitable for Stack Overflow.
You need something like this on Host B:
HostB# sysctl -w net.ipv6.conf.all.forwarding=1
HostB# ip -6 addr add 2001:db8:0:0::1/64 dev eth0
HostB# ip -6 addr add 2001:db8:0:1::1/64 dev tun0
Then on Host A:
HostA# ip -6 addr add 2001:db8:0:0::2/64 dev eth0
HostA# ip -6 route add default via 2001:db8:0:0::1 dev eth0
HostA# ping6 2001:db8:0:1::2 # <-- should work if that host exists on tun0

How to send data to cloud instance in opestack

Context: I have setup a demo cloud in my laptop using VirtualBox and have two virtual machines - one has the client and other as server. Create a small instance using the server and running instance is TinyLinux.
Problem: How shall I send data to that instances and stores in that instance.
Some pointers would be very helpful.
Well, with libvirt, you have several options how to do the networking. The default is to use NATing. In that case libvirt creates a bridge and virtual nics for every so configured virtual nic:
$ brctl show
bridge name bridge id STP enabled interfaces
virbr0 8000.525400512fc8 yes virbr0-nic
vnet0
Then sets-up iptables rules to NAT (masquerade) the packets on such bridge.
Chain POSTROUTING (policy ACCEPT 19309 packets, 1272K bytes)
pkts bytes target prot opt in out source destination
8 416 MASQUERADE tcp -- any any 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535
216 22030 MASQUERADE udp -- any any 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535
11 460 MASQUERADE all -- any any 192.168.122.0/24 !192.168.122.0/24
enables forwarding
# cat /proc/sys/net/ipv4/ip_forward
1
and spawns DHCP server (dnsmasq is both DHCP and DNS in one)
ps aux | grep dnsmasq
nobody 1334 0.0 0.0 13144 568 ? S Feb06 0:00 \
/sbin/dnsmasq --strict-order --local=// --domain-needed \
--pid-file=... --conf-file= --except-interface lo --bind-dynamic \
--interface virbr0 --dhcp-range 192.168.122.2,192.168.122.254 \
--dhcp-leasefile=.../default.leases --dhcp-lease-max=253 --dhcp-no-override
If I had two virtual network interfaces (two machines with one NIC on same network, there would be two nics in that bridge. The machines gets the address from the range 192.168.122.2-254 from the dnsmasq DHCP server. So if you know that addresses, you should be able to connect from one to the other VM as both are on same broadcast domain (connected by the bridge). To the outside of your computer the machines all appear as "one IP address".
The more "advanced" option is to use Bridged networking, which again puts the virtual interfaces into one bridge, but it puts some physical device there as well, so the machines appears as if there were several machines connected to some switch...
I usually bind a web server to the gateway interface the VMs use to NAT with the physical host.

Resources