скрипт проверки внешнего ip с оповещением

Каждые полсекунды проверять внешний ip и выдавать сообщение о том, что ip не защищён vpn.

$ cat ip
#!/bin/sh

myip='81.15.255.255' #my real ip
while [ 1 ] 
do
  ip=$(curl -s ipconfig.io/ip)
  echo $ip
  if [ $ip = $myip ]
  then
    echo 'your ip is not vpn'
  fi
  sleep 0.5
done

вместо echo 'your ip is not vpn' можно включать музыку `mplayer ~/Music/aah.mp3` или отключать интерфейс `ifconfig --down wlp2s0`

ip ro del default
ip ro add $vpn/32 via $gateway dev $netdev

Где дыра и каким боком тут разроаботчики openvpn, я вообще не понял.

" Прочитал эту тему. Места достойные нашёл.

И пришел к выводу - решения проблемы не существует. Потому что решение требуется на уровне кернела, а не примочек и файрволов. blitz (10.12.17 09:19:52) "

МЫ ВСЕ УМРЁМ!!1

Существует как минимум одно тривиальное и очень надёжное решение: закинуть устройство туннеля в отдельный networking namespace, в котором же и запускать приложения. Всё.

Ещё одно решение: создавать tun/tap устройство с адресами и маршрутами при загрузке системы, а не средствами openvpn. И запретить openvpn'у менять это всё. Но публичные VPN-серверы скорее всего на такое не рассчитаны из-за клиентских адресов и маршрутов, раздаваемых динамически.

Можно ещё какие-нибудь решения придумать. Может в iptables как-нибудь трафик маркировать и фильтровать хитро.

Короче, проблемы никакой нет. И тем более, всё это не связано с openvpn.

Это вне задач vpn. Обмазывайся файрволом, будет тебе счастье.

Я по работе пользуюсь vpn, для vpn отдельный пользователь и правила в iptables с дропом пакетов от не тех пользователей:

-A tun-rule -o e+ ! -d 192.168.1.0/24 -m owner --gid-owner 1004 -j tun-rule-reject
-A tun-rule -o tun+ -m owner ! --gid-owner 1004 -j tun-rule-reject

Можно было бы еще хитрее сделать, через `routing policy`, чтоб каждый пользователь пользовал бы свои маршрут, но тогда network-manager applet не работает, без него неудобно.

Ну, если мнение известного дурочка блица для тебя авторитет… Просто для справки — и файрвол, и таблицы маршрутизации — это не «примочки», а на «уровне кернела».

Ему не это же надо. Его смущает, что при пропадении tun-интерфейса никто ему ничего не скажет, а трафик пойдёт через обычный интернет, естественно, не шифрованый.

Как только я вкючаю openvpn мгновенно linux сообщает о разрыве связи. Я не верю, что это случайно, это не рулетка. Как я понял, решений «из коробки» нет. Реклама openvpn - обман, и все усилия по установкам openvpn - ничтожны.

Это заговор!

Реклама openvpn - обман, и все усилия по установкам openvpn - ничтожны.

Маршруты это не дело openvpn, он только за туннель отвечает, а как трафик пойдет, через туннель, паромом или мостом это уже сетевая подсистема решает. Туннель перекрыт, трафик по своим делам «бежит» на мост, как в жизни.

1. Это не дыра в openvpn.

2. Проблема решается запретом трафика ко всем адресам кроме VPN, тем самым при его падении трафик надежно не пойдет никуда до тех пор, пока VPN не подключится.

# Очищаем правила в цепочке OUTPUT 
iptables -F OUTPUT
# По умолчанию запрещаем весь исходящий трафик
iptables -P OUTPUT DROP

# Разрешаем локальный трафик
iptables -A OUTPUT -o lo+ -j ACCEPT

# Разрешаем трафик через интерфейсы VPN
iptables -A OUTPUT -o tun+ -j ACCEPT
iptables -A OUTPUT -o tap+ -j ACCEPT

# Разрешаем трафик до VPN сервера
iptables -A OUTPUT -d 192.0.2.42 -j ACCEPT

Реклама openvpn - обман, и все усилия по установкам openvpn - ничтожны.

Ты пьян или укурен?

Что-то кажется это не будет работать. Нужно таблицу маршрутизации фиксить, а не iptables.

А почему всё-таки неймспейсы не использовать?

Если через VPN надо пускать не какие-то конкретные приложения, а вообще всё, то можно вывернуть наизнанку: в новый пустой неймспейс убрать дефолтный интерфейс с интернетом, в этом же неймспейсе запускать openvpn, а openvpn’овский tun/tap вывести наружу в корневой неймспейс.

CLI для этого уже есть: unshare --net ..., nsenter ... и ip netns .... Осталось завернуть это в юниты systemd и скрипты поднятия интерфейса openvpn.

Можно еще к реальному интерфейсу запретить доступ контекстом безопасности selinux. По-всякому можно.

Но вообще для таких дел файрволл как раз и придумали.

Что-то кажется это не будет работать.

И почему, по твоему, это не будет работать?

