Tentando rotear o tráfego de saída de um endereço / 32 em uma interface pela rota padrão que é através de outra interface

0
Em primeiro lugar, para dar um pouco de fundo, estou executando uma configuração KVM com inter-redes entre o host e vms através de uma ponte. Todos os IPs abaixo são randomizados também, mas os privados são privados e os IPs públicos são públicos na prática. Host e VM estão no CentOS.

Eu tenho uma interface eth0 com um endereço público que é considerado meu endereço principal do servidor. Eu também tenho blocos roteados adicionais. Este IP primário na eth0 é o que o / 29 de IPs públicos é roteado para. Então, além disso, no host eu tenho a interface virbr0, que é a principal ponte usada pelas minhas máquinas virtuais. Essa ponte permite a comunicação entre o host e as máquinas virtuais, com o host tendo o endereço 192.168.122.1/24 atribuído a ele e todos os outros hosts com um endereço nessa sub-rede. Atualmente, o encaminhamento está ativado e o tráfego se disfarça no IP público atribuído à eth0.

Agora, como não tenho acesso a essa caixa dedicada e tenho medo de perder meu único acesso, brincando com a bridge para permitir que as VMs conversem diretamente na NIC, estou tentando configurar o público Endereços em interfaces dentro das máquinas virtuais - cada um como um / 32 e, em seguida, levá-los a rota através da interface 192.168.122.0/24 que cada host tem uma interface dentro Então, essencialmente rota IPs públicos sobre privado, que eu sei é franzido em cima. Eu sei que eu poderia configurá-lo como um / 29 com o gateway atribuído ao host, mas eu teria que sacrificar um endereço público para o gateway (não seria utilizável na minha configuração como um endereço de origem), então preferiria não para ...

Assim, uma configuração de máquina virtual de exemplo:

eth1 (connected to virbr0) 
192.168.122.200/24

ens7 (local nic only)
80.0.0.1/32

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.122.1   0.0.0.0         UG    100    0        0 eth1
80.0.0.1        0.0.0.0         255.255.255.255 UH    100    0        0 ens7
192.168.122.0   0.0.0.0         255.255.255.0   U     100    0        0 eth1

Agora, com essa configuração, sou realmente capaz de acessar com êxito o SSH no servidor a partir de um local remoto e posso ver que o tráfego está sendo roteado pela interface eth1 via tcpdump do host e retornando ao caminho. No entanto, ao tentar iniciar a conectividade com a conexão originada do IP público em ens7, parece falhar com a mensagem padrão "Destination Host Unreachable". Eu também sou capaz de ver que, ao tentar pingar o DNS do Google, há solicitações ARP saindo para o IP público do Google:

23:10:15.292722 ARP, Request who-has 8.8.8.8 tell 80.0.0.1, length 28

Agora, meu entendimento era de que ele examinaria sua tabela de roteamento e, se a rota padrão fosse anexada a outra interface com um gateway, ela enviaria tráfego sobre ela. Especialmente porque a única rota para a interface é 0.0.0.0, que então atingirá a rota padrão principal. Isso realmente não corresponde às minhas expectativas. Minha expectativa seria que ele agisse de forma semelhante a como um roteador levaria tráfego em uma interface em uma sub-rede e, em seguida, roteasse por outro gateway em uma interface diferente, se necessário, usando sua tabela de roteamento.

Eu também estou um pouco confuso sobre como funciona a conectividade de entrada e saída não. Evidentemente, não é uma configuração padrão e eu considerei uma configuração de rede mais padrão / 29. No entanto, as necessidades devem e estou tentando fazer com que isso funcione.

Qualquer conselho é bem-vindo ... Eu só quero essencialmente obter a conectividade de saída funcionando. Inbound não é o que eu preciso neste exemplo. Tudo o que preciso é que uma interface seja padronizada para enviar seu tráfego para fora de outra quando originada do mesmo servidor.

Por favor, pergunte se algum esclarecimento é necessário. Essa é uma das áreas mais cinzentas do conhecimento. Muito obrigado antecipadamente!

Hugh

    
por Hugh 12.02.2018 / 01:24

0 respostas