1

Raspberry PI подключается к серверу OpenVPN через соединение TAP. Отвод ПИ соединен с Ethernet-интерфейсом ПИ.

Когда рассматриваемый клиент подключается к порту Ethernet pi, isc-dhcp-server на сервере OpenVPN немедленно получает опрос и назначает IP-адрес. Клиент берет IP-адрес без каких-либо проблем. Тем не менее, он не имеет абсолютно никакого «шлюза по умолчанию через ...» в своей таблице маршрутов. Если я вручную добавлю маршрут, введя:

ip route add default via 10.70.0.1 def eth0

Тогда клиент работает отлично.

Имейте в виду, что это не традиционное соединение TUN VPN. Это соединение TAP, а VPN-клиент - это Raspberry PI, который находится между клиентом и сервером. Таким образом, ни перетаскивание маршрутов, ни проталкивание шлюзов OpenVPN ни на что не влияет.

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

Также обратите внимание, что RA для IPv6 работают отлично (как и маршрутизация). Просто добавьте это в качестве еще одного доказательства того, что мосты работают как положено. Все эти адреса IPv6 являются частью маршрутизируемого блока IPv6 Сервера. Этот 8723-адрес, указанный ниже, является ожидаемым LL-адресом сервера IPv6.

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-адрес и «по умолчанию через». Я ожидаю, что после того, как будет построен мост между Сервером и Клиентом, он должен вести себя так, как будто все физически связано. И это почти так. Никакая маршрутизация не должна играть в это уравнение, но если кто-нибудь спросит, iptables находится в режиме Accept All, пока я не выясню это.

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;
}

1 ответ1

1

Проблема заключается в том, что Linux, кажется, удаляет шлюз ["(4)Routers" в dhcpdump] в ответе DHCP. OpenVPN документирует это следующим образом:

Если --server-bridge используется без каких-либо параметров, он включит режим DHCP-прокси, где подключающиеся клиенты OpenVPN получат IP-адрес для своего адаптера TAP от сервера DHCP, работающего в локальной сети на стороне сервера OpenVPN. Обратите внимание, что только клиенты, которые поддерживают связывание клиента DHCP с адаптером TAP (например, Windows), могут поддерживать этот режим. Необязательный флаг nogw (расширенный) указывает, что информация шлюза не должна передаваться клиенту.

Итак, использование nogw никак не повлияло на pi - как и ожидалось, поскольку это Linux. Но когда я подключаю компьютер (любой тип клиента: Linux или Windows) к Ethernet-порту pi, ему фактически назначается шлюз. Другими словами, ответ DHCP от сервера TAP делает его неотредактированным для клиентов на другой стороне пи, а не самого пи. Эта последняя часть отлично подходит, так как у нее есть собственные скрипты конфигурации и так далее.

Суть и результат: любые клиенты общего назначения могут подключаться к pi в качестве маршрутизатора, который надежно подключен к VPN-серверу, и им всем будут назначены IP-адреса (как v4, так и v6) с VPN-сервера на другом конце Тап без проблем.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .