Asus весь трафик через vpn как отключить

НАСТРОЙКА ASUS PADAVAN, OPENVPN СОЕДИНЕНИЕ, VPN ТУННЕЛЬ

Настройки на этой странице предназначены для подключения к сервису VPNKI, а не к любому VPN серверу в Интернет.

Перед началом настройки ОБЯЗАТЕЛЬНО ознакомьтесь с «Общими сведениями» о работе системы. Ссылка здесь https://vpnki.ru/settings/before-you-begin/main-tech-info .

Так как вы настраиваете маршрутизирующее оборудование, то не забудьте указать «сеть за маршрутизатором» в личном кабинете системы VPNKI.

(Правила и маршруты на сервере VPNKI применяются при подключении туннеля. Если изменили настройки в личном кабинете — переподключите туннели).

Для подключения OpenVPN c Asus вам потребуются.

— Имя пользователя и пароль туннеля, который вы создали на странице «Мои настройки» — «Настройки туннелей». Имя пользователя имеет формат userXXXXX.

— Файл профиля подключения формата ovpn с личной страницы нашего сайта. Пункт меню «Мои настройки» — «Настройки туннелей». Скачайте его на свой компьютер. (см. п.2 этой инструкции).

1. Для подключения беспроводного маршрутизатора с прошивкой от Padavan (Asus RT-N56U, Asus RT-65U и др.) к системе VPNKI подключитесь к маршрутизатору через Web интерфейс. Выберете в корневом меню – “VPN клиент” и передвиньте ползунок “Включить VPN клиент” в положение включено.

2. Запустите процесс OpenVPN на сервере VPNKI (пункт меню «Мои настройки» — «Настройки туннелей», доступен после регистрации) и скачайте профиль соединения,. Сохраните файл vpnki_XXXXXX.ovpn на свой компьютер, он нам понадобится. Допустим, что вы запустили на сервере VPNKI процесс OpenVPN поверх протокола UDP с шифрованием.

3. Далее в выпадающем пункте меню Padavan “Протокол VPN клиента” выбираем – “OpenVPN”.

В строке “Удаленный VPN-сервер (IP или DNS-хост)” вписываем — msk.vpnki.ru .

В строке “Порт” вписываем значение, выданное вам при старте процесса OpenVPN на сайте. Это же значение находится в скачанном на компьютер профиле подключения в строке remote msk.vpnki.ru xxxx.

В меню “Транспорт” выбирайте “UDP” (если на сервере вы запустили вариант с UDP), в меню “Уровень инкапсуляции” выбираем “L3-TUN(IP)”.

“Тип аутентификации” устанавливаем “TLS: username/password”.

После этого, в строку “Логин” вписываем логин вида: “userXXXXX”. Он был получен на сайте при создании туннеля. В строку “Пароль” – пароль, который вы вводили там же.

Меню “Алгоритм проверки подлинности” лучше оставить без изменения — “[SHA1]SHA-1, 160bit”.

В меню “Алгоритм шифрования данных” выбираем “[AES-128-CBC]AES, 128bit”, сжатие данных методом LZO отключаем и включаем проверку HMAC сигнатуры.

В меню “Блокировать доступ со стороны VPN-сервера” если вы доверяете сервису – выбирайте “Нет (Site-to-Site), только маршрутизация”. В противном случае настраивайте согласно ваших требований.

Пункты меню “Получать адреса DNS от VPN-сервера” и “Направлять весь трафик через VPN интерфейс?” настраиваются под ваши требования.

4. Для дальнейших настроек переходим на вкладку “Сертификаты/ключи OpenVPN”:

5. Любым текстовым редактором открываем файл “vpnki_XXXXXX.ovpn”, скачанный с сайта ранее.

6. Выделяем и копируем текст начиная со строки ——BEGIN CERTIFICATE—— и заканчивая строкой ——END CERTIFICATE—— (включая эти строки) и затем вставляем эти строки в поле “ca.crt (Root CA Certificate)” в Web интерфейсе маршрутизатора. Это сертификат.

Затем, также выделяем и копируем текст начиная со строки ——BEGIN OpenVPN Static key V1—— и заканчивая строкой ——END OpenVPN Static key V1—— (включая эти строки) и затем вставляем эти строки в поле “ta.key (TLS Auth Key) — secret” в Web интерфейсе маршрутизатора. Это ключ.

7. ВСЁ. Настройка закончена, осталось нажать кнопку “Применить”. Затем перейти на вкладку “Настройки” и, если все сделано правильно, в конце строки “ Удаленный VPN-сервер (IP или DNS-хост)” мы увидим надпись “Подключено”. Не торопитесь, это может занимать несколько секунд.

