Raspberry PI는 TAP 연결을 통해 OpenVPN 서버에 연결됩니다. PI의 탭은 PI의 이더넷 인터페이스와 연결됩니다.
해당 클라이언트가 pi의 이더넷 포트에 연결하면 OpenVPN 서버의 isc-dhcp-server가 즉시 폴링되고 IP 주소가 할당됩니다. 클라이언트는 아무런 문제없이 IP 주소를 사용합니다. 그러나, 그는 자신의 경로 테이블에 'via via default gateway ...'를 절대 가지고 있지 않습니다. 다음을 입력하여 수동으로 경로를 추가하는 경우 :
ip route add default via 10.70.0.1 def eth0
그러면 클라이언트가 완벽하게 작동합니다.
이것은 기존의 TUN VPN 연결이 아닙니다. 이것은 TAP 연결이며 VPN 클라이언트는 클라이언트와 서버 사이에있는 Raspberry PI입니다. 따라서 OpenVPN에 의한 라우트 푸시 (pushing) 또는 게이트웨이 푸시 (gateway pushing)는 전혀 없습니다.
PI가 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
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
또한 IPv6에 대한 RA는 완벽하게 작동합니다 (라우팅도 마찬가지입니다). 교량이 예상대로 작동하고 있음을 보여주는 또 다른 증거로이를 던지면됩니다. 이러한 IPv6 주소는 모두 서버의 IPv6 라우팅 블록의 일부입니다. 아래의 8723 주소는 예상대로 서버의 IPv6 LL 주소입니다.
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
클라이언트가 다른 라우터에 연결되면 예상대로 작동합니다. 그것은 그것의 IP 주소와 'default via'를 얻습니다. 내 기대는 브리지가 서버와 클라이언트 사이에 구축되면 물리적으로 모든 것이 연결되어있는 것처럼 동작해야한다는 것입니다. 그리고 거의 그것을합니다. 이 방정식은 라우팅이 필요하지 않습니다. 그러나 iptables는 내가 알아낼 때까지 모두 허용 모드입니다.
DHCP 서버 (이 동일한 구성을 문제없이 여러 번 사용했습니다) :
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;
}