☰

VPN no Linux - problema de roteamento IP

tag-icon • tag-icon linux iptables vpn routing
VPN no Linux - problema de roteamento IP

Eu tenho o seguinte cenário:

um servidor Ubuntu 20.04 lts, ​​para simplificar denominado Um servidor com as seguintes interfaces de rede:

  • loopback
  • enp1s0 (wan) PUBLIC-IP/23
  • enp8s0 (lan) 10.9.96.3/20
  • ppp0 (l2tp) 192.168.42.1

com esta tabela de roteamento (rotas públicas são omitidas intencionalmente):

  • 10.9.96.0/20 dev enp8s0 link de escopo do proto kernel src 10.9.96.3
  • 192.168.1.0/24 via 192.168.42.10 dev ppp0
  • 192.168.42.10 dev ppp0 proto kernel escopo link src 192.168.42.1

Há um cliente VPN remoto conectado com ip 192.168.42.10.
Este cliente é um roteador MikroTik que fornece a rede LAN remota 192.168.1.0/24.
Usando a rota estática adicionada por mim (192.168.1.0/24 via 192.168.42.10 dev ppp0), consigo acessar dispositivos 192.168.1.0/24.

outro servidor Ubuntu 20.04 lts, ​​para simplificar denominado servidor B com as seguintes interfaces de rede:

  • loopback
  • enp1s0 (wan) PUBLIC-IP/23
  • enp8s0 (lan) 10.9.96.4/20

e esta tabela de roteamento (rotas públicas são omitidas intencionalmente):

  • 10.9.96.0/20 dev enp8s0 proto kernel scope link src 10.9.96.4

Basicamente preciso acessar dispositivos 192.168.1.0/24 do servidor B, mas não consigo fazer funcionar.
Também tentei adicionar uma rota estática: 192.168.1.0/24 via 10.9.96.3 dev enp8s0
dentro deste servidor sem sucesso, vejo pacotes destinados a 192.168.1.X chegando ao servidor A mas eles não são encaminhados para ppp0 interface, eu acho (então tentei também algumas regras do iptables)

Como consertar este problema?

O firewall está desabilitado em ambos os servidores.

Responder1

OBSERVAÇÃO: Nesta resposta, a rede 100.64.10.0/23representa a rede pública. Não é particularmente relevante, mas existe apenas para fazer com que a configuração de rede desses nós virtuais corresponda ao que você descreveu em sua pergunta.

Seu problema é que os hosts da rede 192.168.1.0/24 não sabem como acessar a rede 10.9.96.0/20.

Com base no que você nos mostrou em sua pergunta, a tabela de roteamento no roteador microtik (192.168.42.10/192.168.1.1) provavelmente se parece com isto:

192.168.1.0/24 dev h1-eth0 proto kernel scope link src 192.168.1.1
192.168.42.0/24 dev h1-eth1 proto kernel scope link src 192.168.42.10

E a tabela de roteamento no serverA se parece com:

default via 100.64.10.1 dev serverA-eth0
10.9.96.0/20 dev serverA-eth1 proto kernel scope link src 10.9.96.3
100.64.10.0/23 dev serverA-eth0 proto kernel scope link src 100.64.10.10
192.168.1.0/24 via 192.168.42.10 dev serverA-eth2
192.168.42.0/24 dev serverA-eth2 proto kernel scope link src 192.168.42.1

Em serverA, quando você executa ping em um endereço na 192.168.1.0/24rede, seu endereço de origem é 192.168.42.1. O roteador microtik tem rota para essa rede, então está tudo ótimo.

Se serverBvocê tiver uma tabela de roteamento como esta:

default via 100.64.10.1 dev serverB-eth0
10.9.96.0/20 dev serverB-eth1 proto kernel scope link src 10.9.96.4
100.64.10.0/23 dev serverB-eth0 proto kernel scope link src 100.64.10.20
192.168.1.0/24 via 10.9.96.3 dev serverB-eth1

Então, quando você tentar se conectar a um endereço na 192.168.1.0/24rede, seu endereço de origem será 10.9.96.4. O roteador microtik não sabe como chegar a esse endereço (ou tenta responder através do gateway padrão, o que é inadequado).

A solução é adicionar uma rota ao roteador microtik assim:

ip route add 10.9.96.0/20 via 192.168.42.1

Agora:

  • O ServerB pode executar ping no roteador microtik porque o roteador microtik tem uma rota válida de volta ao serverB
  • ServidorB pode executar pingoutrohosts na 192.168.1.0/24rede porque esses hosts usam o roteador microtik ( 192.168.1.1) como gateway padrão... e conforme estabelecido no ponto anterior, o roteador tem uma rota apropriada.

Testei tudo isso em um ambiente de rede simulado construído usandomini-rede; você pode encontrar a configuraçãoaquise você está curioso.

informação relacionada