Skip to main content

Setting up the HOOK mechanism in libvirt for KVM/QEMU to manage customized networking requirements

This post is a belated follow-up to a post I did 3 years ago about configuring Linux KVM networking to use IP forwarding when IP spoofing is disallowed by your dedicated Linux server provider.  Such as 1and1 in my case.

For further context and reference please refer to the original post here:
http://roddines.blogspot.com/2014/09/how-to-configure-dedicated-server.html

Refer to: https://www.libvirt.org/hooks.html

A small bash script file that can be used to test the more complex hook script below

#!/bin/bash
# Location/File: ~/fixnet
#Quick Fix IP Tables
echo 'default' is usually 'virbr0' and this is assumed!
sudo /etc/libvirt/hooks/network default started end


Content of the bash script file located at /etc/libvirt/hooks/network

#!/bin/bash
# Location/File: /etc/libvirt/hooks/network
# Sep2014 Created by Rod Dines rod<at>roddines.com
# Feb2016 edited by Rod Dines to refine scripting
# July2017 edited by Rod Dines to setup for new server IPs

# Note: This file must be set with execute permissions
# For a hook script to be utilised, it must have its execute bit set e.g. chmod
# Refer to: https://www.libvirt.org/hooks.html
# Passed arguments are:
# $1 = <network_name> e.g. default
# $2 = <action> i.e. start, started, stopped
# $3 = <action-stage> i.e.  begin, end
# $4 = <terminator> -

VIRT_NET_MATCH="default"
VIRT_BRIDGE_MATCH="virbr0"
IP_ADDR_WIN_SRV="192.168.122.4"

# SET HERE A LIST OF ALL IP ADDRESSES REQUIRING IP FORWARDING TO VIRT MACHINES
IP_ADDR_LIST="\
 111.111.111.112/32 \
 111.111.112.113/32 \
"

echo "IP_ADDR_LIST=$IP_ADDR_LIST"

if [ "$1" == "$VIRT_NET_MATCH" ]; then
  VIRT_BRIDGE=$VIRT_BRIDGE_MATCH
  # Configure path through script based on <action>
  RT_ACT=""
  if [ "$2" == "started" ]; then
    RT_ACT="add"
    echo "General NAT PREROUTING entries"
    iptables -I PREROUTING -t nat -p tcp -d 111.111.110.110 --dport 80 -j DNAT --to-destination 192.168.122.2:80
    iptables -I PREROUTING -t nat -p tcp -d 111.111.110.110 --dport 22 -j DNAT --to-destination 192.168.122.2:22
    iptables -I PREROUTING -t nat -p tcp -d 111.111.110.111 --dport 80 -j DNAT --to-destination 192.168.122.3:80

    iptables -I PREROUTING -t nat -p tcp -d 111.111.110.111 --dport 22 -j DNAT --to-destination 192.168.122.3:22

    echo "NAT Forwarding RDP on 33333 to Windows Server on 3389"
    iptables -D PREROUTING -t nat -i eth0 -p tcp --dport 33333 -j DNAT --to IP_ADDR_WIN_SRV:3389
    iptables -I PREROUTING -t nat -i eth0 -p tcp --dport 33333 -j DNAT --to IP_ADDR_WIN_SRV:3389
    iptables -D FORWARD -p tcp -d $IP_ADDR_WIN_SRV --dport 3389 -j ACCEPT
    iptables -I FORWARD -p tcp -d $IP_ADDR_WIN_SRV --dport 3389 -j ACCEPT
    echo "Starting $1 ($VIRT_BRIDGE) ..."
  elif [ "$2" == "stopped" ]; then
    RT_ACT="del"
    echo "Stopping $1 ($VIRT_BRIDGE) ..."
  fi


  echo "Fixing IP Tables filtering and IP Routes to allow IPv4 forwarding"
  if [ "$RT_ACT" != "" ] ; then
    #Process the list of IP addresses to forward into the virtual bridge
    for IP_ADDR in $IP_ADDR_LIST
    do
      # FIX IP TABLES FORWARDING
      echo "IP_ADDR=$IP_ADDR"
      # ALWAYS DELETE/ATTEMPT TO REMOVE EXISTING IP TABLES FORWARD
      iptables -C FORWARD -t filter -s $IP_ADDR -i $VIRT_BRIDGE -j ACCEPT &>/dev/null
      if [ $? -eq 0 ]; then
        echo "Deleting IP Tables source $IP_ADDR"
        iptables -D FORWARD -t filter -s $IP_ADDR -i $VIRT_BRIDGE -j ACCEPT
      fi
      iptables -C FORWARD -t filter -d $IP_ADDR -o $VIRT_BRIDGE -j ACCEPT &>/dev/null
      if [ $? -eq 0 ]; then
        echo "Deleting IP Tables destination $IP_ADDR"
        iptables -D FORWARD -t filter -d $IP_ADDR -o $VIRT_BRIDGE -j ACCEPT
      fi
      # IF VIRT BRDIGE HAS STARTED THEN ADD ENTRIES TO TOP OF IP TABLES RULES
      if [ "$RT_ACT" == "add" ]; then
        echo "Adding IP Tables for $IP_ADDR"
        iptables -I FORWARD 1 -t filter -s $IP_ADDR -i $VIRT_BRIDGE -j ACCEPT
        iptables -I FORWARD 1 -t filter -d $IP_ADDR -o $VIRT_BRIDGE -j ACCEPT
      fi
      # FIX IP ROUTES
      echo "$RT_ACT IP route for $IP_ADDR"
      # Add or Remove (set by $RT_ACT='add' or 'del') static route forwarding
      EXIST=`ip route show $IP_ADDR | wc -l`
      if [ $EXIST -eq 0 ] && [ "$RT_ACT" == "add" ]; then
          #Route does not already exist in routing table and needs adding
          echo "Adding IP route for $IP_ADDR"
          route add $IP_ADDR dev $VIRT_BRIDGE
      elif [ $EXIST -eq 1 ] && [ "$RT_ACT" == "add" ]; then
          #Route already exists in routing table and needs removing and adding
          echo "Clearing IP route for $IP_ADDR"
          route del $IP_ADDR
          echo "Adding IP route for $IP_ADDR"
          route add $IP_ADDR dev $VIRT_BRIDGE
      elif [ $EXIST -eq 1 ] && [ "$RT_ACT" == "del" ]; then
          #Route already exists in routeing table and needs removing
          echo "Deleting IP route for $IP_ADDR"
          route del $IP_ADDR
      fi
    done

    #List Changes
    iptables -L

    #List Routes
    route -n

  fi  #[ "$RT_ACT" != "" ] ; then

