Le ecureuil

Хоть бы отписали в чем было дело, чтобы другие тоже не наступили на эти грабли.

Насчет proposals примерно вот так: IPSECURE_IKE_MEDIUM_( "aes256-sha1-modp1536,aes128-sha1-modp1536,3des-sha1-modp1536," "aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024"); IPSECURE_SA_MEDIUM_( "aes128-sha1,aes256-sha1,3des-sha1," "aes256-sha1-modp1536,aes128-sha1-modp1536,3des-sha1-modp1536," "aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024"); IPSECURE_SA_MEDIUM_3DES_( "3des-sha1,aes256-sha1,aes128-sha1," "aes256-sha1-modp1536,aes128-sha1-modp1536,3des-sha1-modp1536," "aes256-sha1-modp1024,aes128-sha1-modp1024,3des-sha1-modp1024"); IPSECURE_SA_MEDIUM_PFS_( "aes128-sha1-modp1024,aes128-sha1,aes256-sha1,3des-sha1," "aes256-sha1-modp1536,aes128-sha1-modp1536,3des-sha1-modp1536," "aes256-sha1-modp1024,3des-sha1-modp1024"); IPSECURE_SA_MEDIUM_3DES_PFS_( "3des-sha1-modp1024,3des-sha1,aes256-sha1,aes128-sha1," "aes256-sha1-modp1536,aes128-sha1-modp1536,3des-sha1-modp1536," "aes256-sha1-modp1024,aes128-sha1-modp1024"); IPSECURE_IKE_LOW_( "aes128-sha1-modp1024,3des-sha1-modp1024,des-sha1-modp1024," "aes128-sha1-modp768,3des-sha1-modp768,des-sha1-modp768," "aes128-md5-modp1024,3des-md5-modp1024,des-md5-modp1024," "aes128-md5-modp768,3des-md5-modp768,des-md5-modp768"); IPSECURE_SA_LOW_( "des-md5,aes128-sha1,3des-sha1,des-sha1,aes128-md5,3des-md5," "aes128-sha1-modp1024,3des-sha1-modp1024,des-sha1-modp1024," "aes128-sha1-modp768,3des-sha1-modp768,des-sha1-modp768," "aes128-md5-modp1024,3des-md5-modp1024,des-md5-modp1024," "aes128-md5-modp768,3des-md5-modp768,des-md5-modp768"); IPSECURE_SA_LOW_PFS_( "des-md5-modp1024,aes128-sha1,3des-sha1,des-sha1,aes128-md5,3des-md5," "aes128-sha1-modp1024,3des-sha1-modp1024,des-sha1-modp1024," "aes128-sha1-modp768,3des-sha1-modp768,des-sha1-modp768," "aes128-md5-modp1024,3des-md5-modp1024," "aes128-md5-modp768,3des-md5-modp768,des-md5-modp768"); IPSECURE_IKE_STRONG_( "aes256-sha1-modp2048,aes128-sha1-modp2048," "aes256-sha1-modp1536,aes128-sha1-modp1536"); IPSECURE_SA_STRONG_( "aes256-sha1-modp1536," "aes256-sha1-modp2048,aes128-sha1-modp2048," "aes128-sha1-modp1536"); Поскольку используется IKEv1, то клиент отсылает только первый proposal из списка, а сервер сравнивает proposal из запроса со списоком и принимает любой подходящий. Примерно так, только учтите, что туннель всегда будет в состоянии up, если он не работает поверх IPsec, и потому резервирование с ним будет работать странно, хотя зависит от числа в ip global. DHCP проходит насквозь через EoIP, как и любой другой трафик L2. Для фильтрования используйте ebtables из entware или что-то в этом духе, модули ядра все присутствуют в компонентах.

Ога, поправил.

Мануал написан, все обсуждение пока давайте вести в той теме.

