Amazon EC2: O servidor OpenVPN não roteará pacotes em ponte do cliente para a sub-rede VPC

Question

Eu tenho uma configuração do OpenVPN em ponte em um servidor Linux em um Amazon EC2 VPC. (Passei horas em docs, lendo problemas semelhantes, aqui, fóruns openVPN, sem sorte ainda.)

A interface em ponte está ativa e contém as duas subinterfaces:

# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.0e7c15e787b0       no              eth0
                                                        tap0

O roteamento é obviamente OK no servidor VPN; Eu posso SSH entrar, ping ao redor, responder à solicitação de VPN do cliente:

# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.0.0.1        0.0.0.0         UG        0 0          0 br0
10.0.0.0        0.0.0.0         255.255.0.0     U         0 0          0 br0

Eu posso pingar do Windows & Clientes Mac para o IP do servidor VPN, mas não para qualquer outro IP na sub-rede VPC. (Esses outros IPs são OK; eles são pingáveis do servidor VPN.)

Quando eu tcpdump na interface da bridge br0 no servidor VPN ele vê as requisições "ARP who-has" do cliente Windows. No entanto, eles não estão indo para a sub-rede VPC! tcpdump no IP de destino não vê o ARP chegar. O cache de arp do Windows permanece não preenchido. (10.0.0.128 é o cliente Windows; 10.0.0.58 é o servidor VPN; 10.0.0.180 é o outro IP na sub-rede; a saída abaixo é do servidor VPN.)

root@vpn:# tcpdump -i br0 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes
21:00:21.092367 ARP, Request who-has 10.0.0.180 tell 10.0.0.128, length 28

[grilos]

Desativei a opção Origem / destino. verifique no console do EC2 na interface de rede do servidor VPN.

Eu configurei as tabelas de IP conforme recomendado no HOWTO de bridging, e geralmente segui essas instruções exatamente.

# iptables -L INPUT -v
Chain INPUT (policy ACCEPT 9 packets, 1008 bytes)
 pkts bytes target     prot opt in     out     source               destination
   38 12464 ACCEPT     all  --  tap0   any     anywhere             anywhere
10447 1297K ACCEPT     all  --  br0    any     anywhere             anywhere

# iptables -L FORWARD -v
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
  918  167K ACCEPT     all  --  br0    any     anywhere             anywhere

link

Eu não acho que eu preciso descarregar as configurações completas porque obviamente muito está funcionando: autenticação, certs, compactação, pool de endereços, configuração de conexão em geral. O Amazon VPC simplesmente se recusa a encaminhar pacotes e eu realmente deveria estar em uma nuvem um pouco menos virtual para fazer isso?

MAIS EXPERIMENTOS NO PRÓXIMO DIA: O VPC claramente não está se comportando como uma verdadeira sub-rede de camada 2. Em particular, as transmissões de who-has do ARP não são realmente transmitidas! Quando eu pingar um IP inexistente (digamos 0,5) de 0,180, 0,58 não vê a solicitação. O VPC está obviamente otimizando as transmissões de ARP e enviando-o apenas para .5, se um .5 tiver sido configurado no VPC via console de gerenciamento / API . Deixar tcpdump -vv -i eth0 arp ativo por enquanto mostra apenas o tráfego entre o host e o gateway, para todos os hosts.

Além disso, o ping do endereço de broadcast na sub-rede não funciona. Isso é feito por meio do FAQ da Amazon VPN.

Assim, o VPC provavelmente se recusa a reconhecer o endereço MAC desconhecido de 0,129, já que não existe em seu próprio "switch ethernet virtual". Eu provavelmente vou mudar isso como a resposta em uma semana ou mais. Para estender a VPC com sua própria VPN, ela deve ser feita por meio do "gateway VPC" formal, que é projetado apenas para funcionar como uma extensão de uma intranet corporativa apoiada por um roteador de hardware dedicado e IP estático, não pelo cenário de laptop móvel " m visando.

    

Answer 1

Sua VPN precisa ser roteada, não conectada, e a sub-rede na qual seus clientes VPN estão conectados deve estar fora dos limites da super-rede VPC.

Em seguida, adicione uma rota estática para a sub-rede do cliente VPN nas tabelas de roteamento VPC, com o destino dessa rota especificado como o ID da instância do servidor vpn.

A rede VPC é uma rede virtual definida por software. Não é uma rede de camada pura 2, mas na maioria das vezes, emula muito bem. As transmissões, no entanto, não são uma dessas maneiras.

Se você perceber, não há uma correlação de 1: 1 do tráfego ARP de uma instância para outra. A resposta que você obtém para um ARP who-has não vem da instância com o IP atribuído. Vem da rede. Se a instância de destino realmente vir a solicitação recebida, ela não está realmente vendo a que você enviou.

O VPC foi projetado dessa forma por alguns motivos bastante convincentes, escalabilidade e segurança entre eles.

O fato de os endereços IP dentro do escopo da supernet da VPC estarem em instâncias, apenas, é um efeito colateral disso. Mesmo se você usar a solução de hardware vpn disponível, você ainda não pode ter endereços privados dentro da super-rede VPC no outro lado desse link ... por isso não é uma limitação encravada para fazer você pagar por algo extra ... é apenas parte do design.

Visualização recomendada: VPC / A dia na vida de um bilhão de pacotes (CPN401)

link