Networking and 1U Colocation

EddieJennings

My final networking challenge is making sure my host is configured to be able to talk to the outside world. This is the current version of the topology.

The question becomes how to configure a default route on the host that sends traffic to virbr1.

I notice in /etc/sysconfig/network-scripts/ there are no scripts for the virtual interfaces. I could use ip route add default via 192.168.1.1; however, that will not survive a reboot.

When I run nmcli I see the bridge (virbr1) with the IP it was assigned via virsh net-edit, since when creating the the network in Virt-Manager it assigned an address of 192.168.1.1, and I wanted the LAN interface on the VyOS firewall to have 192.168.1.1.

Methinks the solution is likely with using nmcli.

JaredBusch

Honestly, if it were me, I would just add a NIC on the LAN to your host and let it reside on your LAN like everything else.

I know other things were mentioned and recommended out of paranoid security concerns, but realistically, that is mitigating such a small risk, that I generally find it not to be worth the effort.

The thought exercise has to be gone through to determine that though.

EddieJennings

@jaredbusch said in Networking and 1U Colocation:

Honestly, if it were me, I would just add a NIC on the LAN to your host and let it reside on your LAN like everything else.

I know other things were mentioned and recommended out of paranoid security concerns, but realistically, that is mitigating such a small risk, that I generally find it not to be worth the effort.

The thought exercise has to be gone through to determine that though.

There is a gap of understanding. The LAN interface of the VyOS VM is connected to virbr1. For the host, do you mean create an interface and [attach] it to virbr1? Or do you mean assigning an IP address to virbr1?

This is how the virtual networks appear on the host (from nmcli).

virbr0: connected to virbr0
	"virbr0"
	bridge, 52:54:00:55:91:EB, sw, mtu 1500
	inet4 192.168.122.1/24

virbr1: connected to virbr1
	"virbr1"
	bridge, 52:54:00:BF:E7:FB, sw, mtu 1500

stacksofplates

If you're not having other people connect to it and it's just for testing, I'd just leave the connection go to the host (SSH and Cockpit) and then join all of your VMs to ZeroTier.

EddieJennings

@stacksofplates said in Networking and 1U Colocation:

If you're not having other people connect to it and it's just for testing, I'd just leave the connection go to the host (SSH and Cockpit) and then join all of your VMs to ZeroTier.

Would you expose your hypervisor to the Internet with no firewall in between?

stacksofplates

@eddiejennings said in Networking and 1U Colocation:

@stacksofplates said in Networking and 1U Colocation:

If you're not having other people connect to it and it's just for testing, I'd just leave the connection go to the host (SSH and Cockpit) and then join all of your VMs to ZeroTier.

Would you expose your hypervisor to the Internet with no firewall in between?

For your lab, as long as you use strong SSH keys I don't see an issue with it. I've not tried it but you should be able to set your hosts.allow to only use your workstations ZeroTier IP address. You could also just do an SSH tunnel for Cockpit if you want to use it.

stacksofplates

You can also do extra hardening with something like SCAP.

EddieJennings

The story has evolved a bit, as Colocation America gave me a /29 network rather than /30, so it's possible that could just assign a public IP to the other physical NIC on my server -- though, that seems like not a good practice.

It seems like there has to be a way for my host to be able to access the Internet through one of the guests.

stacksofplates

@eddiejennings said in Networking and 1U Colocation:

The story has evolved a bit, as Colocation America gave me a /29 network rather than /30, so it's possible that could just assign a public IP to the other physical NIC on my server -- though, that seems like not a good practice.

It seems like there has to be a way for my host to be able to access the Internet through one of the guests.

The only way to do that is a full bridge. Either a normal bridge or an OVS bridge.

stacksofplates

I just tested it on my one hypervisor. If I set hosts.allow to my ZT address on my laptop and hosts.deny to all I can still ssh to the KVM host over ZT.

EddieJennings

@stacksofplates said in Networking and 1U Colocation:

I just tested it on my one hypervisor. If I set hosts.allow to my ZT address on my laptop and hosts.deny to all I can still ssh to the KVM host over ZT.

So applying that to my scenario, one of your KVM hosts's NICs would have a public IP address, correct?

There was one point I missed that you said. Eventually, there will be others connecting to the VMs, I'm planning on running a NextCloud VM, PBX, and Zimbra.

EddieJennings

This looks like it worked. I added this line to the appropriate network using virsh net-edit:

<route address='0.0.0.0' prefix='0' gateway='192.168.100.1'/> (yes, the final subnet decision was to use 192.168.100.0/24).

That created a default route, which shows up with ip route show. If I can get DNS resolution, then I'm all set .

EddieJennings

And for DNS, this worked.

nmcli connection mod virbr1 ipv4.dns "8.8.8.8"

Obsolesce

@eddiejennings said in Networking and 1U Colocation:

@stacksofplates said in Networking and 1U Colocation:

If you're not having other people connect to it and it's just for testing, I'd just leave the connection go to the host (SSH and Cockpit) and then join all of your VMs to ZeroTier.

Would you expose your hypervisor to the Internet with no firewall in between?

I forget what hypervisor you're doing and don't feel like scrolling up, so I'm assuming KVM.

But I see no reason to really treat the hypervisor much different than a VPS that basically directly exposed to the public too.

For your hypervisor, you can do what I do for my VPS and ONLY allowSSH, only key-based access, and no root login via ssh. Also make sure you got logwatch and fail2ban going.

Obsolesce

Another good idea is to use something to keep your hypervisor in a specified state, such as SaltStack. That's what I use on my VPS, so I always know a bunch of specific things are ALWAYS in check.

stacksofplates

@tim_g said in Networking and 1U Colocation:

fail2ban

Fail2ban does nothing with key based access. It's denied before fail2ban even sees it.