Например iptables. Разрешить хождение пакетов не_через vpn интерфейс только до сервера vpn ну и еще dns можно оставить.
Тоже самое можно без iptables а таблицей роутинга реализовать.
Например у меня это реализовано по второму варианту (не специально для запрета, тому есть другие причины, несколько провайдеров)
Марщрут по умолчанию без vpn не прописываю
Перед стартом vpn:
получаю адреса dns серверов и адрес шлюза от dhcp провайдера
прописываю роут до этих серверов через шлюз провайдера
с этих адресов (в цикле пока не получу ответ) запрашиваю ip vpn сервера по его имени (vpn.provider.name)
прописываю этот ip в конфиг vpn
прописываю роут до этого ip через шлюз провайдера
стартую vpn

Опиши проблему подробнее, а то ничего не понятно.

Подключи через ентерпрайзный роутер, на роутере назначь порт на нужный VPN.

Для этого и существуют маршруты

man ip-route

[root@localhost ~]# ip route
default via IP_РОУТЕРА dev ethЦИФРА 
169.254.0.0/16 dev eth1  scope link  metric 1002 
192.168.0.0/24 dev eth1  proto kernel  scope link  src 192.168.0.100
[root@localhost ~]# ip route add IP_СЕРВЕРА_VPN via IP_РОУТЕРА dev ethЦИФРА
[root@localhost ~]# ip route del default

Вернуть всё взад:

[root@localhost ~]# ip route del IP_СЕРВЕРА_VPN
[root@localhost ~]# ip route add default via IP_РОУТЕРА dev ethЦИФРА

вручную прописать маршрутизацию

Немного не в тему, но характерно, что всяческие VPN решения достигают перенаправления в канал с помощью пары маршрутов через VPN для сетей 128.0.0.0/1 и 0.0.0.0/1. Это перекрывает default gateway за счет большей маски, но с падением интерфейса VPN маршруты исчезают и трафик льется в открытую, о чем юзер может даже и не догадываться(( Таков, например, AVAST SecureLine VPN))

Здравствуйте КО. А значит до поднятия впн, все было зашибись и во всем виноват только впн. Самим не смешно?

Проблема не в том что при падении впн трафик начинает идти прямо, это ожидаемо как раз, проблема что юзверь может этого не заметить :) Вот эту вторую проблему и решай :) Например схемку звуковую поправь, чтобы на потерю интерфейса сирена ревела например. А ещё можно наверно как нибудь скрипт испортить чтобы он default route не возвращал после останова, тогда инет отвалится вообще вместе с впн, вертать взад придётся руками, или маршрут на впн сервер напрямую прописать заранее.

Короче, это не баг, это фича и это настраивается.

Я ничего не понял, поясните вашу мысль для тупых?

Ну вот решение anc как раз исключает утечку трафика в обход VPN. Я же просто для справки это здесь привел, не как руководство к действию.

А вот вы простите для кого примеры приводили с маской /1 ? Что было в таблице роутинга по «вашему капитанскомуО» ДО поднятия впн и что изменилось в ней после его отключения? Что-то новое появилось?

Бухаете, да? Я снова ничего не понял, давайте еще разок, в чем суть наезда? Без шуток, я не понимаю ваш бессвязный поток мысли.

Отвечая на ваш вопрос (ну, как я его понял) формально, ничего не изменилось. До того был default gateway, и после того остался. Что-то не так?

Отвечу как принято «кемто до нас и в благословенной земле» А вы простите тогда зачем вообще написали про поднятие роутов /1 ? Вот какое оно отношение к топику имеет?

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

А дефолтные маршруты при падении и поднятии интерфейсов сетевых разьве не автоматически прописываются?

А дефолтные маршруты при падении и поднятии интерфейсов сетевых разьве не автоматически прописываются?

Ну вообще при «падении и поднятии интерфейсов» как таковых ничего не прописывается, кроме ранее прописанных на них адресах.
Но предполагаю что речь не об этом. Обращаю внимание на коренные слова «падении и поднятии интерфейсов», у вас разве при поднятии и опускании интерфейсов таких как ppp/tun/tap что-то с роутингом на физическом интерфейсе (eth) меняется? Намек понятен?

да надо на wlan запретить все кроме ip адреса впн сервера так? днс тоже запретить? они же не нужны по сути там

