Proporcionar acesso público a um servidor web local através de VPN

Question

Eu tenho um túnel VPN estabelecido entre dois servidores: VPS-A e VPS-B com os endereços IP públicos (fictícios): 66.55.44.33 e 77.88.55.66, e pontos de extremidade VPN 10.0.1.1 e 10.0.2.1 respectivamente. / p>

Existe um servidor web em execução no VPS-A. Eu posso sem um problema SSH para VPS-B e receber uma resposta ao emitir uma solicitação HTTP para 10.0.1.1 via curl por exemplo:

curl http://10.0.1.1/

Eu também posso abrir um navegador em qualquer computador conectado à Internet e abrir com sucesso

http://66.55.44.33/

... mas também quero poder acessar o servidor da Web no VPS-A enviando uma solicitação para o VPS-B, ou seja,

http://77.88.55.66/

Agora, adicionei a seguinte regra no VPS-B ( editada para mostrar a regra correta )

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 10.0.1.1:80

... e quando estou fazendo um tcpdump na porta 80, posso ver claramente como as solicitações para http://77.88.55.66/ estão sendo encaminhadas corretamente para http://10.0.1.1 . No entanto, o servidor da Web no VPS-A não parece confirmar a solicitação TCP. Veja o que o tcpdump mostra exatamente:

2013-04-27 03:45:15.001564 IP 45.248.82.171.51377 > 10.0.1.1.80: S 791893048:791
2013-04-27 03:45:15.252571 IP 45.248.82.171.51378 > 10.0.1.1.80: S 670490211:670
2013-04-27 03:45:18.001526 IP 45.248.82.171.51377 > 10.0.1.1.80: S 791893048:791
2013-04-27 03:45:18.258666 IP 45.248.82.171.51378 > 10.0.1.1.80: S 670490211:670

.. enquanto para um pedido vindo através da VPN:

2013-04-27 04:26:57.464859 IP 10.0.2.1.33258 > 10.0.1.1.80: S 2369100373:2369100373(0) win 5744 <mss 1436,sackOK,timestamp 121795122 0,nop,wscale 7>
2013-04-27 04:26:57.464913 IP 10.0.1.1.80 > 10.0.2.1.33258: S 3524730589:3524730589(0) ack 2369100374 win 5744 <mss 1436,nop,nop,sackOK,nop,wscale 7>
2013-04-27 04:26:57.532428 IP 10.0.2.1.33258 > 10.0.1.1.80: . ack 1 win 45

Sou muito novo no Linux, então tenho certeza de que não estou fazendo algo certo, mas não sei o que exatamente. Tentei pesquisar por perguntas semelhantes, mas não encontrei nada. Se alguém puder me indicar um recurso útil ou me dar um exemplo prático, isso seria ótimo.

Obrigado pelo seu tempo lendo meu post!

    

Answer 1

Sua descrição deve estar incompleta. As regras em INPUT e FORWARD não farão os pacotes 77.88.55.66 passarem para 10.0.1.1. Isso é possível com a meta DNAT na cadeia PREROUTING da tabela nat . Obviamente, existe tal regra.

Para um redirecionamento bem-sucedido, você não precisa de regras no INPUT, pois esses pacotes não devem ser recebidos pelo sistema de redirecionamento.

O problema com o DNAT sem SNAT (como no seu caso) é que um sistema geralmente não se importa com ele sobre qual interface ele foi atingido ao rotear a resposta. Seu VPS-A vê uma abertura de conexão de 45.248.82.171 e, se estiver disposto a se comunicar com esse cliente, envia uma resposta para - sim, 45.248.82.171. O cliente enviou um pacote SYN para 77.88.55.66 e recebe um SYN ACK de 66.55.44.33 e obviamente pensa apenas em WTF? Por que de 66.55.44.33? Porque a resposta não é enviada pelo túnel porque a configuração de roteamento do VPS-A diz para não enviar pacotes para este destino através do túnel. Se eles voltassem pelo túnel, o VPS-B reescreveria o endereço de origem e tudo ficaria bem.

Então você tem que usar o iptables para marcar as conexões que vêm pelo túnel (por que pelo tunel?), reescrever a marca de conexão para um pacote e usar o roteamento avançado com esta marca de pacote para ter esses pacotes enviados o tunel. Ou você faz os dois lados do NAT, faz o SNAT antes de enviá-lo do VPS-B pelo túnel e recupera-o do VPS-A da maneira mais fácil. Desvantagem: Os logs do servidor web mostram o endereço IP "errado" (sempre 10.0.2.1).

BTW: 10.0.2.1 e 10.0.1.1 são endereços finais estranhos da mesma VPN, não são?