Configuração adequada para o Quagga OSPF em uma rede OpenVPN

1

Primeiro, uma versão simples da minha topologia de rede. 

                      [ hub ]
                         |
                      OpenVPN
                         |
10.77.1.0/24--[ base ]---|---[ mr0  ]--10.77.2.0/24
10.77.3.0/24--[ mr1  ]---|---[ mr2  ]--10.77.5.0/24
10.77.5.0/24--[ mr3  ]---| ...

hub é um Ubuntu VPS executando um servidor OpenVPN com um IP público estático. base é um firewall pfSense na minha casa que tem uma localização constante, mas IP variável. Cada um dos mr# nós é um roteador móvel que não possui um endereço IP ou local consistente e pode ou não estar por trás de um firewall NAT adicional. As redes CIDR listadas são supernets diretamente conectadas a seus roteadores.

Para o propósito de ler logs, aqui estão meus IPs, IDs de roteador e sistemas operacionais: 

host  ip           ospf id        os
hub   10.77.0.254  10.77.255.254  ubuntu
base  10.77.0.253  10.77.255.253  pfsense
mr0   10.77.0.252  10.77.255.252  lede
mr1   10.77.0.251  10.77.255.251  pfsense
mr2   10.77.0.250  10.77.255.250  centos
mr3   10.77.0.249  10.77.255.249  vyos

No servidor do hub, tenho client-to-client ativado e muitos routes e iroutes empurrado para os vários clientes. Com essa configuração, posso conectar-me de qualquer nó a qualquer nó (dentro das regras de firewall). Mas, essa configuração não é escalável e eu tenho que reiniciar os clientes e o servidor toda vez que uma rota muda, então estou trabalhando para substituir esta configuração estática pelo Quagga OSPF.

Meu problema parece semelhante ao https://serverfault.com/questions/189739/tough-routing-problem-with-linux-quagga-and-openvpn No entanto, sua solução aceita era tornar tudo estático encaminhado, que é o que estou tentando evitar.

Até agora, tenho roteamento dinâmico trabalhando entre meu roteador Linux ( mr2 ) hube um desktop Linux aleatório que adicionei à VPN para testar 3 roteadores OSPF. Minhas VyOS e Os roteadores LEDE têm problemas por motivos não relacionados a essa questão. (editar: VyOS obras noturnas)

Agora para o enigma:

Meus dois firewalls pfSense (um é base e o outro é mr1 ) tanto spam as mensagens de log semelhantes: 

2017/12/31 13:14:55 OSPF: Packet[DD]: Neighbor 10.77.255.250: Initial DBD from Slave, ignoring.
2017/12/31 13:15:00 OSPF: Packet[DD] [Slave]: Neighbor 10.77.255.254 packet duplicated.
2017/12/31 13:15:00 OSPF: *** sendmsg in ospf_write failed to 10.77.0.254, id 0, off 0, len 72, interface ovpnc1, mtu 1500: Network is unreachable
2017/12/31 13:15:00 OSPF: *** sendmsg in ospf_write failed to 10.77.0.254, id 0, off 0, len 108, interface ovpnc1, mtu 1500: Network is unreachable
2017/12/31 13:15:00 OSPF: Packet[DD]: Neighbor 10.77.255.250: Initial DBD from Slave, ignoring.
2017/12/31 13:15:00 OSPF: *** sendmsg in ospf_write failed to 10.77.0.250, id 0, off 0, len 52, interface ovpnc1, mtu 1500: Network is unreachable
2017/12/31 13:15:05 OSPF: Packet[DD] [Slave]: Neighbor 10.77.255.254 packet duplicated.

Como as caixas pfSense não podem enviar suas respostas OSPF, isso deixa a rede nesse estado: 

hub# sh ip os ne

    Neighbor ID Pri State           Dead Time Address         Interface            RXmtL RqstL DBsmL
10.77.255.250     1 Full/Backup       37.090s 10.77.0.250     tun0:10.77.0.254         0     0     0
10.77.255.251     0 ExStart/DROther   31.661s 10.77.0.251     tun0:10.77.0.254         0     0     0
10.77.255.253     0 ExStart/DROther   31.648s 10.77.0.253     tun0:10.77.0.254         0     0     0

Como não pode enviar nada, o nó pfSense fica preso: 

base# sh ip os ne

