Como solucionar uma lista de permissões de IP ao consumir uma API de terceiros?

Question

Usamos um serviço cuja API rejeitará solicitações, a menos que o IP de origem tenha sido anteriormente colocado na lista de permissões. Eles só nos dão 3 slots, o que é um problema, porque temos mais de 3 máquinas que precisam usar a API.

Qual é a técnica mais comum para contornar esse problema?

Observação: não estou tentando fazer nada contra os Termos & Condições da API de terceiros. Estamos usando o ResellerClub e eu entrei em contato com eles para solicitar mais vagas, mas eles responderam:

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

Daí esta questão.

Pensamentos:

• Eu estava pensando que poderíamos resolver o problema executando uma espécie de proxy que age como um homem no meio. Em vez de fazer solicitações de API à terceira parte, nós a transformamos em nossa proxy, que envia a solicitação para a terceira parte, de modo que todas as solicitações parecem vir de um único IP aos seus olhos. Existe software comum para fazer esse tipo de coisa? Parece mais simples fazer isso do que os pensamentos abaixo, mas estou errado?
• Está usando "uma instância NAT", algo que eu deveria estar investigando? por exemplo. link . Parece complicado - não existe uma solução mais simples? (Executar uma instância extra com complexidade de rede extra é uma vergonha).
• Como usamos o Docker, o Weave pode ser relevante?
• Podemos anexar um IP estático ao gateway VPC? Eu vi que é possível com o AWS Storage Gateway ( source ) - não tenho certeza vpc igw embora?

Nossa arquitetura: usamos a AWS e temos nossas instâncias em um VPC em execução atrás de um ELB. Frequentemente, exibimos novas instâncias sem conhecer os endereços IP antecipadamente. Nós rodamos software idêntico em todas as máquinas. As máquinas executam o CoreOS e nosso aplicativo é executado em contêineres do Docker.

    

Answer 1

Uma infra-estrutura bastante comum é aquela em que nenhum dos servidores de aplicativos reais tem endereços IP IPv4 públicos; eles estarão em um intervalo de rede privada RFC 1918 atrás de um balanceador de carga e qualquer solicitação de saída será:

• roteado por um gateway NAT, dando a aparência de um único endereço IP de origem
• deve ser feito por meio de um servidor proxy, que faz a ponte entre o intervalo IP privado e a Internet maior

Answer 2

Pensei em publicar uma atualização, pois o projeto foi concluído com êxito usando uma instância do NAT.

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

Agora que a instância do NAT está configurada, o sentimento inicial de complexidade já passou e ela realmente parece bastante simples - até mais limpa do que antes (porque ser forçada a usar sub-redes privadas é um reforço de segurança).

As instruções oficiais de configuração da instância NAT da AWS funcionaram bem: link . Usamos a AMI que a Amazon fornece para inicializar a instância do NAT. Tendo passado pelo processo, isso me fez perceber como é o "padrão da indústria", talvez até mesmo a "melhor prática".

As desvantagens:

1. A instância do NAT se torna um único ponto de falha. Como todo o tráfego externo proveniente de nossos servidores da Web é roteado por ele, se houver falhas, as instâncias não poderão acessar a Internet para receber atualizações de software, chamar APIs externas (como gateways de pagamento) e não conseguiremos SSH em as instâncias.
2. A execução de uma máquina extra custa dinheiro e é mais para manter. ( t2.small não é muito caro, e a AMI das ações não precisa ser modificada, portanto não é um fardo enorme de manutenção).
3. As instâncias terão uma conexão de rede externa mais lenta. (Eu não consegui perceber a diferença até agora).
4. Não podemos fazer o SSH em instâncias diretamente, precisamos passar pela instância do NAT (usando um Agente SSH). Isso parece pior do que é. Se você gastar alguns minutos editando .ssh/config e lendo em " ProxyCommand ", poderá tornar as coisas 100% transparentes, de modo que usar simplesmente ssh server1 funcione.
5. Não podemos mais testar um determinado servidor no cluster usando seu IP público (ou ter um registro DNS para uma determinada máquina). Isso é algo que você supera rapidamente. Uma solução alternativa, se você realmente precisa garantir que acessa uma máquina, é criar um novo ELB e apenas colocar a máquina que deseja segmentar no pool de instâncias.