Начиная с прошивки 2.08.A.10.0-0 появилась возможность создавать туннели EoIP, GRE, IPIP как в простом виде, так и в сочетании с IPsec. GRE и IPIP-туннели - это туннели уровня L3, на которых видны IP-адреса обоих сторон. Они представляются в системе в виде интерфейсов GreX и IPIPX, и через них можно прокидывать маршрутизацию (в том числе и default route) точно также, как и через любые другие интерфейсы. Плюс ко всему у них также есть security level. Туннели GRE совместимы со всеми Zyxel ZyWall, Mikrotik, а также Linux-роутерами. В теории должно работать вообще со всем оборудованием, которое умеет GRE, в том числе и Cisco, Juniper, etc. Компоненты называются соответственно gre и ipip. EoIP-туннель - это туннель уровня L2, потому обмен через него идет на уровне Ethernet-кадров. При этом видны все mac-адреса, и можно объединить две локальные сети на уровне L2 через Интернет при помощи этого типа туннеля. На нем кроме IP можно гонять любой трафик, в том числе и ARP, DHCP, PPPoE, IPv6, etc. По умолчанию в туннеле при смене security level на private/protected будет работать сканирование подсети посредством ARP. Туннели EoIP разработаны Mikrotik, потому присутствует совместимость с ними, а также с Linux-роутерами, которые умеют EoIP. Компонент называется eoip. Важно понимать, что сами по себе EoIP, GRE и IPIP-туннели являются connectionless, то есть невозможно понять находится ли в работоспособном состоянии туннель или нет. Мы можем только настроить обе стороны и после этого проверить передачу. Плюс ко всему эти туннели в чистом виде никак не проходят через NAT, поэтому сеть между конечными точками для этих туннелей должна обеспечивать прямую связность без трансляции адресов. GRE, IPIP и EoIP-туннели работают непосредственно поверх IPv4-протокола, EoIP и GRE используют номер IP-протокола 47, IPIP использует номер IP-протокола 4. Настройка GRE/IPIP туннеля очень проста: (config)> interface IPIP0 (config-if)> tunnel destination router1.example.com (config-if)> ip address 192.168.100.1 255.255.255.0 (config-if)> security-level private (config-if)> up На другом конце туннеля задаются "зеркальные" настройки: (config)> interface IPIP0 (config-if)> tunnel destination 8.6.5.4 (config-if)> ip address 192.168.100.2 255.255.255.0 (config-if)> security-level private (config-if)> up После этого можно попробовать пропинговать с любой из сторон адрес удаленной стороны в туннеле (это будет подсеть 192.168.100.0/24) для проверки работоспособности туннеля. Стоит обратить внимание, что в качестве destination можно указать как доменное имя (через Cloud-режим в KeenDNS работать _НЕ_ будет), так и IP-адрес удаленной стороны (WAN-интерфейса устройства). Для GRE имя интерфейса будет Gre0. В случае с EoIP настройки абсолютно те же, кроме двух моментов: - можно задать mac-адрес интерфейса. - необходимо задать EoIP tunnel ID, идентификатор туннеля (число в диапазоне от 1 до 65535), причем на обоих концах он должен совпадать. Команды будут выглядеть так: (config)> interface EoIP0 (config-if)> tunnel destination router1.example.com (config-if)> tunnel eoip id 1500 (config-if)> ip address 192.168.100.1 255.255.255.0 (config-if)> security-level private (config-if)> up Другой конец туннеля: (config)> interface EoIP0 (config-if)> tunnel destination 8.6.5.4 (config-if)> tunnel eoip id 1500 (config-if)> ip address 192.168.100.2 255.255.255.0 (config-if)> security-level private (config-if)> up После этого все должно работать. Для туннелей MTU интерфейса автоматически вычисляется на основе интерфейса, через который будет проходить трафик, но также его можно и задать руками через команду interface ip mtu. Более того, L2-интерфейс EoIP можно засунуть в Bridge для объединения локальных сетей. Для этого на обоих сторонах нужно настроить EoIP-интерфейс без IP-адреса, и затем включить в Bridge Home: (config)> interface Home (config-if)> include EoIP0 после этого можно пытаться связаться с хостом из одной домашней сети с хостом из другой домашней сети. В случае установки компонента ipsec появляется возможность защищать эти туннели при помощи IPsec, причем как в автоматическом, так и в полностью ручном режиме. Ручной режим здесь описан не будет, поскольку продвинутые юзеры сами всегда могут сперва настроить IPsec с правильным режимом, а затем поверх IPsec поднять туннель. В случае автоматической настройки решается сразу несколько проблем ручного режима: - правильно выставляется MTU - соединение становится connection-oriented, и нужно выбирать, кто из концов туннеля становится клиентом, а кто сервером - автоматически решается проблема с проходом через NAT, поскольку используется IPsec NAT Traversal, при котором весь туннельный трафик превращается в поток UDP на порт 500/4500 - шифрование и проверка целостности данных Компонент IPsec добавляет следующие настройки к туннелям: interface ipsec preshared-key <key> - PSK для шифрования interface ipsec encryption-level <level> - уровень шифрования, по умолчанию задан таким, чтобы охватывал максимально большое число устройств и ускорялся аппаратно. Можно не менять. Поскольку IPsec разграничивает клиента и сервер, то теперь для настройки клиента (инициатора, той стороны, которая будет пытаться установить соединение) необходимо использовать команду interface tunnel destination, а для включения режима сервера (той стороны, которая будет отвечать на попытки установления соединения) необходимо использовать команду interface tunnel source. Пример настройки EoIP туннеля с IPsec, где сторона с WAN-адресом 8.6.5.4 является сервером: Сервер: (config)> interface EoIP0 (config-if)> tunnel source ISP (config-if)> tunnel eoip id 1500 (config-if)> ipsec preshared-key mytestingkey (config-if)> ip address 192.168.100.1 255.255.255.0 (config-if)> security-level private (config-if)> up Клиент: (config)> interface EoIP0 (config-if)> tunnel destination 8.6.5.4 (config-if)> tunnel eoip id 1500 (config-if)> ipsec preshared-key mytestingkey (config-if)> ip address 192.168.100.2 255.255.255.0 (config-if)> security-level private (config-if)> up Во всех случаях важно, чтобы IPsec PSK совпадал на обоих концах соединения. При этом в команде interface tunnel source можно указать как интерфейс-источник, так и IP-адрес, на котором будет "висеть" сервер. Однако предпочтение отдается интерфейсу, поскольку в данном случае вся перенастройка при смене адреса и прочих событиях будет происходить автоматически. Также можно указать interface tunnel source auto, для автоматического переключения сервера при смене WAN-интерфейса. Известные ограничения: - туннели на базе EoIP/IPsec и GRE/IPsec принципиально несовместимы с PPTP-подключениями из-за использования одного и того же протокола GRE. В этом случае остается использовать всего лишь один доступный вариант: IPIP/IPsec. Важно: - не забывайте про isolate-private: Для тех, кто будет включать EoIP в Bridge: Правильно делать в таком порядке - выставить вручную MTU 1500 на EoIP, и забриджевать его. Тогда все будет работать нормально, в том числе и фрагментация. Иначе на EoIP выставится MTU < 1500 и будут проблемы. Команды eoip_allow_fragment на версиях 3.x нет, она устарела. Фрагментация включается автоматически. Всех желающих прошу подключиться к тестированию, по мере того, как дело будет продвигаться, мануал будет дополняться.