Это работает прямо сейчас с того устройства, на котором я печатаю это сообщение. Как и до этого работало многие годы.

Не знаю что говорят разработчики openvpn, а здравый смысл говорит удалить маршрут по умолчанию и оставить маршрут через свой гейт до серверов VPN. И тогда при потере соединения у тебя просто траффик никуда ходить не будет.

Ну с таблицой маршрутизации как-то оно понятнее, но через iptables это тоже будет работать. Если только кто-то не флушнет все правила иптаблеса. Или какая ошибка закрадётся при добавлении новых правил, то он просто вообще не загрузится и всё будет по умолчанию, то есть траффик утечёт.

ШЕРЕТО

Ну а вообще, оно не для того чтоб трафик прятать, слишком тяжёлое и неповоротливае, да и светится красным. Вот объединить несколько машин за натом в «локалку», другое дело.

Я проверял, устанавливаешь на сервере, генерируешь серт, кликаешь по .ovpn или как там файлу в клиенте, и всё работает. Чтобы обрывалось соединение? Да в жисть такого не было. Попробуйте нормального провайдера.

Использую следующую конфигурацию firewalld (используется по умолчанию в Fedora), чтобы маршрутизировать соединения пользователя только через VPN:

# cat /etc/firewalld/direct.xml 
<?xml version="1.0" encoding="utf-8"?>
<direct>
  <chain table="filter" chain="killswitch" ipv="ipv6"/>
  <chain table="filter" chain="killswitch" ipv="ipv4"/>
  <rule table="filter" chain="OUTPUT_direct" priority="0" ipv="ipv4">-j killswitch</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv4">-o w+ -p udp -m owner --gid-owner 1000 -m udp --dport 53 -m comment --comment 'Reject DNS over UDP' -j REJECT --reject-with icmp-port-unreachable</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv4">-o e+ -p udp -m owner --gid-owner 1000 -m udp --dport 53 -m comment --comment 'Reject DNS over UDP' -j REJECT --reject-with icmp-port-unreachable</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv4">-o b+ -p udp -m owner --gid-owner 1000 -m udp --dport 53 -m comment --comment 'Reject DNS over UDP' -j REJECT --reject-with icmp-port-unreachable</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv4">-o w+ -p tcp -m owner --gid-owner 1000 -m tcp --dport 53 -m comment --comment 'Reject DNS over TCP' -j REJECT --reject-with icmp-port-unreachable</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv4">-o e+ -p tcp -m owner --gid-owner 1000 -m tcp --dport 53 -m comment --comment 'Reject DNS over TCP' -j REJECT --reject-with icmp-port-unreachable</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv4">-o b+ -p tcp -m owner --gid-owner 1000 -m tcp --dport 53 -m comment --comment 'Reject DNS over TCP' -j REJECT --reject-with icmp-port-unreachable</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv4">-d 192.168.0.0/16 -m owner --gid-owner 1000 -m comment --comment 'Allow local network' -j ACCEPT</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv4">-d 169.254.0.0/16 -m owner --gid-owner 1000 -m comment --comment 'Allow local network' -j ACCEPT</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv4">-d 172.16.0.0/12 -m owner --gid-owner 1000 -m comment --comment 'Allow local network' -j ACCEPT</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv4">-d 10.0.0.0/8 -m owner --gid-owner 1000 -m comment --comment 'Allow local network' -j ACCEPT</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv4">-o e+ -m owner --gid-owner 1000 -m comment --comment 'Reject no-VPN Ethernet' -j REJECT --reject-with icmp-port-unreachable</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv4">-o w+ -m owner --gid-owner 1000 -m comment --comment 'Reject no-VPN WLAN' -j REJECT --reject-with icmp-port-unreachable</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv4">-o b+ -m owner --gid-owner 1000 -m comment --comment 'Reject no-VPN Bluetooth' -j REJECT --reject-with icmp-port-unreachable</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv4">-o teredo+ -m owner --gid-owner 1000 -m comment --comment 'Allow teredo' -j ACCEPT</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv4">-i teredo+ -m owner --gid-owner 1000 -m comment --comment 'Allow teredo' -j ACCEPT</rule>

  <rule table="filter" chain="OUTPUT_direct" priority="0" ipv="ipv6">-j killswitch</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv6">-o w+ -p udp -m owner --gid-owner 1000 -m udp --dport 53 -m comment --comment 'Reject DNS over UDP' -j REJECT --reject-with icmp6-port-unreachable</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv6">-o e+ -p udp -m owner --gid-owner 1000 -m udp --dport 53 -m comment --comment 'Reject DNS over UDP' -j REJECT --reject-with icmp6-port-unreachable</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv6">-o b+ -p udp -m owner --gid-owner 1000 -m udp --dport 53 -m comment --comment 'Reject DNS over UDP' -j REJECT --reject-with icmp6-port-unreachable</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv6">-o w+ -p tcp -m owner --gid-owner 1000 -m tcp --dport 53 -m comment --comment 'Reject DNS over TCP' -j REJECT --reject-with icmp6-port-unreachable</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv6">-o e+ -p tcp -m owner --gid-owner 1000 -m tcp --dport 53 -m comment --comment 'Reject DNS over TCP' -j REJECT --reject-with icmp6-port-unreachable</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv6">-o b+ -p tcp -m owner --gid-owner 1000 -m tcp --dport 53 -m comment --comment 'Reject DNS over TCP' -j REJECT --reject-with icmp6-port-unreachable</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv6">-d fe80::/10 -m owner --gid-owner 1000 -m comment --comment 'Allow local network' -j ACCEPT</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv6">-d fc00::/7 -m owner --gid-owner 1000 -m comment --comment 'Allow local network' -j ACCEPT</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv6">-o e+ -m owner --gid-owner 1000 -m comment --comment 'Reject no-VPN Ethernet' -j REJECT --reject-with icmp6-port-unreachable</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv6">-o w+ -m owner --gid-owner 1000 -m comment --comment 'Reject no-VPN WLAN' -j REJECT --reject-with icmp6-port-unreachable</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv6">-o b+ -m owner --gid-owner 1000 -m comment --comment 'Reject no-VPN Bluetooth' -j REJECT --reject-with icmp6-port-unreachable</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv6">-o teredo+ -m owner --gid-owner 1000 -m comment --comment 'Allow teredo' -j ACCEPT</rule>
  <rule table="filter" chain="killswitch" priority="0" ipv="ipv6">-i teredo+ -m owner --gid-owner 1000 -m comment --comment 'Allow teredo' -j ACCEPT</rule>

</direct>

VPN настроен через NetworkManager, соответственно, подключается от пользователя NetworkManager, которому разрешены все соединения.

а как дела у wireguard с этим?

а никак. вайргард не управляет маршрутами (да и процесс соединения не проводит, вобщем). как напишешь, так и будет.

А при выборе vpn решения на текуший день, какое решение предпочтительнее в плане стабильности, нормальной производительности(чтобы 50мбит/с выдавало), и чтобы не резали всякие твари типа йоты и им подобных? ipsec, tinc, openvpn, wireguard?

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

Надо использовать VPN на роутере.

И почему, по твоему, это не будет работать?

Перечитал правила еще раз, сорри, все ок.

Я затупил и не поверил, что правила выше правильные. Сам я использовал маршруты на тачке, где надо было обеспечить сабж. Наверно, правильно было бы делать и iptables, и route правила

Удваиваю. Самое удобное и редхатоугодное решение.

Вообще, на случай, если у тебя что с маршрутами, то да, продублировать в iptables тоже есть смысл.

Надо использовать VPN на роутере.

В кафе тоже с ним ходить?

Если нужен мобильный вариант, тогда на хосте ставить минимальную ОС, в которой ничего не делать, основную ОС ставить в виртуалку, а трафик от гостя уже гнать через VPN. В общем суть в том, что если тебе действительно важно шифрование и недопустима любая утечка вне шифрованного туннеля, то нужно изолировать ОС, в любой конфигурации могут быть ошибки, завернуть интерфейс в VPN проще, чем пытаться роутами всё поприбивать. Вот обновишь systemd, он твои роуты сбросит, потому что потому что, и всё, а ты даже ниче не заметишь, т.к. оно само.

если systemd такое делает - он кандтидат №1 на удаление из системы. Нафига он такой нужен и с какого он рулит маршрутами?

Он кандидат на удаление из системы, а ты кандидат на экстрадицию в США, например. Готов поставть свою жизнь на то, что в твоём дистрибутиве нет багов?

100% в моей системе есть баги, от мала до велика. Вот за это я готов поставить свою жизнь и скорее всего доказать даже. А доказывать отсутсвие - это к верующим людям скорее, бессмысленно, глупо и недостижимо

Дополню, если ставки велики, то в ход идут уже средства посерьезнее, и одним впн там не обойдешься. Как говорится «жить захочешь - не так раскорячишься»

Кремлебот пришел попугать впном? Иди лесом, бездарь, не умеющий толком анализировать информацию.

Тут перепись дураков что ли? Нафига тебе ставить свою жизнь? Ау, дебилушка. Ладно я отписался и ухожу. Удачи.

Зачем тебе vpn/tor? Это всё для детей. Делай туннель через протоколы более низкого уровня.

Делай туннель через протоколы более низкого уровня.

а вот с этого места поподробнее пожалуйста

Бред какой-то.

Ну поставишь ты под виртуалку. А если VPN отключится на хосте? Разница то в чем?

В том, что в виртуалке пропадёт связь, а не полезет вне туннеля.

С чего бы это?

ICMP/DNS туннель какой-нибудь. Правда для просмотра кисок будет слишком палевно.

Установил клиент openvpn на роутере, по логу роутера соединение не разрывается, но через соединение vpn идет очень маленький траффик и браузером определение ip указывает на провайдера. https://wiki.merionet.ru/seti/20/chto-takoe-texnologiya-dpi/

Мог бы ещё NetworkManager этими неймспейсами управлять...