Networking - Revision history

Ben: /* Private Virtual Bridge */ manually created bridge must be (may need to be?) brought up to be useful

2018-12-04T03:11:14Z

Private Virtual Bridge: manually created bridge must be (may need to be?) brought up to be useful

← Older revision		Revision as of 23:11, 3 December 2018
Line 50:		Line 50:

	* You need to create a bridge, e-g:		* You need to create a bridge, e-g:
	# ip link add br0 type bridge		# ip link add br0 type bridge ; ifconfig br0 up
	# brctl addbr br0 (deprecated)		# brctl addbr br0 (deprecated)

Paq: fixed iface and master order in `ip link` command example

2016-10-20T13:24:31Z

fixed iface and master order in `ip link` command example

← Older revision		Revision as of 09:24, 20 October 2016
Line 65:		Line 65:
	sleep 0.5s		sleep 0.5s
	# brctl addif $switch $1 (use ip link instead!)		# brctl addif $switch $1 (use ip link instead!)
	ip link set $~~switch~~ master $1		ip link set $1 master $switch
	exit 0		exit 0
	else		else

Ckotichas: /* Public Bridge */

2016-07-25T00:40:21Z

Public Bridge

← Older revision		Revision as of 20:40, 24 July 2016
Line 89:		Line 89:
	== Public Bridge ==		== Public Bridge ==

	'''WARNING:''' The method shown here will not work with ~~most (if not~~ all) wireless drivers as ~~these do~~ not support bridging.		'''WARNING:''' The method shown here will not work with all wireless drivers as they might not support bridging.

	'''Use case:'''		'''Use case:'''

	* You want to assign an IP ~~address~~ to your virtual machines and make them accessible from your local network		* You want to assign IP addresses to your virtual machines and make them accessible from your local network
	* You also want performance out of your virtual machine		* You also want performance out of your virtual machine