8. Дальнейшие проверки выполняются с сайта согласно инструкций. После успешного установления соединения между вашим маршрутизатором и сервером VPNKI вы можете проверить связь при помощи утилит на странице «Инструменты» в меню «Мои настройки» в вашем личном кабинете VPNKI.

PS: В целях борьбы с зависшими сессиями мы принудительно отключаем пользовательские туннели с протоколом OpenVPN в 00:00 по Московскому времени. При правильной настройке соединения должны автоматически переустановиться.

Если ваше устройство теряет соединение каждый час, то, вероятно, это означает, что клиент и сервер не могут согласовать свои параметры при реализации процедуры смены ключей шифрования. Профиль подключения, полученный вами из личного кабинета VPNKI, содержит параметр reneg-sec 0, однако настройка Padavan в своем интерфейсе не имеет поля для установки такой строки. Этот параметр означает, что клиент НЕ должен запускать процедуру смены ключей шифрования. В свою очередь, сервер VPNKI также не запускает процедуру смены ключей. Из-за того, что сессии и так отключаются в 00-00 ежедневно, то смена ключей шифрования каждый час не имеет практического смысла.

Маршрутизатор с Padavan без такой строки будет пытаться каждый час запустить процедуру смены ключей, что не будет поддержано со стороны сервера. Следствием этого и будет тот самый обрыв соединения. Возможно, в вашем интерфейсе есть поле «Дополнительные настройки» в которое можно вписать строку reneg-sec 0.

Важные советы после настройки удаленного подключения

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

• Проверьте статус подключения туннеля на странице «Мои настройки» — «Состояние туннеля». Попробуйте отключить туннель со стороны сервера. Посмотрите как ваш клиент попытается переустановить соединение.

• Посмотрите как отображается подключение в различных журналах сервера. «Статистика» — «Статистика подключений». Еще в «События безопасности». А еще в «События авторизации». Важно видеть как отображается успешное соединение.

• Попробуйте выполнить пинг сервера VPNKI 172.16.0.1 с вашего устройства.

• Попробуйте выполнить пинг вашего устройства со страницы «Инструменты». Выполните пинг устройства по адресу туннеля сети VPNKI — 172.16.x.x. Это важный шаг и не стоит им пренебрегать. Но стоит знать, что пинг может быть неуспешен и это результат работы межсетевого экрана устройства.

• Если вы имеетевторой подключенный туннель в своем аккаунте, то проверьте пинг и до устройства в другом туннеле. Сначала по его адресу сети VPNKI — 172.16.x.x. Затем можно выполнить пинг устройства в другом туннеле по адресу внутренней сети (192.168.x.x). Если такая маршрутизация настроена.

• Попробуйте запросить лог подключения по OpenVPN из личного кабинета системы. Выгрузка из журнала за сутки поступит на вашу почту. Так выглядит ваше подключение глазами сервера.

• Посмотрите как отображается количество переданного трафика туннеля. Это в «Мои настройки» — «Статистика» — «Графики использования». За текущий день статистика показывается с разбивкой по туннелям. За предыдущие дни — суммарно.
  По особенности подсчета трафика туннелей читайте в FAQ. Ссылка здесь.

Надеемся, что вы успешно прошли все пункты этих советов! Теперь ваше соединение работает успешно. А вы познакомились с инструментами нашего сервера.

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

*** Если вдруг что-то не получилось, обращайтесь на Форум.

Рекомендации по выбору тарифа для удаленного доступа

Если вы не планируете передачу видео трафика, то мы рекомендуем вам начинать с выбора тарифа PLAN-MYDEV. Если передача видео будет осуществляться, то стоит сразу начинать с PLAN-VIDEO. Если скорости хватать не будет, то в любое время вы можете изменить тариф на более скоростной.

Если вы используете нашу систему для решения бизнес задач, то начинайте с аналогичных тарифов с приставкой BUSINESS-.

Контролировать объем переданного трафика вы можете на странице с графиками использования.

Узнать реальную скорость своего VPN соединения вы можете утилитой iperf3 на странице «Инструменты». Стоит отметить, что вопрос скорости передачи полезных данных будет зависеть от трех факторов:

• от типа используемого протокола VPN;

• типа транспортного протокола — TCP или UDP;

• физической удаленности вашего устройства от нашего сервера.

