проверить, что VPN тунель рабочий

0

1

привет!

на девайсе (клиенте) устанавливаю OpenVPN для того, чтоб через VPN сервер иметь возможность подключаться к девайсам разбросанным по миру, для апдейтов.

настройка VPN происходит автоматически, скриптом установщиком ПО.

суть вопроса в том, что мне нужно добавить функцию проверки работоспособности VPN на этапе установки софта.

то есть скрипт все настроил, но должен еще и проверить что VPN работает.

VPN настроен так, чтоб трафик через него не уходил, то есть, после запуска VPN клиента я вижу появление tun0. достаточно ли этого чтоб утверждать что VPN рабоает?

спасибо.

Ссылка

←	Proxmox и (зачем-то) LVM

Как вернуть данные из зашифрованного на LVM диска. (не успел перезаписатся)

→

возможно, я сейчас говорю глупость, но нельзя в скрипт просто ping добавить? или curl ifconfig.me, к примеру?

~~d09~~ ☆
(12.12.20 21:54:29 MSK)

Ответ на: комментарий от d09 12.12.20 21:54:29 MSK

VPN настроен так, чтоб трафик через него не уходил

niXman ★★★
(12.12.20 22:07:24 MSK) автор топика

На сервере смотри openvpn-status.log

Ну и вообще, документация есть https://openvpn.net/community-resources/controlling-a-running-openvpn-process/

Ссылка не очень удачная, ещё хуки можно задать на подключение/отключение.

А если надо проверять на клиенте, то пинговать «внутренний» ресурс.

vvn_black ★★★★★
(12.12.20 22:13:25 MSK)
Последнее исправление: vvn_black 12.12.20 22:19:02 MSK (всего исправлений: 2)

то есть, после запуска VPN клиента я вижу появление tun0. достаточно ли этого чтоб утверждать что VPN рабоает?

Если ещё проверку маршрута добавить, то вполне.

vvn_black ★★★★★
(12.12.20 22:21:46 MSK)

Ответ на: комментарий от vvn_black 12.12.20 22:13:25 MSK

по поводу ссылки - там есть management interface. как я понял, я могу активировать его и при попощи telnet запросить, как минимум, статус…

А если надо проверять на клиенте, то пинговать «внутренний» ресурс.

в смысле, пинговать tun0? думаете, это гарантировано говорит о том что тунель исправен?

niXman ★★★
(12.12.20 23:22:51 MSK) автор топика

Ссылка

Ответ на: комментарий от vvn_black 12.12.20 22:21:46 MSK

то есть ip ro sh и парсить вывод? что именно в выводе я должен проверить?

niXman ★★★
(12.12.20 23:24:27 MSK) автор топика

Ответ на: комментарий от niXman 12.12.20 22:07:24 MSK

проверяй тогда доступность внутренних ресурсов. Можешь пингануть другой конец туннеля.

anonymous
(13.12.20 02:52:01 MSK)

Ответ на: комментарий от anonymous 13.12.20 02:52:01 MSK

Можешь пингануть другой конец туннеля.

не уверен о чем вы… как?

niXman ★★★
(13.12.20 13:51:33 MSK) автор топика

Ответ на: комментарий от niXman 12.12.20 23:24:27 MSK

Есть достаточно простой способ проверить, что пакет уйдет в впн.

ip ro get <ip>

где <ip> адрес ресурса доступный только через впн.

Если в выводе указан tun, значит пакет уйдет в впн.

vel ★★★★★
(13.12.20 16:21:28 MSK)

Ссылка

Ответ на: комментарий от niXman 13.12.20 13:51:33 MSK

А для реальной проверки работоспособности можно воспользоваться магией so_bindtodevice которую использует «ping -I tun0 <ip>»

в этом случае пакет уйдет через tun0

vel ★★★★★
(13.12.20 16:29:45 MSK)

Ответ на: комментарий от vel 13.12.20 16:29:45 MSK

so_bindtodevice

что за тема?

~~in_dance~~ ★
(13.12.20 23:30:00 MSK)

Ответ на: комментарий от in_dance 13.12.20 23:30:00 MSK

«ping -I dev ip» позволяет передать пакет именно через указанное устройство фактически игнорируя некоторые данные из правил и таблиц маршрутизации

без этого например не обойтись при посылке броадкастов, но иногда можно применять и для др. целей.

vel ★★★★★
(14.12.20 10:12:57 MSK)

Ответ на: комментарий от vel 14.12.20 10:12:57 MSK

спасибо, не знал

~~in_dance~~ ★
(14.12.20 10:40:12 MSK)

Ссылка

Ответ на: комментарий от vel 14.12.20 10:12:57 MSK

в моем случае это почему-то не работает…

пробую так:

ping -I tun0 google.com
PING google.com (172.217.20.14) from 10.8.0.41 tun0: 56(84) bytes of data.
^C
--- google.com ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6048ms

идеи?

niXman ★★★
(18.12.20 14:28:29 MSK) автор топика