Início / server / Perguntas / 722222
Accepted
Tom
Asked: 2015-09-15 08:50:31 +0800 CST

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

  • 772

Usamos um serviço cuja API rejeitará solicitações, a menos que o IP de origem tenha sido previamente incluído na lista de permissões. Eles nos dão apenas 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 solucionar esse problema?

Nota: não estou tentando fazer nada contra os Termos e Condições da API de terceiros. Estamos usando o ResellerClub e entrei em contato para pedir mais slots, mas eles responderam:

Solicito que você gentilmente encaminhe seus servidores para alguns conjuntos de IPs.

Daí esta pergunta.

Pensamentos:

  • Eu estava pensando que poderíamos resolver o problema executando uma espécie de proxy que atua como um intermediário. Em vez de fazer solicitações de API para terceiros, nós as fazemos para nosso proxy, que devolve a solicitação para terceiros, para que todas as solicitações pareçam vir de um IP aos olhos deles. Existe um software comum para fazer esse tipo de coisa? Parece mais simples fazer isso do que os pensamentos abaixo, mas estou errado?
  • O uso de "uma instância NAT" é algo que devo investigar? por exemplo , http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html . Parece complicado - Não existe uma solução mais simples? (Executar uma instância extra com complexidade de rede extra é uma pena).
  • 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 sobre um vpc igw regular?

Nossa arquitetura: Usamos AWS e temos nossas instâncias em uma VPC rodando atrás de um ELB. Frequentemente criamos novas instâncias sem saber os endereços IP com antecedência. Executamos software idêntico em todas as máquinas. As máquinas rodam CoreOS e nosso app roda em containers Docker.

proxy

2 respostas

  1. Best Answer

    Uma infraestrutura bastante comum é aquela em que nenhum dos servidores de aplicativos reais possui 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 que eles fizerem será:

    • roteado através de 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 de IP privado e a maior rede
    • 7

  2. Pensei em postar uma atualização, pois o projeto agora foi concluído com sucesso usando uma instância NAT.

    O uso de "uma instância NAT" é algo que devo investigar? Parece complicado - Não existe uma solução mais simples?

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

    As instruções oficiais de configuração da instância NAT da AWS funcionaram bem: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_NAT_Instance.html . Usamos a AMI fornecida pela Amazon para inicializar a instância NAT. Tendo passado pelo processo, percebi o quão "padrão da indústria" é, talvez até "melhor prática".

    As desvantagens:

    1. A instância NAT torna-se um ponto único de falha. Como todo o tráfego externo que sai de nossos servidores da Web é roteado por ele, se houver falha, as instâncias não conseguirão acessar a Internet para receber atualizações de software, chamar APIs externas (como gateways de pagamento) e não poderemos fazer SSH em as instâncias.
    2. Operar uma máquina extra custa dinheiro e é mais para manter. ( t2.smallnão é muito caro e o AMI padrão não precisa ser modificado, portanto, não é um grande fardo de manutenção).
    3. As instâncias terão conexão de rede externa mais lenta. (ainda não consegui notar a diferença).
    4. Não podemos usar o SSH diretamente nas instâncias, precisamos passar pela instância NAT (usando um agente SSH). Isso soa pior do que é. Se você gastar alguns minutos editando .ssh/confige lendo " ProxyCommand", poderá tornar as coisas 100% transparentes para que o uso simplesmente ssh server1funcione.
    5. Não podemos mais testar um servidor específico dentro do cluster usando seu IP público (ou ter um registro DNS para uma máquina específica). Isso é algo que você supera rapidamente. Uma solução alternativa, se você realmente precisar garantir que atingiu uma máquina, é criar um novo ELB e colocar apenas a máquina que deseja segmentar no pool de instâncias.
    • 2

relate perguntas