Network Diagrams¶
Because we deploy virtual machines on-top of our physical infrastructure, we have multiple choices for networking strategies. These disagrams aim to highlight the differences.
Bridged Networking¶
Bridged networking uses Tap/Tun networking on the host machine to create virtual network-devices which can be attached directly to a VM. This virtual interface is presented to the network as a new physical network-interface and follows a normal DHCP process. It recieves an IP address from the same DHCP server as the host and is addressable by any devices on the host's local network. Bridged networks are generally more performant than SLIRP networks due to lower emulation-overhead.
Slirp Networking¶
SLIRP networking emulates an entire DHCP + TCP/IP network stack. It creates its own DHCP and DNS server within a private virtual network and is un-reachable from the outside world (including the host) without explicit creation of a forwarded port. SLIRP networks run in user-sapce and thus do not require root access to create. Because of the increased amount of emulation, there is a higher resource cost associated with a SLIRP network versus a bridged network.
Security considerations¶
Despite being largely obsolete, Slirp made a great influence on the networking stacks used in virtual machines and other virtualized environments. The established practice of connecting the virtual machines to the host's network stack was to use the various packet injection mechanisms. Raw sockets, being one of such mechanisms, were originally used for that purpose, and, due to many problems and limitations, were later replaced with the TAP device.
Packet injection is a privileged operation that may introduce a security threat, something that the introduction of TAP device solved only partially. Slirp-derived NAT implementation brought a solution to this long-standing problem. It was discovered that Slirp has the full NAPT implementation as a stand-alone user-space code, whereas other NAT engines are usually embedded into a network protocol stack and/or do not cooperate with the host OS when doing PAT (use their own port ranges and require packet injection). QEMU project have adopted the appropriate code portions of the Slirp package and got the permission from its original authors to re-license it under 3-clause BSD license.[11] Such license change allowed many other FOSS projects to adopt the QEMU-provided Slirp portions, which was (and still is) not possible with the original Slirp codebase because of the license compatibility problems. Some of the notable adopters are VDE and VirtualBox projects. Even though the Slirp-derived code was heavily criticized,[12] to date there is no competing implementation available.
- https://en.wikipedia.org/wiki/Slirp