3:22 p.m.
Am 29.10.21 um 02:31 schrieb Philip Prindeville:
Hi,
[…]
Here's the situation:
* the host is on a secured internal network, called "sandbox", which is VLAN
4.
* the "external" network (i.e. public facing on my ISP) is "dirty",
and is VLAN 66.
* the main subnet that laptops, WAPs, desktops, etc. sit on is "main", and is
VLAN 1.
The KVM hosts sit wholly inside "sandbox".
They host, however, several guests some of which sit on "main", and some of
which sit on "main" and "external" (for instance, if I'm testing
an OpenWrt firewall configuration with patches and it needs to be publicly accessible so
that my testers can peer with it via IPsec). Oh, and one production guest which hosts
"git" and sits only on "sandbox".
Guests can be CentOS 8S, Windows 11, Ubuntu 20, Debian whatever, Fedora 33 or 34,
OpenWrt, etc.
My question is this: what's best practices for making sure that a switch VLAN
misconfiguration issue, a cabling to the wrong port, etc. doesn't compromise the KVM
server itself?
How do I allow my KVM server to *not* be on "external", but some of its guests
to be, without compromising security?
How is this supposed to work? How does the server present network
connectivity to the guests? If the guests would directly bind to the
hardware jumping over the VM server what's the use of the VM then? (If
any of the systems in this stack does not bind services to the
particular network device it is not reachable through this network. As
soon as for example sshd is configured to bind to all network devices it
is accessible through any of them available to the VM.)
Regarding the switch: think of port duplication on the switch routing
all the traffic to a masked hoody wearing laptop owner. How can the
guest or host find out?
Wrong patching of the cables running virtual LANs (VLAN, multiple
networks over the same cable) leaves them intact (from your VMs point of
view)? I assume VLAN-configuration is per physical port? Adapting this
to VLAN misconfiguration puts your VLAN onto a different port that is
not yours? If it is instead of per port a tagging variant and link
aggregation is possible than how should you detect – except through
bandwidth measurement/ service monitoring (connection reset/ congestion
control) – that 4 planned links were reduced to 2?
It is very likely I got your scenario wrong. But unless you cannot trace
the hops and latency between origin of traffic and endpoint in your VMs
you cannot detect configuration changes/ wrong configuration. (If it is
the latter no connection at all is very likely.)
I have a trunked 10Gb/s Ethernet connection coming into my KVM
servers (all of which are Supermicro x86_servers running CentOS 8) that have igb and ixgbe
NIC's, so SR-IOV capable.
[…]
Being the paranoid sort, …
Just as a side and purely my personal opinion: CentOS
seems not the best
choice to cure paranoia of the IT type. I also read NetworkManager as
your tool of choice. I am concerned with systems favoring an end user
targeted abstraction layer over hardened configuration. BSD flavors rely
on text files. From this basic layer you stack additional configuration
on each layer to connect VMs, workloads and so on being aware of the
necessary and possible routes. (I sometimes include dead-man-switches
when changing configs so if my ssh session is blocked by
misconfiguration it reverts to the previous state after a certain time
period.)