Neighbor ID     Pri State           Dead Time Address         Interface            RXmtL RqstL DBsmL
10.77.255.250     1 ExStart/Backup    36.505s 10.77.0.250     ovpnc1:10.77.0.253       0     0     0
10.77.255.251     0 2-Way/DROther     37.276s 10.77.0.251     ovpnc1:10.77.0.253       0     0     0
10.77.255.254     1 Exchange/DR       37.763s 10.77.0.254     ovpnc1:10.77.0.253       1     0     0

Honestamente, não tenho certeza se esse é um problema de configuração do OpenVPN, um problema de configuração do Quagga, um problema de configuração do sistema operacional ou um bug em um ou mais componentes. Quagga parece funcionar bem quando eu uso apenas links de ethernet (como acontece, base, mr1e mr3 estão todos compartilhando uma localização física no momento), então parece que isso é limitado ao uso do OSPF sobre o OpenVPN.

EDIT 2018 JAN 06: Ao longo deste processo, notei que o denominador comum era que cada roteador funcionando era baseado em Linux. Limpando meu netstat resultados pela milionésima vez, descobri que minhas caixas pfSense implementaram o adaptador tun do OpenVPN de maneira diferente: no Linux, o endereço do adaptador tun é configurado com uma máscara de sub-rede, permitindo que os nós conectados à VPN sejam contatados "sem" um hop de roteador. No FreeBSD, o adaptador tun é exposto como o ponto-a-ponto interno (o que é, mesmo no Linux), e uma rota IPv4 é adicionada para o resto da rede. Não consigo lembrar se fiz isso ou aconteceu automaticamente, mas o objetivo que eu acho é agora: a) como faço para que o FreeBSD / pfSense crie um adaptador TUN que se comportaria como o Linux permitindo conexões "diretas", ou b) posso obter o Quagga para permitir que seus pacotes sejam roteados?

pfSense: 

[root@base ~]# ifconfig ovpnc1
ovpnc1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
    options=80000<LINKSTATE>
    inet6 fe80::20c:29ff:feac:faf4%ovpnc1 prefixlen 64 scopeid 0x16
    inet 10.77.0.253 --> 10.77.0.225  netmask 0xffffffe0
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    groups: tun openvpn
    Opened by PID 27659
[root@base ~]# netstat -nr4 | grep -e ovpnc1 -e link#22
10.77.0.224/27     10.77.0.225        UGS      ovpnc1
10.77.0.225        link#22            UH       ovpnc1
10.77.0.253        link#22            UHS         lo0
...
[root@base ~]# ping -r -c 2 10.77.0.254
PING 10.77.0.254 (10.77.0.254): 56 data bytes
ping: sendto: Network is unreachable
ping: sendto: Network is unreachable

--- 10.77.0.254 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss

Linux: 

[root@mr2 ~]# ip a sh dev tun0
18: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none
    inet 10.77.0.250/27 brd 10.77.0.255 scope global tun0
       valid_lft forever preferred_lft forever
[root@nl3-mr2 ~]# ip ro | grep tun0
10.77.0.224/27 dev tun0 proto kernel scope link src 10.77.0.250
...
[root@mr2 ~]# ping -r -c 2 10.77.0.254
PING 10.77.0.254 (10.77.0.254) 56(84) bytes of data.
64 bytes from 10.77.0.254: icmp_seq=1 ttl=64 time=51.1 ms
64 bytes from 10.77.0.254: icmp_seq=2 ttl=64 time=51.2 ms

--- 10.77.0.254 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 51.117/51.199/51.281/0.082 ms

OpenVPN server.conf: 

port 1194
management localhost 1194
proto udp
dev tun

ca ca.crt
cert server.crt
dh dh2048.pem
tls-auth ta.key 0
key-direction 0

auth SHA256
cipher AES-256-CBC

mode server
tls-server
topology subnet
push "topology subnet"
ifconfig 10.77.0.254 255.255.255.224
push "route-gateway 10.77.0.254"
client-to-client
config ccd/routes.conf
push "route 10.77.4.0 255.255.255.0 10.77.0.254 250"
client-config-dir ccd

user nobody
group nogroup

persist-key
persist-tun

status openvpn-status.log

verb 4

Exemplo de arquivo ccd (este é para base ): 

config ccd/routes_push.conf
ifconfig-push 10.77.0.253 255.255.255.224
iroute 10.77.1.0 255.255.255.0

ccd / routes.conf: 

