Now the console is nice, but it would be much more convenient if we
also had network access to an instance. In order to this though,
we need an internet address, and we need to punch holes in the
firewall that surrounds the instance.
Right, so with this SSH daemon and our IP address, it should be
possible to reach the instance via the network.
To see how this is done, let's look at our network topology.
So what I would like to achieve is accessing a web server from the
public network, which is the outside network.
The problem is the IP address is not routable, actually there might be
several instances with the same address, there might be several
networks like the private network that have the same IP address range.
So what can we do, how can we access this instance?
The solution is that we create an external address, which is then
mapped by the router to the web server. Such an external address is
also named a floating IP, that's a term that OpenStack borrowed from Amazon.
In order to allocate such a floating IP and associate it with our
server, we have to go back to the instance details.
And in the menu here on the upper-right, we have an option that looks
promising, Associate Floating IP. Right now no IP addresses are
allocated, so we have to do that by clicking on the plus sign.
We have to select a pool, there is only one pool, and that pool is
associated with our external network named public.
So this is the IP we received, and now we have to associate it with
one of our instances, and we just select here the web server, it's already prefilled.
And if we go to the Overview page, you can see at the bottom here,
let's put that more into the middle, that this address is now also
associated with this server. Let's test this now.
I will log on to the Packstack server, let me see if there is a route
to that external network, and as you can see, there is one.
Let's see if there is connectivity to our instance.
And that doesn't look so good. It looks like there isn't any
connectivity, we don't get any echo replies.
Why is that so? Well, very simply, the instance is protected by a
firewall, and by default, OpenStack implements a very restrictive
firewall around instances, which simply blocks all traffic.
Now our job is now to selectively open the firewall for the traffic
that we want. The mechanism to do that is named Security Group,
and here on the details screen of our web server, we see indeed a
security group has been defined, it's called default.
It doesn't do what we want, so I will create a new one.
I'm now in the Access and Security section, where security groups can be defined.
I'm going to create a new one. I'll name it ssh, provide some description.
Okay, it exists now, but now we have to tell it what ports should be
open, and we do this by adding rules. The first rule we add is the SSH rule.
We have to scroll down a little bit, it's at the end.
And this rule allows SSH traffic to reach the instance.
We have to add another rule for ICMP traffic, so that we can ping the instance.
To simplify things, I just permit all types of ICMP traffic,
and here are our two rules. Now this instance, this security group
has to be associated with the instance. Let's go back to the
Instances overview screen, and in the actions menu, you can see here
an option, Edit Security Groups. And I will just add the new security
group to the instances Security Groups list.
With that, we should be able to access our server.
And as you can see, connectivity is there, what about SSH?
That looks good. The problem is though this instance doesn't have a
username stack, so I think we have to change that.
We are, by the way, very lucky that this instance has any user that we
can access via a password. This is not normally the case with cloud instances.
In any case here we are, let me just same commands again,
storage and networking, so everything looks good.