Странные у вас формулировки, wlan, в дебе таких слов вроде небыло... или уже появились?
ЗЫ днс нужен что бы по по имени vpn.my-prov.ru получить ip.

wlan0 мой wifi интерфейс а после подключения к впн днс указанные в wlan уже никак не участвуют?

Если вы соединяетесь к vpn серверу по имени а не ip адресу, то из этого имени надо получить ip адрес, для этого и нужно разрешить хождение днс.

Устроили тут цырк...

Не знаю, как в дебиане, но у тебя должно быть так:

- до поднятия туннеля у тебя в таблице не должно быть маршрута по-умолчанию, только маршрут до VPN-сервера (a.b.c.d/32 via x.y.z.t) с некой метрикой, например, R;

- в поднималке VPN необходимо, чтобы прописывался маршрут по умолчанию через туннель, с метрикой R+N, где N>0.

В такой конфигурации, единственная утечка, которая может быть — пакеты на адрес VPN-сервера, если они нешифрованные.

Не внимательно читаете. Если адрес впн не IP а имяхоста, то еще нужно как-то его из имени в IP преобразовать, а значит нужно разрешить хождение запросов к dns.
Про метрику вообще чуш какую-то нагородили. Метрика играет роль только для одинаковых маршрутов. Идите дальше курить доки.

Это я понимаю. в дальнейшем то эти днс'ы не должны учавствовать

так как такое настроить?

а когда буду отклеиваться от впн маршруты какие то дефолтные будут создаваться для wlan напрямую?

Запретить, не?

а как?)

а еще ведь можно просто в host прописать сопостовления имени и адреса ?

Сильно устало «Да, можно». И вообще если ppp/&etc то пофиг, сам пропиши сразу ip если роли не играет.

Можно свой резолвер на локалхосте установить и настроить, чтобы домен впн-сервера резолвился на ДНСе провайдера, а остальное через, например, 8.8.8.8

Вопрос тот же, что и автора темы. К ВПН подключаюсь с виртуалки, подключенной к хостовой ОС по NAT.

Можно где-то увидеть пример настройки маршрутов с примером решения задачи обрыва трафика, при падении ВПН?

Спасибо.

Если зарезать файрволом возможности перенаправления трафика куда угодно кроме VPN-интерфейса, то такой фигни не будет. В Linux это делается с пол-пинка.

Тут уже надо выбирать - либо безопасность(либо есть Интернет - через VPN, либо если VPN-лежит - болт), либо удобство(Интернет есть всегда если не лежит провайдер, но через VPN он идёт только если сам VPN не лежит)

Интересна схема с полным отключением сети при отключении ВПН. Ну и возможность все вернуть в первоначальное состояние.

Мне нужны именно примеры (мануалы, если возможно).

Читаешь это, после прочтения задаешь вопросы. Да, руководство не сильно актуальное, но основные принципы(в том числе то что ты хочешь настроить) там абсолютно те же.

Hint: в идеале после прочтения вопросов уже не будет. Но если вдруг они останутся - задавай, не стесняйся. Пока что дам подсказку: «сначала запретить всё для входящего и транзитного трафика, затем разрешить нужное».

я это делаю через ufw

sudo ufw enable
sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow in on tun0
sudo ufw allow out on tun0
sudo ufw allow out to 192.168.0.0/24
sudo ufw allow out to <подсавить IP своего VPN сервера>

когда нужно идти напрямую, то просто выключаю ufw (sudo ufw disable)

Дали им NetworkManager, нет, хочу красноглазить.

А если это виртуалка за NAT

И марушруты такие:

0.0.0.0/1 via 10.8.1.5 dev tun0 
default via 10.0.2.2 dev enp0s3  proto static  metric 100 
10.0.2.0/24 dev enp0s3  proto kernel  scope link  src 10.0.2.15  metric 100 
10.8.1.1 via 10.8.1.5 dev tun0 
10.8.1.5 dev tun0  proto kernel  scope link  src 10.8.1.6 
128.0.0.0/1 via 10.8.1.5 dev tun0 
xxx.xxx.0.0/16 dev enp0s3  scope link  metric 1000 
<адрес VPN-сервера> via 10.0.2.2 dev enp0s3 

то эту строку

sudo ufw allow out to 192.168.0.0/24

заменить на

sudo ufw allow out to 10.0.2.0/24