Line 110:		Line 110:
	'''Solution 1: Using Distribution-Specific Scripts'''		'''Solution 1: Using Distribution-Specific Scripts'''
	{\|border="1"		{\|border="1"
	!RedHat~~'s way~~		!RedHat
	!Debian~~'s way~~		!Debian
	!SuSE~~'s way~~		!SuSE
	\|-		\|-
	\|		\|

Telnetuserid: /* Public Bridge */

2016-05-28T03:31:02Z

Public Bridge

← Older revision		Revision as of 23:31, 27 May 2016
Line 102:		Line 102:
	* The following commands must be installed on the host system and executed as root:		* The following commands must be installed on the host system and executed as root:
	ip		ip
	brctl		brctl (deprecated, use ip link instead)
	tunctl		tunctl (deprecated, use ip tuntap instead)

	* Your host system must be able to access the internet or the local network		* Your host system must be able to access the internet or the local network
Line 164:		Line 164:

	* You need to create a bridge, e-g:		* You need to create a bridge, e-g:
	# brctl addbr br0		# ip link add br0 type bridge
			# brctl addbr br0 (deprecated, use ip link instead!)

	* Add one of your physical interface to the bridge, e-g for eth0:		* Add one of your physical interface to the bridge, e-g for eth0:
	# brctl addif br0 eth0		# ip link set eth0 master br0
			# brctl addif br0 eth0 (deprecated, use ip link instead!)

	* You need a qemu-ifup script containing the following (run as root):		* You need a qemu-ifup script containing the following (run as root):
Line 177:		Line 179:

	if [ -n "$1" ];then		if [ -n "$1" ];then
	tunctl -u `whoami` -t $1		#tunctl -u `whoami` -t $1
			ip tuntap add $1 mode tap user `whoami`
	ip link set $1 up		ip link set $1 up
	sleep 0.5s		sleep 0.5s
	brctl addif $switch $1		#brctl addif $switch $1
			ip link set $1 master $switch
	exit 0		exit 0
	else		else

Telnetuserid: / * Modifying the script to use ip link and ip tuntap instead of brctl and tunctl */

2016-05-28T03:12:53Z

/ * Modifying the script to use ip link and ip tuntap instead of brctl and tunctl */

← Older revision		Revision as of 23:12, 27 May 2016
Line 44:		Line 44:
	* The following commands must be installed on the host system and executed as root:		* The following commands must be installed on the host system and executed as root:
	ip		ip
	brctl		brctl (deprecated). Use ip link instead
	tunctl		tunctl (deprecated). Use ip tuntap and ip link instead

	'''Solution:'''		'''Solution:'''

	* You need to create a bridge, e-g:		* You need to create a bridge, e-g:
	# brctl addbr br0		# ip link add br0 type bridge
			# brctl addbr br0 (deprecated)

	* You need a qemu-ifup script containing the following (run as root):		* You need a qemu-ifup script containing the following (run as root):
Line 59:		Line 60:

	if [ -n "$1" ];then		if [ -n "$1" ];then
	tunctl -u `whoami` -t $1		# tunctl -u `whoami` -t $1 (use ip tuntap instead!)
			ip tuntap add $1 mode tap user `whoami`
	ip link set $1 up		ip link set $1 up
	sleep 0.5s		sleep 0.5s
	brctl addif $switch $1		# brctl addif $switch $1 (use ip link instead!)
			ip link set $switch master $1
	exit 0		exit 0
	else		else

Ckotichas: /* User Networking */

2015-11-22T04:46:14Z

User Networking

← Older revision		Revision as of 00:46, 22 November 2015
Line 17:		Line 17:
	* You need kvm up and running		* You need kvm up and running
	* If you don't want to run as root, then the user needs to have rw access to /dev/kvm		* If you don't want to run as root, then the user needs to have rw access to /dev/kvm
	* ~~If you want~~ to be able to access the internet or a local network, ~~your~~ host system must be able to access ~~the internet or the local network~~		* In order for the guest to be able to access the internet or a local network, the host system must be able to access these resources as well

Ckotichas: /* User Networking */

2015-11-22T04:42:42Z

User Networking

← Older revision		Revision as of 00:42, 22 November 2015
Line 31:		Line 31:
	qemu-system-x86_64 -hda /path/to/hda.img -netdev user,id=user.0 -device e1000,netdev=user.0		qemu-system-x86_64 -hda /path/to/hda.img -netdev user,id=user.0 -device e1000,netdev=user.0
	* The user.0 identifier above is just to connect the two halves into one. You may use any identifier you wish, such as "n" or "net0".		* The user.0 identifier above is just to connect the two halves into one. You may use any identifier you wish, such as "n" or "net0".
	* Use rtl8139 instead of e1000 to get ~~8139~~-~~series NIC~~.		* Use rtl8139 instead of e1000 to get an rtl8139-based network interface.
	* You can still access one specific port on the guest using the "hostfwd" option. This means e.g. if you want to transport a file with scp from host to guest, start the guest with "-device e1000,netdev=user.0 -netdev user,id=user.0,hostfwd=tcp::5555-:22". Now you are forwarding the host port 5555 to the guest port 22. After starting up the guest, you can transport a file with e.g. "scp -P 5555 file.txt root@localhost:/tmp" from host to guest. Or you can also use the other address of the host to connect to.		* You can still access one specific port on the guest using the "hostfwd" option. This means e.g. if you want to transport a file with scp from host to guest, start the guest with "-device e1000,netdev=user.0 -netdev user,id=user.0,hostfwd=tcp::5555-:22". Now you are forwarding the host port 5555 to the guest port 22. After starting up the guest, you can transport a file with e.g. "scp -P 5555 file.txt root@localhost:/tmp" from host to guest. Or you can also use the other address of the host to connect to.

Ckotichas: /* VDE */

2015-11-22T04:37:31Z

VDE

← Older revision		Revision as of 00:37, 22 November 2015
Line 223:		Line 223:
	route add default gw <ip-of-host>		route add default gw <ip-of-host>

	== ~~vde~~ ==		== VDE ==

	Another option is using ~~vde~~ (~~virtual distributed ethernet~~).		Another option is using VDE (Virtual Distributed Ethernet).

			More information will be provided later.

	== Performance ==		== Performance ==

Ckotichas: /* Routing with iptables */

2015-11-22T04:33:26Z

Routing with iptables

← Older revision		Revision as of 00:33, 22 November 2015
Line 204:		Line 204:
	With this method, you can connect your guest vm to a tap device in your host. Then you can set iptables rules in your host so that it acts as a router and firewall for your guest.		With this method, you can connect your guest vm to a tap device in your host. Then you can set iptables rules in your host so that it acts as a router and firewall for your guest.

	Routing ~~would be~~ done simply by ~~creating~~ the default route on the client to the IP address of the host, allowing IP forwarding, and setting a route to the tap device of the client on the host.		Routing is done simply by setting the default route on the client to the IP address of the host, allowing IP forwarding, and setting a route to the tap device of the client on the host.

	~~Test the setup beforehand:~~

	*Host-side: Allow IPv4 forwarding and add a route to the guest (could be put in a script, but the route has to be added after the guest has started):		*Host-side: Allow IPv4 forwarding and add a route to the guest (could be put in a script, but the route has to be added after the guest has started):

	sysctl -w net.ipv4.ip_forward=1 # allow forwarding of IPv4		sysctl -w net.ipv4.ip_forward=1 # allow forwarding of IPv4
	route add -host <ip-of-client> dev <tap-device> # add route to the client		route add -host <ip-of-client> dev <tap-device> # add route to the client


	*Guest-side: Set the default gateway to the IP address of the host (make sure the host and guest IP addresses are in the same subnet):		*Guest-side: Set the default gateway to the IP address of the host (make sure the host and guest IP addresses are in the same subnet):

	route add default gw <ip-of-host>		route add default gw <ip-of-host>


	*Note: If the host is not on the same subnet as the guest, then you must manually add the route to the host before you create the default route:		*Note: If the host is not on the same subnet as the guest, then you must manually add the route to the host before you create the default route:

Ckotichas: /* Routing with iptables */

2015-11-22T04:30:08Z

Routing with iptables

← Older revision		Revision as of 00:30, 22 November 2015
Line 200:		Line 200:
	qemu-system-x86_64 -hda /path/to/hda.img -device e1000,netdev=net0,mac=$macaddress -netdev tap,id=net0,script=/path/to/qemu-ifup		qemu-system-x86_64 -hda /path/to/hda.img -device e1000,netdev=net0,mac=$macaddress -netdev tap,id=net0,script=/path/to/qemu-ifup

	== iptables~~/routing~~ ==		== Routing with iptables ==

	you can ~~also~~ connect your guest vm to a tap in your host. ~~then setting~~ iptables rules in your host ~~to become~~ a router + firewall for your vm.		With this method, you can connect your guest vm to a tap device in your host. Then you can set iptables rules in your host so that it acts as a router and firewall for your guest.

	Routing would be done simply by creating the default route on the client to the IP of the host ~~(and~~ allowing IP forwarding) and setting a route to the tap? device of the client on the host.		Routing would be done simply by creating the default route on the client to the IP address of the host, allowing IP forwarding, and setting a route to the tap device of the client on the host.

	Test the setup beforehand:		Test the setup beforehand:

	*~~Hostside~~: Allow IPv4 forwarding and add route to ~~client~~ (could be put in a script - route has to be added after the ~~client~~ has started):		*Host-side: Allow IPv4 forwarding and add a route to the guest (could be put in a script, but the route has to be added after the guest has started):

	sysctl -w net.ipv4.ip_forward=1 # allow forwarding of IPv4		sysctl -w net.ipv4.ip_forward=1 # allow forwarding of IPv4
	route add -host <ip-of-client> dev <tap-device> # add route to the client		route add -host <ip-of-client> dev <tap-device> # add route to the client

	*~~Clientside~~: ~~Default GW of~~ the ~~client is~~ of ~~course then~~ the host (~~<ip-of-~~host~~> has to be~~ in same subnet ~~as <ip-of-client> ...~~):		*Guest-side: Set the default gateway to the IP address of the host (make sure the host and guest IP addresses are in the same subnet):

	route add default gw <ip-of-host>		route add default gw <ip-of-host>

	*~~Clientside v2~~: If ~~you~~ host IP is not on the same subnet as ~~<ip-of-client>~~, then you must manually add the route to host before you create default route:		*Note: If the host is not on the same subnet as the guest, then you must manually add the route to the host before you create the default route:

	route add -host <ip-of-host> dev <network-interface>		route add -host <ip-of-host> dev <network-interface>
	route add default gw <ip-of-host>		route add default gw <ip-of-host>


	== vde ==		== vde ==