Parece que eu estava correto no meu design e no bom caminho. Agora estou respondendo a minha própria pergunta tanto para compartilhar conhecimento e publicar meus pensamentos, pesquisas e considerações para referência em futuras perguntas.
Graças a este post , encontrei a maioria das respostas às minhas perguntas. Então deixe-me resumir:
- O OpenVpn tem configuração para redes locais de peering
Our user had a openvpn server with a lan (10.10.2.0/24) behind it, and 2 client with lans behind them:
client1 with lan 10.10.1.0/24 client2 with lan 10.10.3.0/24
He wanted machines on all 3 lans to be able to communicate using a tun (routed) setup.
Every machine with a LAN behind it must have IP forwarding enabled. In this example that means the server, and client1/client2. The user needed the following in his server.conf:
route 10.10.1.0 255.255.255.0
route 10.10.3.0 255.255.255.0
push "route 10.10.2.0 255.255.255.0"
push "route 10.10.1.0 255.255.255.0"
push "route 10.10.3.0 255.255.255.0"
client-to-client
Basta adaptar-se ao meu caso: o servidor tem de route apenas as redes que não controla e push all. Não é tão inteligente empurrar dinamicamente todas as LANs que se conectam a ele. Não é um problema porque não estou implementando uma configuração escalável e tenho apenas duas LANs
- O OpenVpn cuida do roteamento no Raspberry em execução.
Eu fiz um exemplo dentro da minha própria lan no site B. Eu atribuí um endereço IP de Um a Raspberry A, deixe-a tomar um endereço DHCP de B na mesma interface eth0 e, em seguida, execute o OpenVpn e um servidor de eco. Em seguida, conectei o Raspberry A, que tinha seu endereço IP de rede B, ao endereço do Raspberry A em B LAN.
Finalmente, eu poderia ecoar e assistir nos logs. A ressalva era que o Raspberry A (servidor de eco) via a conexão de um IP em um intervalo e não em B, portanto as LANs não estavam se comunicando.
- As rotas devem ser definidas no gateway, aparentemente. O artigo explica bem. Deixe-me citar
Lets say our server is 10.10.2.10 on its lan, and uses 10.10.2.1 as its default route, and you want the 2.x lan to be accessible or able to access over the vpn. 2.1 would need a route for every network that 2.x will access or be accessed by. That means in our example: 10.10.2.1 must know that for 10.10.1.x 10.10.3.x and the vpn internal network (for example, 10.8.0.x), it sends the traffic to 10.10.2.10 This is true for any number of lans you want to connect, whether server or client.
If you fail to add this route, here is what would happen if a VPN client (for example, 10.8.0.6) wanted to send traffic to 10.10.2.20:
The vpn client sends traffic to 10.10.2.20, with a source address of 10.8.0.6 The vpn server (10.8.0.1 and 10.10.2.10) receives the traffic, has IP forwarding enabled, and passes the traffic to 10.10.2.20 10.10.2.20 gets it and tries to respond to 10.8.0.6 but has no entry in its routing table Because 10.10.2.20 has no route for 10.8.0.6, it sends the traffic to its default gateway which is 10.10.2.1 10.10.2.1 checks its routing table, has no route for 10.8.0.6, and sends the traffic to its default gateway which is likely its ISP The ISP ignores it, because it is a RFC 1918 ip (aka lan only)
Como eu tenho controle sobre os dois gateways, definir uma rota estática foi a maneira correta