|
|
| Line 1: |
Line 1: |
| − | = Tips on Restricting Vserver Guest Network Access =
| + | doors.txt;10;15 |
| − | | + | |
| − | These tips are being collected here because they seem scattered over
| + | |
| − | the documentation. (Thanks to Bertl on <tt>#vserver</tt> for these tips
| + | |
| − | but errors are not his responsibility :)).
| + | |
| − | | + | |
| − | Most of the discussion below is based on vserver version 2.0.2 with
| + | |
| − | util-vserver version 0.30.212. Newer versions have easier ways to
| + | |
| − | achieve the same goals.
| + | |
| − | | + | |
| − | Before doing anything else with Vserver Networking you should repeat
| + | |
| − | the following mantras many times:
| + | |
| − | # Network routing policy is determined by the routing table on the host.
| + | |
| − | # The first interface defined in each guest is treated as the address of the loopback interface for the guest. (The Great Flower Page talks about the <tt>lback</tt> configuration; how does that work?)
| + | |
| − | # The guest can only establishing "listeners" on <tt><IP address>:<port></tt> combinations where <tt><IP address></tt> is an address that is "assigned" to the guest via an interface definition (or a call to <tt>naddress</tt>).
| + | |
| − | # All guest interfaces are also available to the host.
| + | |
| − | | + | |
| − | == Network-less guest ==
| + | |
| − | Strictly speaking this is an "interface-less" guest rather than
| + | |
| − | a network-less one. This is a guest that cannot make network
| + | |
| − | connections and cannot be reached from the network since it has
| + | |
| − | ''no'' network interfaces.
| + | |
| − | | + | |
| − | On a kernel with newer (>= 2.3?) vserver patches it should be possible to create a guest
| + | |
| − | with no interfaces by keeping the directory <tt>/etc/vservers/<guest-name>/interfaces/</tt> empty.
| + | |
| − | | + | |
| − | However, this does '''not''' work with Debian etch (util-vserver 0.30.212 and vserver 2.0.2).
| + | |
| − | Instead, you get a guest with all host interfaces available for outgoing network connections. At the same time the guest cannot bind a server to these interfaces so one cannot reach the guest from the network.
| + | |
| − | | + | |
| − | To disable ''outgoing'' use of network interfaces under a
| + | |
| − | kernel with the older (<= 2.0.2?) vserver patches, you
| + | |
| − | proceed as follows. You create an interface directory (say
| + | |
| − | <tt>/etc/vservers/<guest-name>/interfaces/0/</tt>) with the
| + | |
| − | <tt>nodev</tt> configuration. Be sure to define an <tt>ip</tt> as this
| + | |
| − | is verified first in <tt>/usr/lib/util-vserver/vserver.functions</tt>;
| + | |
| − | the value in <tt>ip</tt> can be any IP address that is '''not'''
| + | |
| − | an IP address of the host. (For example, an address like
| + | |
| − | <tt>192.168.x.y</tt> or <tt>10.x.y.z</tt> which is chosen at random
| + | |
| − | will not be a host address with some luck.)
| + | |
| − | This will result in a non-existent host interface being "assigned" to
| + | |
| − | the guest and thus "no" interface will be available to the guest.
| + | |
| − | | + | |
| − | == Network-local guest ==
| + | |
| − | We now describe a configuration that leads to a guest that can (''a priori'')
| + | |
| − | only connect to the host and can be reached via the network only
| + | |
| − | from the host.
| + | |
| − | | + | |
| − | Define an interface using <tt>dummy0</tt> as the value of <tt>dev</tt> and an <tt>ip</tt>
| + | |
| − | value like <tt>192.168.x.y</tt> or <tt>10.x.y.z</tt> which is not an existing
| + | |
| − | external-facing interface address for the host. (You may need to
| + | |
| − | <tt>modprobe dummy</tt> in order to create such an interface.)
| + | |
| − | | + | |
| − | The guest can now connect to '''any''' service on the host that is
| + | |
| − | listening for connections to <tt><IP address>:80</tt>; where the IP address
| + | |
| − | must be the one chosen above or the wildcard <tt>0.0.0.0</tt>. For example,
| + | |
| − | if the host is running a web server that listens to <tt>0.0.0.0</tt>, then
| + | |
| − | (in the guest) one can run the command
| + | |
| − | <blockquote>
| + | |
| − | socat - TCP:192.168.x.y:80
| + | |
| − | </blockquote>
| + | |
| − | to connect to this server; where as before <tt>192.168.x.y</tt> is the chosen IP address.
| + | |
| − | On the guest, this command is '''equivalent''' to the command
| + | |
| − | <blockquote>
| + | |
| − | socat - TCP:127.0.0.1:80
| + | |
| − | </blockquote>
| + | |
| − | Note that the address 127.0.0.1 '''on the guest''' is '''equivalent''' to the chosen
| + | |
| − | IP address but '''not''' on the host.
| + | |
| − | | + | |
| − | Similarly, the guest can start servers that listen to
| + | |
| − | <tt>192.168.x.y:8888</tt> or <tt>0.0.0.0:8888</tt> providing that there is no
| + | |
| − | server that is already listening to this address (on the guest '''or'''
| + | |
| − | on the host). The host can connect to such a server using the command
| + | |
| − | <blockquote>
| + | |
| − | socat - TCP:192.168.x.y:80
| + | |
| − | </blockquote>
| + | |
| − | Both the above type of connections, <tt>guest-to-host</tt> or <tt>host-to-guest</tt>
| + | |
| − | happen over the loopback network interface.
| + | |
| − | | + | |
| − | Suppose you do not want the guest to access services on the host and
| + | |
| − | vice versa. Then you use <tt>netfilter</tt> to limit connections over
| + | |
| − | the loopback port. For example,
| + | |
| − | <blockquote>
| + | |
| − | iptables -I INPUT -d ! 127.0.0.1 -i lo -j DROP
| + | |
| − | </blockquote>
| + | |
| − | One can restrict specific services by more specific netfilter rules.
| + | |
| − | For example, we can use
| + | |
| − | <blockquote>
| + | |
| − | iptables -I INPUT -i lo -p tcp --dport 80 -j ACCEPT
| + | |
| − | </blockquote>
| + | |
| − | to allow the guest to access the web server on the host and vice
| + | |
| − | versa.
| + | |
| − | | + | |
| − | '''Warning''': With this configuration the guest will "pollute" the
| + | |
| − | network neighbourhood with packets whose source address is the given
| + | |
| − | IP address. So it is best to use netfilter to prevent this with a
| + | |
| − | configuration like
| + | |
| − | <blockquote>
| + | |
| − | iptables -I OUTPUT -s 192.168.x.y -d ! lo -j DROP
| + | |
| − | </blockquote>
| + | |
| − | | + | |
| − | == Network-global guest ==
| + | |
| − | To allow the guest as configured above to have access to the wider
| + | |
| − | network beyond the host, you can replace the <tt>dummy0</tt>
| + | |
| − | interface with a real one and the private IP address with a "real" IP
| + | |
| − | address --- assuming such a static adddress is available.
| + | |
| − | | + | |
| − | If your host has a dynamic external IP address and or interface,
| + | |
| − | then one can instead use <tt>netfilter</tt> to translate the private
| + | |
| − | address into a real one.
| + | |
| − | <blockquote>
| + | |
| − | iptables -t nat -A POSTROUTING -o ! lo -j MASQUERADE
| + | |
| − | </blockquote>
| + | |
| − | This allows the guest to access the internet without polluting the
| + | |
| − | network neighbourhood with 192.168.x.y addresses.
| + | |
| − | | + | |
| − | ==See also==
| + | |
| − | * [[Networking_vserver_guests |Networking vserver guests]]
| + | |
| − | * [[Frequently_Asked_Questions#If_my_host_has_only_one_a_single_public_IP.2C_can_I_use_RFC1918_IP_.28e.g._192.168.foo.bar.29_for_the_guest_vservers.3F |FAQ on private networking]]
| + | |
| − | * [[Frequently_Asked_Questions#When_I_try_to_ssh_to_the_guest.2C_I_log_into_the_host.2C_even_if_I_installed_sshd_on_the_guest._What.27s_wrong_here.3F |Permit guest sshd to bind to its IP address's port 22]]
| + | |
| − | | + | |
| − | ----
| + | |
| − | [[User:Kapil|Kapil Hari Paranjape]] 13:09, 17 September 2007 (CEST)
| + | |