Худшим вариантом по скорости окажется вариант, когда в качестве транспортного протокола для VPN соединения используется TCP. При этом ваше устройство размещено далеко от сервера VPNKI. В этом случае, реальная скорость передачи данных будет определяться необходимостью подтверждения передачи каждого пакета в протоколе TCP.

ДОПОЛНИТЕЛЬНО ПО ТЕМЕ КОНФИГУРАЦИИ УДАЛЕННОГО ДОСТУПА

Кроме настройки по этой инструкции вам могут пригодиться другие примеры конфигурации и использования системы. Среди них:

• Рабочий стол через RDP и OpenVPN. Ссылка здесь.

• Выставить FTP сервер через проброс TCP порта. Ссылка здесь.

ОБЩАЯ ИНФОРМАЦИЯ О БЛИЗКИХ ТЕМАХ

По ссылкам ниже вы можете ознакомиться с информацией, связанной с темой VPN соединений.

• Немного более подробно про IP адреса. Можно прочитать на нашем сайте.

• Про удалённый доступ к компьютеру можно. Можно почитать на нашем сайте.

• Про VPN и протоколы можно почитать здесь.

• Про выход в Интернет через VPN и центральный офис. Можно почитать здесь.

Все в порядке, но.

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

В целях обеспечения безопасности сайта от кибератак нам необходимо убедиться, что вы человек. Если данная страница выводится вам часто, есть вероятность, что ваш компьютер заражен или вы используете для доступа IP адрес зараженных компьютеров.

Если это ваш частный компьютер и вы пытаетесь зайти на сайт, например, из дома — мы рекомендуем вам проверить ваш компьютер на наличие вирусов.

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

• © 2005-2023, «4PDA». 4PDA® — зарегистрированный товарный знак.

Как отключить маршрутизацию всего трафика через VPN в Ubuntu?

Честно, я плохо знаком с настройками iptables и вообще какой либо маршрутизации на линуксе, так что если нужны какие-то конфиги или логи, кроме приведенных — пишите.
Заранее благодарен за помощь.

И так. Установленны пакеты strongswan, nm-strongswan, network-manager-strongswan.
Соединение (клиент) по IKEV2 (сертификаты) — соединение есть, но перенаправляет полностью вест трафик по VPN.
Если указать в настройках Use this connection only for resources on its network — трафик весь все-равно перенаправляется, т.е. нет доступа к ресурсам сети.

Шлюз: 10.10.16.1
Шлюз VPN: 10.10.10.5

ip route show:
default via 10.10.16.1 dev eth0 proto static
10.10.1.0 via 10.10.10.5 dev tun0 proto static metric 200
10.10.10.5 dev tun0 proto static scope link
10.10.16.0/26 dev eth0 proto kernel scope link src 10.10.16.60 metric 1

ip route show table local:
local 10.10.1.13 dev eth0 proto kernel scope host src 10.10.1.13
local 10.10.1.13 dev tun0 proto kernel scope host src 10.10.1.13
broadcast 10.10.1.13 dev tun0 proto kernel scope link src 10.10.1.13
broadcast 10.10.16.0 dev eth0 proto kernel scope link src 10.10.16.60
local 10.10.16.60 dev eth0 proto kernel scope host src 10.10.16.60
broadcast 10.10.16.63 dev eth0 proto kernel scope link src 10.10.16.60
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1

ip rule:
0: from all lookup local
220: from all lookup 220
220: from all lookup 220
32766: from all lookup main
32767: from all lookup default

