Вопрос или проблема
Мой сын настроил сервер OpenVPN на своем маршрутизаторе NetGear в Великобритании. Я нахожусь в Италии и у меня есть клиент OpenVPN, который хорошо работает на Windows, но я хочу подключаться также с моего Raspberry Pi и ноутбука на Ubuntu. Я следовал всем инструкциям по установке клиента OpenVPN, но ни одна из версий для Linux не подключается. Версия OpenVPN, установленная на Raspberry Pi, — 2.6.3-1+deb12u2. Сейчас я сосредоточусь на версии для Raspberry Pi, поскольку проблемы, похоже, схожи в обоих случаях, и, возможно, решение одной из них подскажет, как решить другую. Raspberry Pi — это модель 5, которая работает на Debian GNU/Linux 12 (bookworm). Файл Client.conf выглядит следующим образом:
client
#dev tap
dev tun
proto udp
remote beerisgood.ddns.net 12974
resolv-retry infinite
nobind
persist-key
persist-tun
persist-remote-ip
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
cipher AES-128-CBC
# data-ciphers-fallback AES-128-CBC
comp-lzo
# route-noexec ## added JKJ 17/2/25
verb 3
log /etc/openvpn/log/jrjvpn.log
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
Запуск клиента OpenVPN генерирует следующий файл журнала:
2025-02-19 18:58:07 DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations.
2025-02-19 18:58:07 Note: '--allow-compression' is not set to 'no', disabling data channel offload.
2025-02-19 18:58:07 OpenVPN 2.6.3 aarch64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
2025-02-19 18:58:07 library versions: OpenSSL 3.0.15 3 Sep 2024, LZO 2.10
2025-02-19 18:58:07 DCO version: N/A
2025-02-19 18:58:07 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
2025-02-19 18:58:08 TCP/UDP: Preserving recently used remote address: [AF_INET]213.18.141.7:12974
2025-02-19 18:58:08 Socket Buffers: R=[212992->212992] S=[212992->212992]
2025-02-19 18:58:08 UDPv4 link local: (not bound)
2025-02-19 18:58:08 UDPv4 link remote: [AF_INET]213.18.141.7:12974
2025-02-19 18:58:08 TLS: Initial packet from [AF_INET]213.18.141.7:12974, sid=2f04db75 d6626407
2025-02-19 18:58:08 VERIFY OK: depth=1, C=TW, ST=TW, L=Taipei, O=netgear, OU=netgear, CN=netgear CA, name=EasyRSA, emailAddress=mail@netgear
2025-02-19 18:58:08 VERIFY OK: depth=0, C=TW, ST=TW, L=Taipei, O=netgear, OU=netgear, CN=server, name=EasyRSA, emailAddress=mail@netgear
2025-02-19 18:58:08 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, peer certificate: 1024 bit RSA, signature: RSA-SHA256
2025-02-19 18:58:08 [server] Peer Connection Initiated with [AF_INET]213.18.141.7:12974
2025-02-19 18:58:08 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2025-02-19 18:58:08 TLS: tls_multi_process: initial untrusted session promoted to trusted
2025-02-19 18:58:09 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
2025-02-19 18:58:09 PUSH: Received control message: 'PUSH_REPLY,ping 10,ping-restart 120,route-delay 10,route-gateway 192.168.1.1,redirect-gateway def1,peer-id 0,cipher AES-256-GCM'
2025-02-19 18:58:09 OPTIONS IMPORT: route options modified
2025-02-19 18:58:09 OPTIONS IMPORT: route-related options modified
2025-02-19 18:58:09 net_route_v4_best_gw query: dst 0.0.0.0
2025-02-19 18:58:09 net_route_v4_best_gw result: via 192.168.178.1 dev wlan0
2025-02-19 18:58:09 ROUTE_GATEWAY 192.168.178.1/255.255.255.0 IFACE=wlan0 HWADDR=2c:cf:67:5e:8e:04
2025-02-19 18:58:09 TUN/TAP device tun0 opened
2025-02-19 18:58:09 Data Channel: cipher 'AES-256-GCM', peer-id: 0, compression: 'lzo'
2025-02-19 18:58:09 Timers: ping 10, ping-restart 120
2025-02-19 18:58:19 net_route_v4_add: 213.18.141.7/32 via 192.168.178.1 dev [NULL] table 0 metric -1
2025-02-19 18:58:19 net_route_v4_add: 0.0.0.0/1 via 192.168.1.1 dev [NULL] table 0 metric -1
2025-02-19 18:58:19 sitnl_send: rtnl: generic error (-101): Network is unreachable
2025-02-19 18:58:19 ERROR: Linux route add command failed
2025-02-19 18:58:19 net_route_v4_add: 128.0.0.0/1 via 192.168.1.1 dev [NULL] table 0 metric -1
2025-02-19 18:58:19 sitnl_send: rtnl: generic error (-101): Network is unreachable
2025-02-19 18:58:19 ERROR: Linux route add command failed
2025-02-19 18:58:19 Initialization Sequence Completed
Как вы можете видеть, происходит ошибка выполнения команды route add. Скрипт для Windows, который работает, использует dev tap, но я изменил его на dev tun в надежде, что это решит ошибку, но это не принесло никакой разницы. Запуск ip a до и после запуска клиента показывает следующее различие после запуска OpenVPN:
17: tun0: <POINTOPOINT,MULTICAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 500
link/none
Вызовы скриптов up и down для update-resolv-conf были предложены как дополнения в инструкциях по установке, но они не повлияли на ситуацию, поэтому я закомментировал их для генерации приведенного выше файла журнала. Насколько я могу понять из скриптов, они используют переменные окружения, которые могут передаваться с сервера и использоваться для изменения таблиц маршрутизации, но ничего не передается с сервера, поэтому их наличие или отсутствие не имеет значения.
Одна из тем, которую я прочитал, предположила, что нужна утилита resolvconf, поэтому я установил и ее, но это тоже не помогло. Запуск утилиты до и после запуска OpenVPN дает следующий результат:
$ sudo resolvconf -l
# resolv.conf from NetworkManager
search fritz.box
nameserver 192.168.178.1
nameserver fd00::de39:6fff:feec:40a6
Еще одна вещь, которую я попробовал, это добавление route-noexec в файл конфигурации (закомментировано выше). Это устранило ошибки, но не решило проблему неработающего VPN, поэтому я решил, что лучше видеть ошибки. Сравнение файлов журналов с этой командой и без нее показало, что они идентичны до момента 2025-02-19 18:58:09 Timers: ping 10, ping-restart 120 в приведенном выше журнале, но затем остаток журнала пуст до Initialization Sequence Completed.
Вопрос: как заставить это работать?
Спасибо @tink и @StephenHarris за ваши очень быстрые ответы.
Ничего не изменяя на сервере, клиент VPN теперь работает на Raspberry Pi и также на Ubuntu. Проблема оказалась в том, что TUN использует порт 12973, тогда как TAP использует 12974. Переключившись на порт 12973, ошибки исчезли.
Мой сын обнаружил, что VPN NetGear очень ограничен, и он может настроить очень мало, так что невозможно устранить некоторые предупреждения, которые записываются клиентом, такие как проверка сертификатов. Он изучает возможность перейти на Raspberry Pi и использовать WireGuard.
Эта проблема заняла много времени для решения, послав меня в множество тупиковых путей. Должны быть лучшие способы отладки таких проблем.
Ответ или решение
Решение задачи подключения клиента OpenVPN к серверу OpenVPN, установленному на маршрутизаторе NetGear, требует тщательного подхода. Рассмотрим все аспекты проблемы, чтобы понять, как можно исправить возникшую ситуацию и добиться устойчивой работы VPN-соединения.
Теория
OpenVPN — это программное обеспечение для создания виртуальных частных сетей с использованием шифрования для поддержки конфиденциальности и защиты данных в сети. Основные элементы установки OpenVPN включают клиентскую и серверную части, а также необходимые конфигурационные файлы и сертификаты. Полноценное функционирование сети зависит от правильной настройки и совместимости данных компонентов.
В вашем случае проблемой могла стать неправильно настроенная конфигурация клиента OpenVPN на Raspberry Pi и Ubuntu. Также следует учитывать особенности маршрутизаторов NetGear, которые могут ограничивать некоторые параметры конфигурации в сравнении с более гибкими решениями, например, собственной сборкой на Raspberry Pi.
Пример
Исходя из предоставленной конфигурации и логов, давайте детально рассмотрим возможные причины и шаги по решению проблемы:
-
Конфигурация порта и устройства: Замена
dev tapнаdev tunи смена порта с 12974 на 12973, как выяснилось, оказалась ключевым моментом. TAP и TUN используют разные порты, что важно учитывать. -
Шифрование и компрессия: В логе упоминается о необходимости настроить
--data-ciphersвместо устаревшего параметра--cipher. Это важно, так как неправильные настройки шифрования могут привести к отказу в соединении. -
Маршруты и туннели: Ошибка, связанная с
route add, может указывать на проблему с маршрутами, которые сервер OpenVPN пытается передать клиенту. Если устройство TUN не открылось корректно, это может возникать из-за неверных маршрутов. -
Результат выполнения скриптов: Замечено, что скрипты
upиdown, связанные сupdate-resolv-conf, не влияют на проблему. Однако важно убедиться, что они правильно настроены и применяются в нужное время. Это может быть критично для обновления DNS и конфигурации маршрутизации.
Применение
Учитывая вышеописанные данные, чтобы успешно настроить OpenVPN клиент на Raspberry Pi:
-
Правильная настройка порта: Убедитесь, что используете правильный порт. Как выяснилось, 12973 является правильным для конфигурации TUN.
-
Обновите параметры шифрования: Замените устаревший параметр
--cipherна--data-ciphers, указав поддерживаемые шифры. Это необходимо для обеспечения совместимости с сервером. -
Проверьте устройство TUN: Убедитесь, что устройство TUN правильно конфигурируется и доступно в системе. Команда
ip aдолжна отобразить его как активное и поднятое устройство. -
Устраните маршрутизационные ошибки: Проверьте настройки маршрутизации, используя команды
ip routeиsudo resolvconf -l, чтобы убедиться, что VPN-туннель получает и использует корректные маршруты. -
Отладка и логи: Сохраняйте подробные логи для анализа, используя
verb 3или более высокий уровень. Это поможет диагностировать этап, на котором происходит сбой. -
Сертификационная валидация: Хотя сервер NetGear ограничен в настройках, рекомендуем использовать доступные средства, чтобы убедиться в безопасности соединений.
После выполнения этих шагов клиент на Raspberry Pi должен подключаться без ошибок. В дальнейшем рассматривайте переход на более гибкие VPN-решения, такие как WireGuard, для упрощения управления и повышения безопасности.