O Raspberry PI é conectado ao servidor OpenVPN via conexão TAP. O toque do PI é preenchido com a interface ethernet do PI.
Quando o cliente em questão se conecta à porta ethernet do pi, o isc-dhcp-server no servidor OpenVPN é imediatamente consultado e atribui um endereço IP. O cliente pega o endereço IP sem nenhum problema. No entanto, ele não tem absolutamente nenhum 'gateway padrão via ...' em sua tabela de rotas. Se eu adicionar manualmente a rota inserindo:
ip route add default via 10.70.0.1 def eth0
Então o cliente funciona perfeitamente.
Lembre-se de que essa não é uma conexão VPN TUN tradicional. Esta é uma conexão TAP e o cliente VPN é o PI Raspberry que está entre o cliente e o servidor. Então, nenhuma rota empurrando ou gateway empurrando pelo OpenVPN joga em nada disso.
PI quando conectado ao servidor OpenVPN:
root@pi-test:~# ip addr show br0
5: br0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 96:d5:0f:08:f3:30 brd ff:ff:ff:ff:ff:ff
inet 10.70.0.201/24 brd 10.70.0.255 scope global br0
valid_lft forever preferred_lft forever
inet6 2600:xxxx:xxxx:xxxx:94d5:fff:fe08:f330/64 scope global mngtmpaddr dynamic
valid_lft 86200sec preferred_lft 14200sec
inet6 fe80::94d5:fff:fe08:f330/64 scope link
valid_lft forever preferred_lft forever
root@pi-test:~# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.96d50f08f330 no eth0
tap0
Cliente quando conectado ao PI:
me@client:~$ ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:12:3f:82:92:38 brd ff:ff:ff:ff:ff:ff
inet 10.70.0.105/24 brd 10.70.0.255 scope global dynamic noprefixroute eth0
valid_lft 31065sec preferred_lft 31065sec
inet6 2600:xxxx:xxxx:xxxx:c040:ebd3:1619:57b1/64 scope global temporary dynamic
valid_lft 86066sec preferred_lft 14066sec
inet6 2600:xxxx:xxxx:xxxx:d7f9:41bf:a910:9b43/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 86066sec preferred_lft 14066sec
inet6 fe80::cfce:6b01:c5d4:ced6/64 scope link noprefixroute
valid_lft forever preferred_lft forever
me@client:~$ ip route
default via 10.70.0.1 dev eth0 (this line is missing)
10.70.0.0/24 dev eth0 proto kernel scope link src 10.70.0.105 metric 100
Note também que os RA's para IPv6 estão funcionando perfeitamente (assim é o roteamento). Apenas jogando isso aqui como mais uma prova de que as pontes estão funcionando como esperado. Esses endereços IPv6 fazem parte do bloco roteado IPv6 do servidor. Esse endereço 8723 abaixo é o endereço LL IPv6 do servidor conforme o esperado.
me@client:~$ ip -6 route
2600:xxxx:xxxx:xxxx::/64 dev eth0 proto ra metric 100 pref medium
fe80::/64 dev eth0 proto kernel metric 100 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::d8ae:1bff:fe1f:8723 dev eth0 proto ra metric 100 pref medium
O cliente funciona como esperado quando conectado a outro roteador. Obtém o seu endereço IP E o 'default via'. Minha expectativa é que, uma vez que a ponte tenha sido construída entre o Servidor e o Cliente, ela deva se comportar como se tudo estivesse fisicamente conectado. E quase isso acontece. Nenhum roteamento deve funcionar nessa equação, mas se alguém perguntar, o iptables está no modo Accept All até que eu consiga descobrir isso.
Servidor DHCP (usei essa mesma configuração muitas vezes sem problemas):
root@server:~# cat /etc/dhcp/dhcpd.conf
option domain-name "local.net";
option domain-name-servers 10.70.0.1;
ddns-update-style none;
subnet 10.70.0.0 netmask 255.255.255.0 {
range 10.70.0.100 10.70.0.199;
option routers 10.70.0.1;
}
host pi-router1 {
hardware ethernet 96:d5:0f:08:f3:30;
fixed-address 10.70.0.201;
}