Была идея настроить соединение вручную, через ipsec.conf:
conn hide
eap_identity=%any
keyexchange=ikev2
right=*Адрес Сервера*
rightsubnet=0.0.0.0/0
rightid=%any
leftauth=pubkey
rightauth=%any
leftca=/etc/ipsec.d/cacerts/strongswanCert.pem
leftcert=/etc/ipsec.d/certs/*Сертификат пользователя*.der
left=%defaultroute
leftfirewall=yes
mobike=yes
auto=add

ipsec.secrets:
: RSA /etc/ipsec.d/certs/*ключ от сертификата пользователя*.der

Конец лога:
initiating IKE_SA hide[1] to *Адрес сервера*
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
sending packet: from *АйпиМашины*[500] to *Адрес сервера*[500] (1076 bytes)
received packet: from *Адрес сервера*[500] to *АйпиМашины*[500] (273 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ]
local host is behind NAT, sending keep alives
received cert request for «*корневой сертификат*»
sending cert request for «*корневой сертификат*»
authentication of ‘*пользовательский сертификат*’ (myself) with RSA signature successful
sending end entity cert «*пользовательский сертификат*»
establishing CHILD_SA hide
generating IKE_AUTH request 1 [ IDi CERT CERTREQ AUTH SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) ]
sending packet: from *АйпиМашины*[4500] to *Адрес сервера*[4500] (1968 bytes)
received packet: from *Адрес сервера*[4500] to *АйпиМашины*[4500] (1648 bytes)
parsed IKE_AUTH response 1 [ IDr CERT AUTH N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(FAIL_CP_REQ) N(TS_UNACCEPT) ]
received end entity cert «*видимо ключ от сертификата пользователя*»
using certificate «*видимо ключ от сертификата пользователя*»
using trusted ca certificate «*корневой сертификат*»
checking certificate status of «*видимо ключ от сертификата пользователя*»
certificate status is not available
reached self-signed root ca with a path length of 0
authentication of ‘*видимо ключ от сертификата пользователя*’ with RSA signature successful
IKE_SA hide[1] established between *АйпиМашины*[*пользовательский сертификат*]. *Адрес сервера*[*видимо ключ от сертификата пользователя*]
scheduling reauthentication in 10034s
maximum IKE_SA lifetime 10574s
received FAILED_CP_REQUIRED notify, no CHILD_SA built
failed to establish CHILD_SA, keeping IKE_SA
establishing connection ‘hide’ failed

• Вопрос задан более трёх лет назад
• 1667 просмотров

2 комментария

Оценить 2 комментария

Заворачиваем весь трафик локальной сети в vpn без ограничения скорости

В прошлой статье мы разбирали, как анонимизировать весь Интернет-трафик одного хоста. Теперь давайте повысим уровень безопасности, обернув всю локальную сеть VPN-ом. При этом мы избавимся от опасности выйти в интернет с еще не настроенного девайса и ассоциировать адрес своего провайдера с этим устройством.

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

Итак, каковы наши цели:

• пропускать через VPN весь без исключения исходящий трафик
• делать это с максимально возможной скоростью
• не зависеть от временных неполадок VPN-провайдера
• максимум анонимности в Интернете

Подготовка

Нам нужен мощный роутер, способный шифровать трафик на высокой скорости. Он будет выступать в роли VPN-шлюза. Мы нашли замечательные мини-ПК на AliExpress, которые подошли под эту задачу: четырехъядерный Intel Celeron, нативная поддержка AES-CBC, AES-XTS, AES-GCM, AES-ICM и аж четыре RJ-45 порта. И по умолчанию на них была установлена pfSense. С ней и будем работать.

Если ваш Интернет-провайдер требует особой настройки соединения, вы можете взять еще два роутера и разделить доступ к интернету и локальную сеть, а между ними поставить VPN-шлюз. В другом случае, можете напрямую подключить провод провайдера к VPN-шлюзу, а за ним разместить ваш домашний роутер с локальной сетью. Первоначальная настройка Интернет-соединения на pfSense выходит за рамки этой статьи.

Настройка

Статья предполагает, что интернет подключен к первому порту, ваш ПК или домашняя сеть — ко второму, и что до настройки VPN вы смогли выйти в интернет.

Во избежание дальнейших проблем давайте авторизуемся у любимого VPN-провайдера и найдем инструкцию по настройке pfSense. Если ваш провайдер не предоставляет инструкцию по ручной настройке в pfSense, можно воспользоваться вот этой от моего любимого провайдера: www.expressvpn.com/support/vpn-setup/pfsense-with-expressvpn-openvpn — основная суть не изменится. Приведенная статья с картинками расписывает, как полностью настроить только что купленный роутер с pfSense.

Вот краткий чеклист настройки нового VPN-а:

• System — Cert. Manager — CAs. Добавляем сертификат VPN CA
• System — Cert. Manager — Certificates. Добавляем сертификат VPN сервера
• VPN — OpenVPN — Clients. Создаем нового клиента по инструкции от VPN-провайдера
• Interfaces — Assignment. Добавляем клиентов как интерфейсы
• System — Routing. Проверяем что появился шлюз.
• Firewall — NAT. Добавляем правила NAT для каждого клиента
• Firewall — Rules — LAN. Добавляем перенаправление всего трафика из сети через Gateway
• System — Routing. Для активного VPN-a в настройках шлюза указываем Monitor IP, пингом до которого будет проверяться работоспособность VPN-а

На этом этапе останавливаемся и проверяем, что доступ в интернет через VPN есть, и что при отключении от VPN доступ пропадает вовсе. Если интернета нет — где-то ошиблись, смотрим логи VPN, проверяем настройки заново. Если после отключения VPN трафик начинает идти через основной шлюз, значит накосячили в Firewall — Rules — LAN.

Теперь интересная часть. Если ваш провайдер выдает 20 Мбит в секунду, и то ночью — то на этом этапе вы уже получили локальную сеть, полностью закрытую VPN-ом, который работает с максимально возможной скоростью. Но что, если у вас канал пошире?

Масштабируемся

Настраиваем еще пару-тройку VPN клиентов для разных серверов по инструкции выше. Добавлять сертификаты CA и сервера не нужно, выбираем уже добавленные. Также не выполняем шаг с Firewall — Rules — LAN, его мы сделаем позже. Необходимое количество клиентов устанавливается эмпирическим путем по результатам замеров скорости через каждый отдельный сервер.

После того как завершили, у нас должна быть следующая картина:

— В VPN — OpenVPN — Clients созданы и активированы клиенты

— В Interfaces — Assignment созданы и активированы интерфейсы для каждого клиента

— В Status — OpenVPN все клиенты находятся в состоянии «up»

— В System — Routing появились шлюзы, и для них указаны пингуемые IP-адреса.
(Если не можете придумать, кого попинговать — откройте shodan.io и найдите все IP google)

Теперь зайдем в System — Routing — Gateway Groups. Нажмите Add. Укажите запоминающееся имя в Group Name.

Теперь обратите внимание на таблицу Gateway Priority. Группы шлюзов работают следующим образом: failover по уровням, балансировка внутри уровня. Столбец Tier указывает, в каком уровне будет использоваться данный шлюз. Простейший вариант — указываем все активные VPN-шлюзы в первом уровне. Вариант для медленного интернета — создаем двух клиентов и размещаем их на первом и втором уровне, но в этом случае будет только отказоустойчивость.

Ниже найдите Trigger Level. Это условие, при котором произойдет временное исключение шлюза из группы. Варианты кроме Member Down позволяют перестать отправлять пакеты шлюзу чуть раньше, чем он упадет полностью — по превышению порога потери пакетов и/или по высокому пингу. Пороги потерь и пинга задаются для каждого шлюза индивидуально в System — Routing — Gateway.

Как только выбрали удобный вариант расстановки шлюзов по уровням, нажмите Save.

Пришло время направить трафик в новую группу шлюзов. Идем в Firewall — Rules — LAN, открываем созданное ранее правило перенаправления, спускаемся до списка со шлюзами и видим в этом списке созданную нами группу. Выбираем её, сохраняем правило и применяем изменения. Всё, теперь каждое новое соединение будет идти через новый VPN-клиент в группе.

Время тестирования: открываем api.ipify.me, отключаем кэш и keep-alive, и перезагружаем страницу. Если вы единственный пользователь в сети, на каждое обновление страницы вы должны видеть новый IP адрес, отличающийся от вашего домашнего. Если вы видите один и тот же адрес, полностью обновите страницу при помощи Ctrl+F5 (Command+Shift+R на маках), или откройте новую приватную вкладку. Если не помогло — значит где-то ошиблись в настройках группы, или не сменили шлюз в правилах фаерволла.

Теперь о плохом. К сожалению, у данного решения есть небольшой трудноуловимый баг, если использовать его перед роутером локальной сети (а не коммутатором). Рано или поздно у вас отваливается один из VPN-клиентов, срабатывает исключение его из группы, и всё хорошо до того момента, пока VPN не поднимется обратно. Так как все пользователи находятся за NAT, а VPN-роутер видит только один IP-адрес и 65 тысяч портов, со временем он ассоциирует все порты с теми VPN-клиентами, которые никогда не падали. Соответственно, как только VPN-клиент поднимается, через него не идет никакой трафик. Клиент полностью жив, через него идут пинги и некоторое стабильное количество служебного трафика, но через него не идет трафик клиентов. По идее это решалось бы сбросом таблицы соединений, и для этого даже есть галочка в настройках pfSense, но в моих исследованиях эта галочка напрочь блокировала всякий доступ к роутеру, так как клиенты начинали валиться циклично, при этом роняя только-только установленные соединения с веб-интерфейсом, что сильно затрудняло исправление проблемы. Без этой галочки при наличии более двух VPN-ов они уравновешивали себя, так что доступ хотя бы через один всегда был. В конце концов я настроил в мониторинге условие «если пять минут на интерфейсе было меньше 1000 байт трафика в секунду, сообщить мне», и в особо запущенных случаях перезагружаю зомби-VPN-клиента вручную с целью сбросить таблицу соединений.

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

• Блог компании Postuf
• Информационная безопасность