KorDen

Вариант 1: положить файлы crt/key куда-нибудь на флешку, открыть ovpn блокнотом, поправить пути в директивах ca, cert и key (и возможно tls-auth, если есть hmac), закинуть содержимое в конфиг. Вариант 2, более правильный: засунуть содержимое crt и key в ovpn: Открываем все файлы на редактирование в блокноте, смотрим в ovpn, какой файл указан в директиве ca (например ca serverca.crt). Удаляем эту строчку, вместо этого помещаем содержимое нужного файла в <ca> </ca> в конце ovpn файла. Аналогично делаем для key (<key>) и cert (<cert>). Например: Содержимое ovpn кидаем в таком виде в вебморду

Да, проверил - нормально получает более 64. Видимо на первоначальном тестовом сервере какой-то баг.. Если эти ошибки в локальном конфигурационном файле - логично. Но если это ошибки в пропушенных с сервера опциях, зачем? Традиционно провайдеры VPN пушат опции и для Win, соответственно такие конфиги будут по-умолчанию фелиться. mode server планируется, или пока нет? В текущем виде "Options error: --ipchange cannot be used with --mode server (use --client-connect instead)" Ах да, еще интересный вопрос: Возможно ли напрячь аппаратный криптомодуль обработкой AES[/hmac]? Или EIP умеет только в ESP? Или улучшения производительности не будет из-за юзерспейсности и прочих костылей сабжа?

Столкнулся с тем же, что и у @AlexUnder2010 - ругается на block-outside-dns и не запускается. При этом в моем случае опция пушится с сервера, и по мануалу "Note that pushing unknown options from server does not trigger fatal errors". После добавления в конфиг "ignore-unknown-option block-outside-dns" запустился. При включении получения маршрутов с удаленной стороны, насколько я понимаю, получает максимум 64 маршрута.

@Le ecureuil, можете пояснить автотуннели IKEv2 в 2.10, конкретно "ID у интерфейсов должны совпадать с обеих сторон, например EoIP14 и EoIP14, Gre6 и Gre6, иначе соединение работать не будет. Аналогично создаются интерфейсы в роли сервера, но тогда имена должны различаться."? Где все-таки они должны совпадать, а где - нет?

Ох ты ж.. Вот это было неожиданно. Еще не ставил.. Поддерживается и tun и tap или только tun? Как с интерфейсами дела обстоят? Правильно ли я понимаю, что OpenVPN будет даже на MT7628N, например 4G III rev. B или Start II? Интересует подключение удаленной точки с достаточной скоростью 4-8 мбит/с, если учесть что IPsec там сломан на уровне присутствующего интернет-канала (аккурат по посту @gik), и хочется избавиться от лишних флешек-entware/openwrt/etc.

Постараюсь пояснить свои мысли, на всякий случай, вдруг еще идеи придут. На данный момент отлавливаются абсолютные варианты - не поднимается PPP, перебили кабель, сдох свич, сдох провайдер. Но, кроме полного отключения, частенько встречаются ситуации, в которых пингчек будет сходить с ума и дергать туда-сюда: - после гроз/электриков где-нибудь подгорел свич/трансивер/порт и интернет как бы вроде есть, но с ощутимыми (не обязательно большими) потерями до всего. Для игр и голоса 5-10% потерь уже ощутимы. Тут нужна возможность указать процент ппотерь и минимальное количество пакетов для статистики. - - отдельный вариант - бесконечные перезагрузки или перестроения маршрутизации, в итоге инет отваливается каждые N минут. В этом и остальных случаях нужен период ожидания. - упал аплинк у провайдера, первые минуты, пока BGP разойдется, половина сайтов не открывается, частично повышенный пинг, частично не изменится. Как назло, ресурс из пингчека будет работать идеально.. Тут нужна проверка нескольких ресурсов и указание максимального пинга А сейчас просто приходится вручную тушить глючащий канал.

- добавить указание таймаута пинга/установления TCP, возможно процент потерь. Например, если у меня обычно до тестового IP пинг не выше 20, а тут вдруг выше сотни - явно с соединением что-то не так, лучше бы уйти на резерв. Возможно ввести два состояния - warn/crit, первый - при пинге выше X, второй - при отсутствии ответа/пинге выше Y. - перед переходом на резерв проверять сам резерв на работоспособность. Например резерв не работает, а у нас warn а не crit - тогда не уходить. - добавить интервалы запуска, возврата после восстановления, минимальный интервал между сменами. Например, после срабатывания сидеть на резерве минимум 15 минут, после восстановления ждать 5 минут до возврата - если за это время будет опять N провалившихся проверок - увеличивать интервал и не уходить с резерва. Или скажем давать таймаут для загрузки модема. - доработать саму проверку, об этом уже говорилось тут. Например, ввести понятие passive-active, в пассивном режиме проверяет каждые 20 секунд, если вдруг ответа нет - отправлять следующий уже через 3 секунды для ускорения проверки при недоступности. В идеале с проверкой нескольких хостов, как было описано ранее.

Под любым браузером и ОС: добавьте перед адресом роутера например a@ (имя_не_текущего_пользователя@ip) Например http://a@192.168.1.1 Вот и сброс

