View Single Post
  #4   (View Single Post)  
Old 23rd March 2015
rocket357's Avatar
rocket357 rocket357 is offline
Real Name: Jonathon
Wannabe OpenBSD porter
 
Join Date: Jun 2010
Location: 127.0.0.1
Posts: 429
Default

Quote:
Originally Posted by Oko View Post
Can you be little bit more specific? I have experience with virtual hosts and Nginx as a proxy server. I run Nginx on my firewall with the public address with uploaded SSL certificate. And Nginx points back to a "virtual host" one of my machines behind. My EasyDNS points A record of the HTTPS server to the firewall even though content is served by the "virtual host"

Now I don't control firewall and everything I see on the internet talks about purchasing load balancer from Amazon and uploading certificate there. To make things more complicated I am not using Amazon DNS. So basically the way things work without SSL is that point CNAME which I want to use for my web server to something like

ec2-54-69-99-199.us-west-2.compute.amazonaws.com

So do I generate SSL certificate for

ec2-54-69-99-199.us-west-2.compute.amazonaws.com

or for the name I want my web server to have

www.oko.com
Static NAT is a 1:1. A packet comes in on, say 54.166.123.245, it is translated to the private IP, say, 172.30.234.65, and forwarded to the instance with that private IP. Outgoing packets are treated exactly the same, albeit in reverse. The only protocols that operate problematically that I've seen are protocols such as certain VoIP protocols that, for whatever reason the authors of said protocols decided to embed the *private* ip as the connect-back ip into the packet payloads, which isn't altered by SNAT.

You should use the url you want the web server to have, then configure nginx to proxy from one instance to another on the private IPs. (If you do point to that ec2-* hostname, and you have to stop/start the instance for maintenance or due to underlying hardware issues, your cert will be useless as the odds of you getting that exact IP/attached DNS record back are *incredibly* slim...hence the Elastic IP suggestion. You would want www.oko.com to resolve to the Elastic IP, which stays with your account and can be moved between instances, if necessary).

The details of how the private ips work together depend heavily on whether you are running in an EC2 Classic environment or a VPC environment. If VPC (default for all new accounts...so you're using this unless this account is an older account), then you could setup a public subnet and private subnet within the VPC CIDR, then put the nginx proxy in the public subnet (and attach an Elastic IP to it...trust me, you want to do this!), and put the backend web server in the private subnet. You can configure your security groups (stateful firewall rules, basically) to control what traffic can hit your instances, and you can apply more than one security group to each instance. You might setup a management security group for ssh access from your IPs, a public web security group for your nginx proxy, and a restricted "direct access" security group for your backend web server. You would then apply both the management and appropriate web access security groups to your instances.

Also, if you plan on wiring up OpenBSD to a VGW for VPN access to your VPC (yes, talking like this gets incredibly old on a daily basis), I can point you to a few howto's I've written up expressly for that purpose. Static is easier but I've found the BGP-based configuration to be a bit more stable in the long-run.


Quote:
Originally Posted by Oko View Post
No we are not using Elastic IP for now and I noticed that shit. Thanks for confirming this to me. We need to migrate one of the machines out of CMU for legal reasons and I am not sure that Amazon is good idea but I was overruled.
Amazon is a great way to supplement existing compute capacity or run incredibly low cost web sites (that give you more control than, say, HostGator). It isn't a perfect "one-size-fits-all" solution, to be certain (though it is, in my biased opinion, quite nice for very many tasks as long as those tasks don't involve running OpenBSD instances =\ ).
__________________
Linux/Network-Security Engineer by Profession. OpenBSD user by choice.

Last edited by rocket357; 23rd March 2015 at 11:43 PM.
Reply With Quote