Le ecureuil

100+ Мбит/сек, да. Видимо у вас VPS не выдерживает нагрузку (что вполне реально, так как у вас используется юзерспейсный xl2tpd), или провайдер.

Да, возможность настроить резервирование в IPsec была всегда. Только она реализована в cli. > crypto map <test> set-peer 201.201.1.1 > crypto map <test> set-peer-fallback 211.211.1.1 > crypto map <test> fallback-check-interval 600 Приоритет будет у 201.201.1.1, если с ним пропадет связь, то перейдет работать на 211.211.1.1, но раз в 600 секунд будет в фоне проверяться работоспособность 201.201.1.1, и при появлении связи с 201.201.1.1 все вернется туда.

Ок, подумаем.

А почему вы так против SL = public? Именно public включает source NAT, без него у вас в IPIP все полетит с оригинальным адресом и будет ой.

up

Создайте отдельную тему в "Развитии", подумаем.

При чем тут вообще Zywall? Мы вроде Keenetic обсуждаем.

Там все правильно написано, кроме одного - пакеты openwrt нужно пересобрать так, чтобы они смогли запуститься на устройстве.

Если все пингуется (в том числе и полноразмерными пакетами с MTU == MTU интерфейса), то проверьте как работает DNS. DNS пока идет по системной таблице, и может разрешать имена через другие интерфейсы. Знаем об этой ситуации, работаем над ней, но пока сложно сказать когда точно будет сделано - слишком много завязано на DNS.

По первому пункту можно поподробнее? Где именно у вас настроен tunnel broker, на Keenetic, или на устройстве за ним?

Нужен policy routing для IPsec - используйте IPIP/GRE/EoIP over IPsec туннели.

Перед тем, как мы будем копировать функционал из Cisco за $10k+, давайте сначала хотя бы базовые сценарии отладим.

Да.

interface CdcEthernet0 up / down

NAS подключается как NFS, CIFS, или еще как-нибудь?

Эти разделы никак не связаны между собой кроме того факта, что если на устройстве нет USB-разъема, то и раздела /storage тоже нет.

Пока на клиенте не сделаете туннель с SL public и ip global > 0 и не пропишете default route на него через ip route - никак.

Никак, такой функционал не закладывался.

Включайте system debug, отключайте openvpn, снимайте self-test и кидайте сюда. Посмотрим, что не так.

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

Если подскажете, как дешево (в смысле нагрузки на CPU) отличить каждый TCP/UDP поток торрента от TCP/UDP потока неторрента, то подумаем. Пока у меня идей нет.

Может быть, но пока давайте хотя бы вариант с раскидыванием хостов и встроенных в Keenetic сервисов по нужным политикам доведем до ума. Ну и load-balancing на несколько каналов мне видится тоже приоритетнее.

Там не совсем точная информация, особенно если хосты за рипитером.

С антеннами все проще - они внутри сделаны на печатной плате и с высокой точностью + усилки и выходной тракт специально калибруется в полном сборе с уже припаянными антеннами для максимальных показателей. Потому замена антенны на другую во-первых только ухудшит характеристики тракта, а во-вторых потери в разьеме будут очень сильные - опять падение характеристик. Это все в теории можно побороть, но цена заметно возрастет, сами понимаете. Насчет умирающих усилков - у меня активно используется пара отладочных плат под разрабатываемые устройства - это вообще голые платы, даже без радиаторов и тем более без антенн WiFi. Тем не менее, до сих пор все живы (например Ultra II с 2015 года, пережившая несколько тысяч перепрошивок) - в целом выходной тракт WiFi неплохо защищен от таких издевателств. PoE на Ultra II точно не планируется - это устройство 2014-2015 года разработки, оно уже финализировано и никто железную часть перерабатывать не будет. Если будут еще какие вопросы - пишите, упоминайте меня, постараемся решить что возможно.

Если прошивка свежая (2.11 и выше), то лучше смотреть на вывод show ip hotspot или show ip neighbour. Там более полная и точная информация.