☰

Сервер OpenVPN не может пинговать клиентов

tag-icon • tag-icon routing openvpn
Сервер OpenVPN не может пинговать клиентов

У меня настроен OpenVPN на сервере Debian. Клиенты могут подключаться, а также могут пинговать и получать доступ к ресурсам (общие ресурсы Samba и интрасеть) на сервере.

Однако сервер не может выполнить пинг клиента — время ожидания истекло.

Диаграмма

Client OpenVPN assigned IP: 10.67.15.26
   ↓ UDP on 1194
Internet
   ↓
Router port-forwards 1194 to server
   ↓ 
Server LAN IP: 10.67.5.1

Конфигурация сервера OpenVPN (соответствующие биты)

port 1194
proto udp
dev tun
server 10.67.15.0 255.255.255.0
push "route 10.67.5.0 255.255.255.0"

Таблица маршрутизации сервера

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.67.15.2      0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.67.15.0      10.67.15.2      255.255.255.0   UG    0      0        0 tun0
10.67.5.0       0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         10.67.5.254     0.0.0.0         UG    0      0        0 eth1

Серверный брандмауэр

Я временно отключил брандмауэр сервера, все политики цепочек установлены на ACCEPT и все флаги пересылки установлены:

1 : /proc/sys/net/ipv4/conf/all/forwarding
1 : /proc/sys/net/ipv4/conf/default/forwarding
1 : /proc/sys/net/ipv4/conf/lo/forwarding
1 : /proc/sys/net/ipv4/conf/eth1/forwarding
1 : /proc/sys/net/ipv4/conf/tun0/forwarding
1 : /proc/sys/net/ipv4/ip_forward

Тестовые случаи:

клиент: ping 10.67.5.1работает, как и другие ресурсы.

сервер: ping 10.67.15.26время ожидания истекло.

решение1

Сравнив двух разных клиентов, мне удалось выявить и устранить две проблемы.

Проблема 1: маршрутизация

По какой-то причине (и я не уверен, что решил ее) таблица маршрутизации сервера постоянно забывала маршрут в/из его LAN (10.67.5.0/24). Это приводило к тому, что весь исходящий трафик LAN проходил через его основной шлюз, который не направлялся в OpenVPN LAN (10.67.15.0/24). Это приводило к тому, что трафик из сети OpenVPN, предназначенный для LAN, терпел неудачу на основном шлюзе; таким образом, пинги отправлялись, но ответ терялся.

Редактировать:К сожалению, я не знаю, что вызвало отбрасывание этого маршрута; как вы можете видеть, это было в таблице маршрутизации выше. Я попытался добавить команду маршрутизации в /etc/network/interfaces, но затем у меня получилось два дублирующихся, идентичных маршрута, поэтому я снова удалил ее.Это был мойfwbuilderконфигурация, которая приводила к отключению этого маршрута: при настройке адаптера eth1 я указал сетевую маску /32 (т.е. хост) вместо /24 (для локальной сети).

Протестировав клиент Debian, мне удалось разобраться с этим, после этого он заработал, а вот клиент Windows 7 — нет.

Проблема 2: Брандмауэр/конфигурация Windows 7

При установке Windows возникло две проблемы.

В Windows для адаптера TAP должен быть установлен частный профиль «Работа».

За этот раздел спасибо kalwi

Обновление от 2020-06-11

Вы можете сделать интерфейс закрытым, используя следующие две команды PowerShell:

# this first one will let you see the available connections, 
# find the interface index of the one you would like to change
Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceIndex NN -NetworkCategory Private

В «Центре управления сетями и общим доступом» вы должны увидеть (как минимум) 2 «активные сети». У меня была беспроводная сеть, а затем «Неопознанная сеть». Последняя — это устройство OpenVPN TAP, и у него был значок скамейки в парке, что означало, что оно рассматривалось как общедоступное, недоверенное. Чтобы иметь возможность изменить это, вам нужно добавить шлюз по умолчанию для адаптера.

Запустите терминал DOS/Cygwinкак администратор. (Запустите Orb > найдите CMD > щелкните правой кнопкой мыши > запустите от имени администратора).

Затем выполните route print -4. Вы увидите список интерфейсов. Каждая строка начинается с номера, а справа вы увидите имя. Определите номер интерфейса для адаптера TAP-Win32. У меня был 17.

Теперь добавьте маршрут:

route -p add 0.0.0.0 mask 0.0.0.0 1.2.3.4 metric 500 if 17

Где 1.2.3.4 должен быть IP вашего шлюза OpenVPN (отображается в столбце Gateway в выводе предыдущей команды), а 17 должен быть номером вашего интерфейса TAP. Эта -pопция делает маршрут постоянным. Сначала я сделал это без этого, чтобы проверить.Это предполагает, что IP-адрес шлюза OpenVPN клиента не будет меняться между подключениями..

После того, как вы это сделаете, должно появиться диалоговое окно с просьбой классифицировать новую сеть. ВыберитеРабота.

На этом этапе мне удалось отправить трафик из локальной сети моей компании к клиенту (проверено с помощью netcat), однако пинги по-прежнему оставались без ответа.

Сообщите Windows, что нужно разрешить пинги (ICMPv4)

Запустите Orb > Брандмауэр Windows в режиме повышенной безопасности. Затем перейдите в раздел «Правила для входящих подключений» и «Новое правило».

  • Пользовательское правило
  • Все программы
  • Протокол: ICMPv4
  • Разрешить подключение
  • Применить к личному профилю
  • Назови это.

Наконец, пинги вернулись.

Связанный контент