В особенностях работы WiFi лучше всего разбирается @Padavan, и если он сказал что должно работать нормально - я больше ничего от себя добавить не могу.

10 Мбайт/сек - это довольно легко для этого CPU, вот рубеж в 50 Мбайт/сек был бы достижением.

В процессе, скоро будут мануалы.

Пока нет.

Нет, и это не нужно. У вас явно проблема с poptop, с ним и разбирайтесь. Скорее всего он рассчитан на другую реализацию mppe, которая была в виде патча для ядер 2.4 и 2.6.21-22-23 с поддержкой mppe56. Эта реализация в итоге не вошла в официальное ядро linux (и нами тоже добавлена не будет), а была принята другая реализация с поддержкой только mppe40 и mppe128. Попробуйте поизучать свою версию poptop на тему, какая же из ядерных реализаций ему нужна.

И в настройках Kerio, и в настройках Keenetic. Причем это должна быть валидная маска ( 192.168.170.0/23, она же 192.168.170.0/255.255.254.0 )

Пока прописать роут нельзя. Скоро появятся EoIP, GRE и IPIP-туннели поверх IPsec, и там все будет можно. А расширять маску нужно с обоих сторон, и тогда все заработает.

IPsec не имеет интерфейсов.

Откуда берутся 3 секунды - читайте в моем посте выше, там указаны все тайминги.

Если совсем просто, то mark нельзя трогать совсем, если настроен IPsec или включен ppe software. Если же метки менять/ставить, то в случае с IPsec могут быть рандомные глюки, в случае с ppe software он просто не будет работать.

Если он в бинарном виде и собран под x86/x86_64, то его запустить невозможно из-за совершенно другой архитектуры процессора.

Можно еще с Udpxy подобное провернуть.

Снимите галку "Использовать для выхода в Интернет" со всех интерфейсов, и пропишите вручную через web роут до openvpn сервера через нужный интерфейс. Если openvpn настроен так, что создает default route, то как раз получите желаемое.

Он вкомпилирован в ядро, поэтому отдельно не видно. При запуске сервера он должен активироваться автоматически.

А вас устроит popup-уведомление на телефоне от мобильного приложения при выходе новой прошивки? У нас же уже есть приложение.

Он уже включен в ядро в рамках PPTP-подключения. Его исходники вы можете увидеть тут: github Другого у нас нет.

Потому что он сейчас в глобальной переделке, а в 2.07 он был вообще незаявлен и попал туда случайно. В 2.08 все вернется на место.

Прошивка может переписать конфиг и перегрузить его в любой момент, потому это все рисковые операции

1. Скорее всего никогда, DSL остался на прошивке 2.05, в котором нет IPsec. 2. Если вы про Keenetic 4G первого поколения (белый), то на нем тоже никогда - он остался на прошивке 2.04. 3. На Viva можете поставить delta-прошивку из 2.07 или draft из 2.08 (http://forum.keenetic.net/announcement/5-где-взять-тестовые-прошивки/), там все есть и работает, и даже обновляется через штатную страницу компонентов. 4. Там, где его нет, поднять его практически невозможно. У меня нет идей как вы это могли бы сделать разумно и просто.