1

We use a service who's API will reject requests unless the source IP has been previously whitelisted. They only give us 3 slots which is a problem because we have more than 3 machines that need to use the API.

What is the most common technique to workaround this issue?

Note: I'm not trying to do anything against the Terms & Conditions of the 3rd-party API. We are using ResellerClub and I contacted them to ask for more slots but they replied:

I request you to kindly route your servers to a few set of IPs.

Hence this question.

Thoughts:

  • I was thinking we could solve the problem by running a sort of proxy that acts as a man-in-the-middle. Instead of making API requests to the 3rd-party we make them to our proxy which bounces the request to the 3rd-party so that all requests seem to all come from one IP in their eyes. Is there common software for doing this kind of thing? It seems simpler to do this than the below thoughts, but am I wrong?
  • Is using "a NAT instance" something I should be looking into? e.g. http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html . It looks complicated - Is there not a simpler solution? (Running a extra instance with extra networking complexity is a shame).
  • Since we use Docker, could Weave be relevant?
  • Could we attach a static IP to the VPC gateway? I saw it's possible with the AWS Storage Gateway (source) - not sure about a regular vpc igw though?

Our architecture: We use AWS and have our instances in a VPC running behind a ELB. We frequently bring up new instances without knowing the IP addresses in advance. We run identical software on all machines. The machines run CoreOS and our app runs in Docker containers.

Tom
  • 4,157
  • 11
  • 41
  • 52

2 Answers2

7

A fairly common infrastructure is one where none of the actual application servers have public IPv4 IP-addresses, they will be in a RFC 1918 private network range behind a load-balancer and any outgoing request they make is either:

  • routed through a NAT gateway, giving the appearance of a single source IP-address
  • must be made through a proxy server, which bridges between the private IP-range and the greater internet
HBruijn
  • 72,524
  • 21
  • 127
  • 192
2

I thought I would post a update since the project is now completed successfully using a NAT instance.

Is using "a NAT instance" something I should be looking into? It looks complicated - Is there not a simpler solution?

Now that the NAT instance is all set up, the initial feeling of complexity has passed and it actually feels quite simple - even cleaner than before actually (because being forced to use private subnets is a security boost).

The official NAT instance setup instructions from AWS worked well: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html . We used the AMI that Amazon provide for booting the NAT instance. Having gone through the process, it made me realise how "industry standard" it is, maybe even "best practice".

The disadvantages:

  1. The NAT instance becomes a single point of failure. Since all external traffic coming out from our webservers is routed through it, if it fails instances won't be able to reach the internet to receive software updates, call external APIs (such as payment gateways), and we wont be able to SSH into the instances.
  2. Running a extra machine costs money and is more to maintain. (t2.small isn't very expensive, and the stock AMI doesn't need modifying, so isn't a huge maintenance burden ).
  3. The instances will have slower external network connection. (I haven't been able to notice the difference so far).
  4. We can't SSH into instances directly, we need to go via the NAT instance (using a SSH Agent). This sounds worse than it is. If you spend a few mins editing .ssh/config and read up on "ProxyCommand" you can make things 100% transparent so that using simply ssh server1 works.
  5. We can no longer test a particular server within the cluster by using it's public IP (or have a DNS record for a particular machine). This is something you get over quickly. A workaround if you really need to ensure you hit one machine is to create a new ELB and only put the machine you want to target into the instance pool.
Tom
  • 4,157
  • 11
  • 41
  • 52