On Sep 28, 2016, at 9:43 AM, <tdu...@palmettoshopper.com> <tdu...@palmettoshopper.com> wrote: > > The first one, I created in my / file system but didn't really have the > space so I deleted it.
One of the primary advantages of VMs over real machines is that you can pause them, move them, and then restart them, with the VM guest OS not realizing that anything has happened. Some virtual machine management systems even automate this, letting you move an active VM without any downtime at all. > The second one, I created in /home/kvm, but deleted it as well when I > couldn't access it FROM the internet. That’s actually the main reason to use NAT over bridged networking: to *prevent* outsiders from connecting into the VM guest. It’s a good thing for exactly the same reason your home internet service’s router/gateway’s NAT is a good thing. While it is possible to drill a hole back through the VM’s NAT layer into the guest using port mapping rules, that amounts to double NAT, which adds an unnecessary amount of complexity. If all of the threats to the VM guest are outside the LAN’s border gateway, it’s simpler to use bridged networking, and set up the port forwarding rules on the LAN border gateway. Beyond that general advice, you escape anything CentOS-specific, so you need to take the problem up elsewhere, such as https://portforward.com/ > I want to be able to access this VM from the internet. Once the VM is set to use port forwarding and a static IP, you can forward port 22 to the Internet. I recommend that the port forwarding rule expose the internal port 22 as some random value on the outside. This will cut down on a lot of script kiddie spam in your logs. Some will decry this as “security through obscurity,” but that’s bogus. Obscurity is not a bad thing in itself. The problem comes when obscurity is your *only* security. That’s not the case with SSH. I don’t recommend forwarding any other ports to the Internet, if you can possibly get away with it. SSH can do its own port forwarding, which reduces your VM’s attack surface from the Internet. With SSH acting as a poor-man’s VPN, an attacker would have to break SSH before they can get into any of your internal VM’s other services. Alternately, you could set up a VPN, and then you wouldn’t need to mess with port forwarding, either at the LAN border or via SSH. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
