Прошу прощения, если об этом спрашивали в другом месте, но я не смог найти решение после нескольких дней копаний и экспериментов.
У меня есть сервер OpenVPN, работающий на Linux за выделенным брандмауэром, и я пытаюсь создать туннель в сегмент локальной сети за Raspberry Pi для доступа к некоторым контроллерам lantronix.
Проблема, с которой я сталкиваюсь, заключается в том, что я могу установить полную двустороннюю связь с устройствами, подключенными к порту Ethernet на Pi.
Вот мой конфиг openvpn server:
local 127.0.0.1
port 17396
proto tcp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DOMAIN highmark.local"
push "dhcp-option DNS 192.168.10.202"
push "dhcp-option DNS 10.1.10.1"
push "dhcp-option DNS 1.1.1.1"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
client-config-dir /etc/openvpn/server/ccd
route 172.16.3.0 255.255.255.0
;route 192.168.10.0 255.255.255.0 10.8.0.1
client-to-client
push "route 172.16.3.0 255.255.255.0 172.16.3.1"
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn/openvpn-server.log
log-append /var/log/openvpn/openvpn-server-connection.log
verb 6
crl-verify crl.pem
Вот что находится в файле, который находится в каталоге ccd:
iroute 172.16.3.0 255.255.255.0
Вот соответствующие биты файла конфигурации клиента:
client
dev tun
proto tcp
remote ******************** 17396
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
ignore-unknown-option block-outside-dns
block-outside-dns
verb 6
Общие замечания:
Подсеть сервера настроена так:
Server Subnet: 192.168.10.201/24 gw 192.168.10.254
OpenVPN Server: 10.8.0.1/24 gw 0.0.0.0
OpenVPN Client: 10.8.0.2/24 gw 0.0.0.0
Client Subnet: 172.16.3.1/24 gw 0.0.0.0
Вот таблица маршрутизации сервера с установленным подключением к Pi:
Destination Gateway Genmask Flags Metric Ref Use Iface
default _gateway 0.0.0.0 UG 0 0 0 eno1
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
172.16.3.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
192.168.10.0 ubuntu1 255.255.255.0 UG 0 0 0 eno1
Вот таблица маршрутизации клиента с установленным vpn-соединением:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.8.0.1 128.0.0.0 UG 0 0 0 tun0
default DD-WRT 0.0.0.0 UG 303 0 0 wlan0
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
*************** DD-WRT 255.255.255.255 UGH 0 0 0 wlan0
128.0.0.0 10.8.0.1 128.0.0.0 UG 0 0 0 tun0
link-local 0.0.0.0 255.255.0.0 U 300 0 0 eth0
172.16.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 303 0 0 wlan0
В качестве примечания, я не могу понять, откуда / почему этот маршрут 128.0.0.0 сгенерирован - он появляется как часть подключаемого туннеля, а затем, как и другие подключения tun0, выпадает.
Я убедился, что ip-переадресация работает на обоих.
У меня есть полный доступ в Интернет на Pi через VPN, но что-то подключенное как 172.16.3.5/24 gw 172.16.3.1 может видеть Интернет. Адрес .5 может пинговать в подсеть 192.168.10.0/24, но адреса из 192.168.10.0/24 могут пинговать адрес 172.16.3.1, но не могут пинговать адрес .5. Посмотрев на tcpdump, я вижу, что эхо-запросы попадают в 172.16.3.1, но я не вижу ответа. Я проверил, что пи может нормально пинговать 0,5.
Сначала я подумал, что это может быть проблема NAT между интерфейсами Pi, но я очистил все правила iptables в качестве теста, но безуспешно. Мне кажется, что это проблема маршрутизации, но я не могу понять, в чем проблема.
Спасибо заранее за любую помощь.
ОБНОВИТЬ Хорошо, я идиот и обнаружил, что машина Windows, которую я подключал к пи для тестирования, видела соединение как общедоступную сеть. Однако я все еще не подключаюсь к Интернету через Ethernet.