fi #if [ "$1" == "$VIRT_NET_MATCH" ]; then
#EOF












Comments

Popular posts from this blog

Thin Mini-ITX Motherboard Overview [Updated AUG 2024]

THIN MINI-ITX Primarily, the Thin Mini-ITX form factor and its motherboards are targeted at the business-oriented All-in-One (AIO) market but are also used in 1U rack servers, e.g. NAS, embedded systems, digital signage, and sometimes in mains-powered IoT applications.  They typically have LVD/eDP/LCD panel drivers built-in also and have slightly higher pricing because of this and other embedded features such as a single DC power supply input (which facilitates a smaller case). BACKGROUND The Intel Q series motherboard chipsets support the Intel vPro/AMT remote management with KVM over IP (or iKVM) functionality built into the CPU/chipset combination.  This is very convenient for administrators.  For example, with the correct configuration, you can watch a full reboot, manage the BIOS, and install a new OS remotely. http://www.wikiwand.com/en/Intel_Active_Management_Technology CASE Typically Thin Mini-ITX cases are smaller based on the thinness of the motherboard, i...

Removing the WLAN / WiFi pcie card whitelist on Lenovo IdeaPad u410 Touch with BIOS update

WARNING! PLEASE READ THE ENTIRE POST BEFORE USING / DOING ANYTHING! BACKGROUND I recently (early 2016) acquired a 2013 Lenovo IdeaPad u410 Touch. It was not my first choice but still useful but I wanted to upgrade it to more recent tech and make it more usable as it is not the fastest CPU around, i.e. an i5-3337U dual core (quad thread) at 1.8GHz. http://ark.intel.com/products/72055/Intel-Core-i5-3337U-Processor-3M-Cache-up-to-2_70-GHz First thing I did was upgrade the BIOS to latest (as anyone would/should do really) version 65CN99WW (8/28/2014) available here: http://support.lenovo.com/au/en/products/laptops-and-netbooks/ideapad-u-series-laptops/ideapad-u410?beta=false I then added 2 x Kingston SO-DIMM KVR16LS11/8 1.35V (Low Voltage) 8G DDR3 1600 Notebook Ram SODIMM's despite the specs I could find all saying it would only take 8GB and it works fine with the 16GB as the Intel i5-3337U CPU (says 32GB) & Mobile Intel HM77 Express Chipset specifications suggest.  ...