Проще заблокировать control-channel OpenVPN по содержимому пакета, которое особо не обфусцируется. Для раздумья: есть такие вещи как штатное openvpn'овское port-share либо мультиплексоры типа sslh, позволяющие запустить OpenVPN в TCP на 443 порту одновременно с вебсервером. Удобно для работы из всяких местечковых wifi-сетей (типа кампусовых сетей университетов), на которых до сих пор доступ в интернет через HTTP-прокси, отдающееся через WPAD. Если мультиплексор легко детектит тип до хендшейка - то и DPI сможет, и стойкость шифров тут ни при чем. Это надо либо туннелировать через SSH (впрочем, в китае и это режется - тупо скорость SSH делается такой, что в консоли работать номрмально, но как прокси - невозможно, медленно), либо через https и какой-нибудь websockets. Оверхед правда будет огого...

Opera 12?

Так никто не мешает повесить айпишник на этот сегмент и ходить через него - просто приоритет у вас неверный получается, вы приставки собираетесь изначально через CPU гонять, а интернет наоборот, по одному RGMII через LAN

Наоборот, если приставкам нужен просто свитчинг в сеть провайдера, надо сделать public-сегмент без IP на LAN-портах, и туда воткнуть и приходящий кабель и приставки, т.е. будет тупо утилизироваться свич, на ЦП заходить не будет вообще. @mehrubon, не пробовали спросить у провайдера, могут ли они дать гигабитный линк, или же только два стомегабитных (второй - для приставок)?

В простейшем виде, создаете соединение (PPTP, L2TP, L2TP/IPsec, IPIP,...), не ставя на нем галку "использовать для выхода в интернет". А дальше на странице Интернет->Прочее указываете статический маршрут через это соединение до нужного ресурса. Можно через CLI и ip route. Никаких Entware-iptables не требуется, можно хоть на Keenetic Start делать.

Все равно не работает. По 78.47.125.180:<порт вебморды> с мобилы захожу, а DNS не работает. При захвате с интерфейса ISP (фильтр по IP смарта в туннеле) вот такая картинка Она же и при DNS=192.168.0.1. Замазан мой внешний IP. В принципе, если захватывать вообще весь трафик на ISP, после прихода query роутер вроде как отправляет что-то в туннель (виден пакет в ESP), и уже затем прилетает destination unreachable.. Надо будет на рутованом смарте и чистом роутере подампить трафик...

Да, у меня Home с .0.1 (.1.1/24 - удаленная сеть через другой туннель), и по IP в X-Plore на SMB-шару роутера захожу, а вот при указании на мобильнике DNS 192.168.0.1 - DNS не работает. Пробовал и со своим DNS-сервером в Entware, и с прошивочным - резолвинг не идет. Есть один нюанс Android - для работы "Постоянный VPN" нужно, чтобы сервер был указан IP-шником (а не доменом) и в настройках соединения был вручную прописан адрес DNS-сервера. В Android 4.4-6.0 появляется ошибка с таким описанием, когда пытаешься выбрать в меню "постоянный VPN", а в Android 7 это вообще неочевидно - просто недоступна кнопка сохранить пока стоит галка "Постоянный VPN" и не выполнены требования - и гадай, что не так.

@dexter, попробуйте для EoIP заюзать недавно добавленную фрагментацию - system set net.core.eoip_allow_fragment 1 - по идее будет нормально работать при бриджевании с MTU 1500 (сам так и не попробовал еще..)

Если у вас с двух сторон белые статические IP, то Если же где-то NAT - сделать не получится, если динамический IP - придется писать скрипты обновления

Стандартная настройка Virtual IP на роутере и на мобильнике (Android 7). Все работает до тех пор, пока в качестве DNS для VPN не пытаюсь указать IP роутера (.0.1) - при этом пакеты на 192.168.0.1:53 похоже уходят в ISP (или это просто захват так показывает?). Причем к SMB-шаре на роутере с мобильника спокойно подключается, не работает только DNS. Это баг или фича?

Не подтверждаю, у меня отображается корректно, что 1 что 2 клиента

Просто для статистики: знакомый активно сидит в Discord с Giga II @ 2.08 (UPnP включен), я изредка захожу с Ultra II @ актуальная 2.09 (но UPnP выключен) - проблем со слышимостью не наблюдал. TeamSpeak последнее время уже не использую, сказать не могу, раньше проблем не наблюдалось. В обоих случаях соединение с интернетом IPoE.

Еще не успел проверить. Надо поменять железку на удаленной точке (там сейчас Giga 1 по PPTP) на поддерживающую EoIP. Ну, еще можно на столе тесты провести, но это не интересно.

Думаю одно, говорю другое *в дефолтном виде автоматическое указание MSS, а не PMTU. Могу ошибаться, но при set-tcpmss pmtu у меня через автотуннель ранее когда тестировал все сайты открывались, а вот через VirtualIP без ручного указания MSS те же сайты не открываются.

В таком случае хотелось бы в дефолтном виде автоматическое указание pmtu, а то получается вкладку настройки VirtualIP упростили, но лезть в консоль все равно приходится

@r13, у меня нормально работает VirtualIP совместно с транспортом IKEv2 AES-128/SHA1/modp2048, в том числе нормально ходит из VirtualIP в другой.