route 10.77.1.0 255.255.255.0 10.77.0.253 250
route 10.77.2.0 255.255.255.0 10.77.0.252 250
route 10.77.3.0 255.255.255.0 10.77.0.251 250
route 10.77.5.0 255.255.255.0 10.77.0.250 250
route 10.77.6.0 255.255.255.0 10.77.0.249 250

ccd / routes_push.conf: 

push "route 10.77.1.0 255.255.255.0 10.77.0.253 250"
push "route 10.77.2.0 255.255.255.0 10.77.0.252 250"
push "route 10.77.3.0 255.255.255.0 10.77.0.251 250"
push "route 10.77.5.0 255.255.255.0 10.77.0.250 250"
push "route 10.77.6.0 255.255.255.0 10.77.0.249 250"

Configuração de execução abreviada em hub: 

...
!
service advanced-vty
service password-encryption
!
debug ospf event
!
...
!
interface tun0
 description grandcentral-hub
 ip ospf network broadcast
 ipv6 nd suppress-ra
 no link-detect
!
router ospf
 ospf router-id 10.77.255.254
 log-adjacency-changes
 network 10.77.0.224/27 area 0.0.0.0
 network 10.77.4.0/24 area 0.0.0.0
 network 172.17.0.0/16 area 0.0.0.0
 area 0.0.0.0 range 10.77.4.0/24
!
ip forwarding
ipv6 forwarding
!
line vty
!
end

Configuração de execução abreviada em base, conforme gerado pelo pfSense: 

...
!
interface ovpnc1
 ip ospf network broadcast
 ip ospf priority 0
!
...
!
router ospf
 ospf router-id 10.77.255.253
 log-adjacency-changes detail
 passive-interface em0.1
 network 10.77.0.224/27 area 0.0.0.0
 network 10.77.1.0/27 area 0.0.0.0
 network 10.77.1.192/26 area 0.0.0.0
 network 192.168.254.0/24 area 0.0.0.0
!
ip forwarding
ipv6 forwarding
!
line vty
!
end
linux  networking  vpn  openvpn  pfsense 
— computergeek125
fonte

Respostas:

0

EDIT 20 de janeiro de 2018 17:57 CST: as grawity salientou (muito obrigado), apenas usando dispositivos de toque em vez de tun corre tudo. Deveria ter pensado nisso antes.

Dito isto, ainda estou procurando uma solução com tun para ver se é possível. Eu não sei se ~ 20 bytes ímpares do cabeçalho Ethernet podem realmente importar para um link DSL, e com certeza o registro é mais opaco desde que todos os MULTI: Learn: as entradas são agora endereços MAC virtuais em vez de endereços IP.

Parece que o que estou tentando fazer não é possível diretamente com o tun. O OpenVPN é uma interface ponto-a-ponto por natureza, e a implementação do OpenVPN / TUN no Linux permite que a comunicação cliente-cliente fique escondida dentro da pilha de rede.

Por outro lado, o FreeBSD expõe a interface ponto-a-ponto e instala uma rota para tratar cliente-cliente (testado em um FreeBSD 11.1-RELEASE limpo).

Além disso, quando você altera o endereço IP interno de um servidor OpenVPN, ele ainda atribui o endereço IP padrão (menor IP disponível no intervalo) a interfaces ponto a ponto.

Então, para consertar isso, terei que reimplementar tudo como um sistema ponto-a-multiponto (aprendendo coisas novas). Eu atualizarei esta resposta quando eu conseguir.

— computergeek125
fonte
1
Talvez você deva usar o modo de toque?
— grawity
Eu definitivamente deveria ter pensado nisso antes * facepalm * . Eu preferiria usar tun e não ter que encapsular os cabeçalhos extras de ethernet, mas isso funciona por enquanto.
— computergeek125
1
Talvez seja necessário configurar a interface como uma interface de não difusão do OSPF. Muitos túneis não suportam multicast, que é o que o OSPF tentará usar em uma rede de transmissão. Isso significa que o OSPF precisará ser configurado com uma instrução vizinha.
— Ron Maupin
Isso funciona desde que você não altere o endereço IP do servidor VPN e não precise formar uma adjacência com outro roteador que não seja o hub VPN. Infelizmente, como não é um multicast que está quebrado no tun do FreeBSD (o Unicast é o mais estranho), você ainda OSPF: *** sendmsg in ospf_write failed to 10.77.0.254, id 0, off 0, len 72, interface tun0, mtu 1500: Network is unreachable
— computergeek125
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.