Вопрос или проблема
Пожалуйста, помогите с другим вопросом по openvpn.
Я пытаюсь подключиться с сервера (на котором работает openvpn как сервер) к частному LAN-устройству дома. Частное LAN-устройство получает свой IP/шлюз от DHCP локально (dnsmasq). Топология выглядит так:
Домашнее устройство <-> VPN-клиент/DHCP Raspberry PI <-> VPN-сервер в интернете
192.168.1.134 tun0 10.8.0.2 tun0 10.8.0.1
eth0 192.168.1.99 eth0 <публичный IP>
wlan0 <моя домашняя сеть>
Домашнее устройство и raspberry pi напрямую подключены с помощью ethernet-кабеля – raspberry получает доступ в интернет через wlan0
Что работает?
- raspberry PI правильно выдает 192.168.1.134
- с домашнего устройства PING И SSH на 10.8.0.1
- Raspberry PI может SSH и PING все (192.168.1.134, 10.8.0.1)
- с VPN-сервера SSH и PING raspberry PI (10.8.0.2)
Не работает
- с VPN-сервера PING 192.168.1.x (оба IP)
Итак: трафик идет и возвращается из частного LAN к VPN-серверу. Трафик от VPN-сервера к VPN-клиенту также работает. tcpdump (на vpn-клиенте) это подтверждает:
когда ping от 192.168.1.134 К 10.8.0.1 (работает)
13:51:50.753125 IP 192.168.1.134 > 10.8.0.1: ICMP echo request, id 38796, seq 0, length 64
13:51:50.839622 IP 10.8.0.1 > 192.168.1.134: ICMP echo reply, id 38796, seq 0, length 64
13:51:51.756973 IP 192.168.1.134 > 10.8.0.1: ICMP echo request, id 38796, seq 1, length 64
13:51:51.836193 IP 10.8.0.1 > 192.168.1.134: ICMP echo reply, id 38796, seq 1, length 64
но ping от VPN-сервера к 192.168.1.134 выглядит странно:
13:51:45.140662 IP static.x.x.x.x.clients.your-server.de > 192.168.1.134: ICMP echo request, id 29623, seq 38, length 64
13:51:46.165299 IP static.x.x.x.x.clients.your-server.de > 192.168.1.134: ICMP echo request, id 29623, seq 39, length 64
13:51:47.191915 IP static.x.x.x.x.clients.your-server.de > 192.168.1.134: ICMP echo request, id 29623, seq 40, length 64
Вышеуказанное работает без какой-либо дополнительной конфигурации, кроме включения ip forwarding на клиенте и сервере.
Маршрутная таблица на raspberry PI
0.0.0.0/1 via 10.8.0.1 dev tun0
default via 192.168.178.1 dev wlan0 proto dhcp src 192.168.178.147 metric 600
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2
<IP сервера VPN> via 192.168.178.1 dev wlan0
128.0.0.0/1 via 10.8.0.1 dev tun0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.99 metric 100
192.168.178.0/24 dev wlan0 proto kernel scope link src 192.168.178.147 metric 600
Маршрут VPN-сервера
default via <шлюз провайдера> dev eth0 proto dhcp src <публичный IP> metric 100
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
<шлюз провайдера> dev eth0 proto dhcp scope link src <публичный IP> metric 100
192.168.1.0/24 via 10.8.0.2 dev tun0
Важные моменты из openvpn server.conf
topology subnet
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 ipv6 bypass-dhcp"
route 192.168.1.0 255.255.255.0 # добавляет маршрут для сервера
client-to-client
ccd
ifconfig-push 10.8.0.2 255.255.255.0
iroute 192.168.1.0 255.255.255.0
Необходимые шаги:
-
изменение маршрута по умолчанию raspberry pi на шлюз 10.8.0.1
-
разные параметры маршрута на стороне сервера
-
push “route 192.168.1.0 255.255.255.0” # НЕ ВЛИЯЕТ
-
push “route gateway 10.8.0.1” # НЕ ВЛИЯЕТ
-
push “route 10.8.0.0 255.255.255.0” # НЕ НУЖЕН, так как создает дубли
-
(на raspberry PI) Ответ на ping не доходит до LAN-устройств, но доходит до шлюза Linux
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
Мне кажется, что ping, исходящий от VPN-сервера и доходящий до raspberry PI, неправильно “отмечен”, так как raspberry отбрасывает ответ. Или PI не знает, как маршрутизировать трафик между 10.8.0.x и 192.168.1.x. Любая помощь была бы очень полезна.
Ответ или решение
Когда у вас возникают проблемы с подключением OpenVPN к частной локальной сети (LAN), необходимо тщательно проанализировать расстановку маршрутов и правила межсетевого экрана, чтобы определить корень проблемы. Давайте рассмотрим вашу ситуацию более подробно.
Обозначение топологии
Из вашего описания видно, что у вас есть:
- Home Device: устройство с IP 192.168.1.134
- Raspberry PI (Клиент OpenVPN): с внутренним IP 192.168.1.99 и туннельным IP 10.8.0.2
- VPN Server: с публичным IP на интернет-соединении и туннельным IP 10.8.0.1
Что работает
- Устройство на частной LAN получает IP 192.168.1.134 и отвечает на пинги от 10.8.0.1. Это указывает на то, что маршрут от Raspberry PI к VPN-серверу корректен.
- Raspberry PI может пинговать как 192.168.1.134, так и 10.8.0.1, что также подтверждает работу маршрутов.
Что не работает
Проблема заключается в том, что VPN-сервер не может пинговать 192.168.1.x. Необходимо провести следующие действия для диагностики и устранения проблемы.
Проверка маршрутов
-
Маршруты на Raspberry PI: Убедитесь, что у Raspberry PI есть маршрут к сети 192.168.1.0, который ведет к туннелю. Ваша таблица маршрутов показывает, что это так. Однако важно убедиться, что Raspberry PI знает, как вернуть трафик обратно в сеть 10.8.0.0.
-
Маршруты на VPN-сервере: Ваши маршруты на VPN-сервере также выглядят корректными. Вы маршрутизируете трафик к 192.168.1.0 через 10.8.0.2 (Raspberry PI).
Проверка iptables
Ваши настройки iptables на Raspberry PI, кажется, выставлены верно. Однако, чтобы обеспечить корректную маршрутизацию, попробуйте следующее:
iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPTЭти правила обеспечивают, чтобы пакеты, проходящие между интерфейсами tun0 и eth0, принимались.
Проверьте конфигурацию OpenVPN
-
ccd конфигурация: В вашей конфигурации ccd, вы применяете
iroute. Убедитесь, что эта строка правильно находит192.168.1.0 255.255.255.0. -
Push маршруты на сервере: Здесь вам может понадобиться улучшить настройки
pushмаршрутов. Вместоpush "route 192.168.1.0 255.255.255.0", попробуйте также использовать:push "route 192.168.1.0 255.255.255.0 10.8.0.1"
Дополнительные советы
- Убедитесь, что на домашнем роутере или хосте, к которому подключается Raspberry PI, не настроены дополнительные фильтры или NAT, которые могут блокировать входящие пакеты от 10.8.0.0.
- Проверьте, не установлен ли на маршрутизаторе или другим устройством в вашей локальной сети фильтр, который может игнорировать пакеты, представляющиеся из VPN.
- Если возможно, проверьте лог-файлы OpenVPN как на сервере, так и на клиенте на предмет возможных ошибок.
Заключение
Обратите внимание на конфигурацию маршрутизации и правила iptables как на Raspberry PI, так и на VPN-сервере. Регулярно проверяйте параметры на каждой стадии и обеспечьте, чтобы установленные маршруты между сетями учитывали весь входящий и исходящий трафик, чтобы исправить проблемы с достижимостью ваших IP-адресов.