git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is that safe to put public IP directly on Virtual Router/ System VMs?


Hi Eric Lee,

Thanks for detail explanation. You shed some light to my doubts.

Regards,
Netlynker

On Thu, 27 Sep 2018 at 9:37 AM, Eric Lee Green <eric.lee.green@xxxxxxxxx>
wrote:

> On 9/26/18 6:21 PM, Netlynker wrote:
> > Hi Eric,
> >
> > Usual setup for my other infra service is that we use external firewall
> > doing NAT and protecting the resource behind. The public IP will stay on
> > that firewall and it is NATed to private IP of the service internal.
> >
> > What CS document imply is to put “real” public IP address on System VMs
> and
> > VR which will leave those systems exposed directly to outside world.
>
> That is the configuration for a public Cloudstack service. If you are a
> corporation setting up a private cloud within a corporation, the "public
> address" should be routed to your corporate network. For example, my
> corporate "floor" network that goes to the desktops on people's desks is
> 10.100.0.0/16 while my corporate "wifi" is 10.101.0.0/16. I gave my
> Cloudstack cluster the public address of 10.102.0.0/16 which is routed
> to my external firewall router via a VLAN-enabled Cisco Layer 3 switch
> to the actual firewall on the external DMZ VLAN 10.2.0.0/24. (Other
> private networks such as the pool for VPC creation use additional 10.x
> subnets). The 10.102.x.y addresses are "internet" addresses as far as
> Cloudstack is concerned -- they can access the Internet. The fact that
> they're accessing it via my corporate network rather than being directly
> connected to the Internet is irrelevant.
>
> As far as the safety of the router virtual machines, they are a small
> Linux distribution just like the one in your external firewall, that,
> like the one in your external firewall, is configured with routes and
> firewall rules to be secure. If you were doing a public-facing Internet
> service there would be no problem putting them directly on the public
> Internet. From a design perspective they're no more or less secure than
> your current NAT firewall, which is also a small Linux distribution
> unless it's a Cisco. Whether you want to put them directly onto the
> Internet or not depends on your design goals, not safety. If you want to
> be able to access your virtual machines from the public Internet without
> logging in via a VPN, such as publicly available services, then a NAT
> firewall between your Cloudstack service and your virtual machines will
> not allow for that. If you are satisfied with having your virtual
> machines only be reachable from your corporate network and comfortable
> with VPN access for those times you need to access them remotely, then
> sure, put them on your corporate network behind the NAT firewall. That's
> what I do, because my production virtual machines providing service to
> the general public are running on the Amazon cloud, my Cloudstack
> installation is for corporate-private R&D and support instances that the
> general public isn't supposed to access.
>
> > My question is if that architecture is recommeneded and how safe it is to
> > put “real” public IP on System VMs and VRs directly.
> >
> > Thanks in advance,
> > Netlynker
> >
> > On Thu, 27 Sep 2018 at 8:58 AM, Eric Lee Green <eric.lee.green@xxxxxxxxx
> >
> > wrote:
> >
> >> On 9/25/18 6:29 PM, Netlynker wrote:
> >>> Hi,
> >>>
> >>> I looked at the deployment architecture from document and it said to
> have
> >>> public IP addresses on Virtaul Router/System VMs.
> >>>
> >>> Is that recommended setup?
> >>>
> >>> How safe will it be to expose Virtaul Router/ System VMs directly to
> >>> internet?
> >>
> >> If a virtual router is not connected to the Internet, how will it route
> >> traffic from your internal VM's in their virtual private networks to the
> >> Internet? Magic? (This presuming you have an Internet-facing service,
> >> but even if it's internal to your company, the virtual router is going
> >> to need to be able to talk to the Internet via your company's "internal"
> >> Internet network if your internal VM's on their own internal private
> >> networks are going to get to the Internet or other corporate resources).
> >>
> >>
> >>
> >>
>
>