Envie todo o tráfego para eth0, receba todo o tráfego para eth0, exceto o acesso ssh via eth1

Question

Eu tenho:

• interface eth0 com 10.0.0.41 tendo o ip público 54.x.x.x (será usado para o cliente VPN)
• interface eth1 com 10.0.0.100 com o IP público 57.x.x.x

eth1 é onde eu estou conectado remotamente usando o SSH eth0 será conectado a outro servidor como VPN IPsec

porque meu roteamento padrão é eth1, enquanto conecto a VPN ele falha, pois o servidor VPN só permite o ip 54.x.x.x não o tráfego de 57.x.x.x

Agora, como posso dizer ao roteamento que todo o tráfego que vai para o endereço do servidor VPN: 212.xxx será enviado via eth0 (54.xxx) e ainda ter eth1 (57.xxx) disponível para acesso remoto SSH?

EDITAR:

EDIT:aamazonpermite-meter2diferentesippúblicosdesub-redeparaaminhainterfacederede2.parecequenão

EDIT:AmazonEC2-VPCcomváriassub-redes

link

Cenário 1: VPC com apenas uma sub-rede pública - 1 sub-rede link

Cenário 2: VPC com sub-redes públicas e privadas - 2 sub-redes link

Cenário 3: VPC com sub-redes públicas e privadas e acesso VPN de hardware - 3 sub-redes link

Cenário 4: VPC com uma sub-rede privada e acesso VPN de hardware link

EDITAR:

Etapa 1: Amazon EC2 > Cenário 1: VPC com apenas uma sub-rede pública - 1 sub-rede

Passo 2: isto permitirá a sub-rede 10.0.0.0/24 com 1: 1 NAT

Etapa 3: para fazer o desvio de tráfego de entrada e saída, devemos fazer:

ip rule add from 10.0.0.41/32 table 1 # outbound
ip rule add to 10.0.0.41/32 table 1   # inbound
ip route add default via 10.0.0.1 dev eth0 table 1

ip rule add from 10.0.0.100/32 table 2 # outbound
ip rule add to 10.0.0.100/32 table 2   # inbound
ip route add default via 10.0.0.1 dev eth1 table 2

Passo 4: teste remotamente assumindo que o pc remoto tem: iamremotely_publicip

ping publicip_eth0
ping publicip_eth1

Etapa 5: teste de entrada

$ tcpdump -vv src iamremotely_publicip and not dst port 22 -i any

### inbound reply received for eth0
13:29:02.163426 IP (tos 0x0, ttl 55, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    2.205.81.5 > ip-10-0-0-41.eu-west-1.compute.internal: ICMP echo request, id 10242, seq 1, length 64

### inbound reply received for eth1
13:24:05.415740 IP (tos 0x0, ttl 55, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    2.205.81.5 > ip-10-0-0-100.eu-west-1.compute.internal: ICMP echo request, id 11808, seq 52, length 64

Passo 6: teste de saída no PC iamremotely_publicip

$ tcpdump -vv src publicip_eth0 and not dst port 22 -i any
$ tcpdump -vv src publicip_eth1 and not dst port 22 -i any

Isso funciona sem VPN.

    

Answer 1

Não está muito claro como sua LAN está configurada e parece estar desativada.

• de que é parte eth0 / 1? Um servidor DMZ? Ou é o roteador padrão da sua LAN local?

• Quais são os dispositivos reais atribuídos com 54.x.x.xe 57.x.x.x? Eles são dois roteadores físicos da Internet? Ou link PPP estabelecido a partir deste host?

• Você quer que a eth0 seja uma interface dedicada para um link IPsec para uma rede remota que tenha um IP 212.x.x.x voltado para o público correto?

• Se o eth0 for destinado a um link VPN dedicado a uma rede VPN remota, por que ele está anexado à sub-rede local 10.0.0.x local?

Você deve usar sub-redes diferentes para eth0 e eth1, caso contrário, é muito confuso e você é obrigado a ter pacotes sendo enviados de ambas as interfaces, porque o host acha que eles estão na mesma sub-rede. Se eth0 é destinado apenas a um link dedicado VPN, dá-lhe uma sub-rede fictícia como 192.168.200.x. Sua LAN local e remota nunca deve ser roteada para essa sub-rede, eles só usarão esse link dentro do túnel da VPN, que terá IPs locais privados (10.0.0.x).

Contanto que você tenha uma rota estática para o 212.xxx usar eth0, assim que o link VPN for estabelecido, todo o tráfego designado para a LAN remota usará o túnel e, portanto, eth0, não há necessidade de roteamento especial Desde que o ponto de extremidade IPsec exista no roteador principal em sua LAN, todas as rotas necessárias devem ser configuradas para você.

O problema que você está tendo com o bloqueio remoto do servidor VPN 54.x.x.x é uma restrição de segurança unicamente relacionada à extremidade remota. O servidor VPN remoto está esperando o tráfego somente de 57.x.x.x e o pedido de bloqueio de 54.x.x.x. Para o qual você tem que descobrir porque está fazendo isso. Você iniciou o link da VPN usando 57.x.x.x? Ou o servidor VPN está restringindo o acesso usando a pesquisa inversa de DNS, e você não configurou o DNS adequadamente para que o link VPN seja estabelecido a partir de um nome de host DNS que resolva de volta para 54.x.x.x? O link IPsec está usando um certificado SSL vinculado a um nome de host DNS que resolve para 57.x.x.x?

EDIT: Aqui está a sugestão revisada:

• Peça à Amazon para fornecer uma sub-rede diferente no link 54.x.x.x (você não pode simplesmente atribuir um IP arbitrário ao seu host e esperar que os roteadores da Amazon saibam como lidar com isso)

• Configure o eth0 com a nova sub-rede e o gateway padrão (digamos, ip 10.0.2.2 gw 10.0.2.1). 10.0.2.2 é o IP local para eth0 e 10.0.2.1 é o gateway padrão para essa sub-rede, que reside na rede da Amazon.

• Seu host já deve ter uma rota padrão para 10.0.2.0 para usar 10.0.2.2 como a interface quando você configurar eth0, qualquer tráfego para 10.0.2.0/24 pulará a eth1.

• configure uma rota estática para o servidor VPN 212.x.x.x para usar 10.0.2.1 como o gateway. Não deve haver necessidade de especificar eth0.

• FEITO. Quando você se conecta ao 212.x.x.x, ele usa automaticamente o eth0 e o gw 10.0.2.1, que, por sua vez, vão para a Internet com o link 54.x.x.x

Answer 2

A rotatividade de políticas deve funcionar com a configuração normal, não tendo certeza se funciona com o NAT / VPN, mas eu tentaria algo nas seguintes linhas:

ip rule add from src 10.0.0.41/32 table 1
ip route add default via 10.0.0.xxx dev eth0 table 1

ip rule add from src 10.0.0.100/32 table 2
ip route add default via 10.0.0.xxx dev eth1 table 2

mas não tenho ideia de como a Amazon roteia essas redes e a VPN funcionará com essa configuração.

Além disso, você pode precisar fazer algumas arp magic para fazer com que aqueles funcionem corretamente se o cache de arp não estiver frio.

Mas isso deve garantir que seu tráfego de 10.0.0.100 seja apagado via eth1 e .41 via eth0, então você deve ser capaz de acessá-lo via eth1 se o NAT 1: 1.

Não teste isso em nada além de instância de teste, você pode perder a conectividade de rede completamente.