KorDen

В совокупности с советом в соседней теме про переход на 2.09 и отрепорченным вами же багом кажется получается ой - в 2.08 работает udp-port-preserve, но нет ip statis in out / DHCP-опций; а в текущей бете 2.09 получается поломан udp-port-preserve (не уверен, т.к. проверить сейчас негде, везде 2.10)

У кинетика по умолчанию команда ip nat Home подразумевает, что все что попало на роутер (L3) из сегмента Home и уходит с кинетика (не важно, куда), надо натить. Трафик до циски идет по L2, на роутер не заходит. Ставьте beta 2.09, там будет и выдача опций DHCP и исходящий интерфейс для ip static. Хотя, если у вас на WAN кинетика статичный IP и это единственный WAN, можно сделать на 2.08 ip static Home 1.2.3.4 (где 1.2.3.4 - IP WAN-интерфейса) NAT Loopback будет только если ходить на ресурсы, проброшенные на внешние интерфейсы по их айпишникам.

Что-то сходу не нашел - предлагали уже реализовать функционал белых-черных списков для входящих вызовов? Если нет - реквестирую Желательно per-line.

Столкнулся тут с некритичной проблемой на 2.10.A.3.0-4, которую не было возможности толком проверить с селфтестами, т.к. надо было срочно. Ultra II, уже настроены VirtualIP и автотуннель IPIP IKEv2. Giga II, с дефолтных настроек настроен интернет-wifi, перезагружен. Создаю новый автотуннель между ними (NAT нет), условный конфиг: До первой перезагрузки Giga II после настройки туннеля IPsec взлетал, но пакеты по туннелю не ходили - в логах появлялось только EIP inbound для гиги (outbound для ультры), а outbound не появлялось. После перезагрузки гиги взлетело. Такое ощущение, что что-то недоинициализировалось находу (это было первое IPsec-соединение на гиге получается)

Как по мне, пригодится не только для таких хитрых проверок - опять же, в случае глюков у провайдера (точнее, скорее у аплинков) пакет может неестественно блуждать по куче хопов, или наоборот, какая-то железка внезапно начнет отвечать на пинг, поэтому ограничение TTL сверху и снизу в качестве одного из вариантов проверки (хоть и не идеального - ведь может поменяться что-то со стороны проверяемого сервера) вполне сгодится. Правда тут уже надо уже функциональный граф пилить, чтобы каждый сам делал оптимальную для себя схему, но это уже как-то перебор для SOHO наверное Типа, я хочу следующее: - Пингуем 1.1.1.1, 2.2.2.2 каждые 20 секунд L=64, 3 пакетов (таймаут = 100ms, ожидаемый TTL=54..49); - Проверяем TCP на 1.2.3.4:567, 5.6.7.8:123 каждые 60 секунд, таймаут = 500ms - - хоть один TCP или ICMP не прошел проверку: принудительно пингуем 1.1.1.1 и 2.2.2.2 L=1000 10 пакетов таймаут=50ms, ожидаемый TTL=54..49, проверяем резерв на работоспособность [граф резерва] - - - основной канал нестабилен, резерв стабилен - уходим на резерв. Основной канал не работает вообще, резерв работает хоть как-то - уходим на резерв. Резерву тоже хана - не дергаемся понапрасну А кто-то хочет что-то другое....

Сейчас должна быть идентификация всех пользователей, WiFi без пароля и без авторизации по SMS/звонку (бесплатным) сейчас не найти. А если найдется - прикроют соответствующие органы, если заметят. Поэтому компонент вполне востребован в SOHO может быть, особенно если хотспот бриджевать с портами. Скажем, у нас до появления этих законов продолжительное время работала связка Giga II как проводной роутер + несколько ТД. Несколько десятков пользователей на соточном канале, 3-4 порты - сегмент Guest на свичи на ТД и клиентские розетки, 1-2 - Home на свичи для своего оборудования. После введения закона пробросили 3-4 порты тэгированым вланом в WAN, провайдер свой сервис авторизации продавал. Еще стоит заметить, что Captive Portal - это в первую очередь аутентификация клиентов через RADIUS, поэтому возможны нестандартные варианты использования - к примеру, этакий колхозный WPA2-Enterprise без необходимости колдовства с сертификатами на клиентских устройствах, что может быть актуально, если сотрудники подключаются со своих всевозможных устройств к местному WiFi. DC++ и раздача с облаков - это тоже вполне узконаправленные фичи. Каждому свое.

2.10 draft, аналогично на 2.09.B.0.0-1 beta А вот на v2.08.C действительно как у вас

Он не активен если стоит IKEv1, при IKEv2 он доступен

Что в данном понимании сессия, если говорить например о торрентах, где сотни-тысячи соединений по UDP до разных хостов? В режиме черного списка, когда он начинает давить торренты - всегда, или только при наличии другого трафика выше определенного порога?

Ну т.е. per-host, даже без отделения условных 80/443 и игрового UDP с этого же хоста? Плохо...

Мой опыт с QoS на кинетиках остался еще на уровне NDMSv1.11 - тогда там была на тот момент непонятная галка "Авто-QoS", которая вроде делала какую-то магию, но из-за нее скорость провисала. На этом тему QoS на роутерах я для себя закрыл - нынешние тарифы позволяют не задумываться о полосе для серфинга, даже гоняя торренты или загрузки игр на больших скоростях, а реальную QoS-маркировку исходящих пакетов большинство провайдеров игнорируют. Но все-таки задумался, а что сейчас представляет из себя IntelliQoS? Конкретно интересуют используемые модели - Ultra II, Giga II (везде гигабитный аплинк, но на некоторых тарифная скорость 70-100), Extra II (и другие на 7628). Слышал, что в том же 7621 вроде есть аппаратная маркировка (а как с этим на 6856 и 7628, и что можно получить?), читал про ограничение скорости торрентов, но инфа возможно устаревшая. Есть ли смысл от него на гигабитных линках и тарифах за сотню? В моем представлении, тяжелым загрузкам должна отдаваться вся (95%) полоса до тех пор, пока нет ощутимого другого трафика, но как я понимаю, на данный момемт они режутся на 80%. Или это уже не так? Можно ли эти пороги настроить?

@beugene, в 2.09 можно указывать исходящий интерфейс для ip static. Например "ip static Home Lte0"

Это понятно, скорее вопрос, как будут (предположительно) вести себя устройства с поддержкой 5G, если на основном маршрутизаторе включен Band Steering и на удалении есть точка, дублирующая основную, без включенного Band Steering. Или два роутера с одинаковыми сетями и включенным Band Steering на обоих. Будет ли это вообще работать, или все будут сходить с ума при удалении от одного роутера и приближении к другому?

Вообще, это два отдельных вопроса, но попробую объединить в одну тему. Вопрос 1: Может ли / будет ли работать Band Steering для гостевой сети, при условии что параметры сети WifiMaster1/AccessPoint1 совпадают с WifiMaster0/AccessPoint1? На текущий момент у меня роутером создаются условные Main, Main5, Guest, Guest5. Хочу объединить и чтобы все было красиво и без глюков. Вопрос 2, основной (независимо от вопроса 1, гостевую сеть не рассматриваем): Есть основной роутер (условно Ultra II), расположенный в месте оптимального приема по всей квартире/дому как для 2.4, так и для 5. Хочется получить стабильную сеть во дворе. Т.к. с соседних многоэтажек во дворе прилетает пара десятков других точек - 2.4 во дворе бесполезен, только 5 ГГц, но он во двор не добивает. Для этого предполагается поставить на окне условный Air (или даже два, по обе стороны дома), на котором будет включена только точка 5 ГГц (сам он будет подключен кабелем к Ultra II, никаких репитеров по воздуху). В идеале - все точки (2.4G/5G основного и 5G дополнительного) будут иметь единые настройки для максимально бесшовной работы (насколько это возможно в SOHO). Собственно вопрос - как в принципе лучше все настроить, стоит ли включать Band Steering на основном роутере, или он в таком случае будет бесполезен? Или не заморачиваться, оставить отдельные (по названию) сети 2.4G и 5G, и клиентов с поддержкой 5G подключать только к 5G (которая будет состоять из двух-трех точек с едиными настройками)?

В таком случае предлагаю выложить сюда селф-тест в момент передачи скрытым постом.

Насколько я понимаю, данные получается передаются через L2TP VPN? Не помню, есть ли в 2.06 L2TP/IPsec с аппаратным ускорением... В общем и целом я бы посоветовал поставить 2.08 delta и перейти с L2TP на IPIP поверх IPsec, или даже просто попробовать чистый туннельный IPsec, без L2TP, если конечно через это соединение не нужно выходить наружу

Я в курсе, и активно за этим слежу, но тот кусок сети пока не рискну переводить... Да и одну из железок для IPsec придется менять... Впрочем, как чип начнет пригорать, так или иначе придется думать о замене...

Я так и понял Мне не критично, это я обнаружил, чисто случайно ткнув на закладку сервака с внутренним IP, находясь в сети Giga, и потом уже вспомнив (и проверив конфиги), что маршрут-то через PPTP есть еще со времен, когда об IPsec/туннелях речи не было и все цеплялись по PPTP, поэтому должно было подключиться. Да, меня не автотуннели, IPIP ходят через ручной IKEv2-транспорт.

(туннели - черными, цветными - пути пакетов) Есть IPIP от Giga II до сервера. С сети микротика, подключенного к Giga II по IPIP, спокойно заходит на сервер по туннелям (Mikrotik -> (IPIP) -> Giga II -> (IPIP) -> Linux). С Giga, подключенной к Giga II через PPTP-сервер Giga II, доступа по внутреннему айпишнику сервера (т.е. Giga -> (PPTP) -> Giga II -> (IPIP) -> (Linux)) нет. Пинги Linux от Giga такое ощущение что теряются в недрах Giga II, их не видно на захватах IPIP, ISP, Home. При этом в интернет через PPTP можно спокойно ходить, нет доступа именнок туннелям. Прежде чем все ломать, переводя на 2.10 и делая селфтесты, хочется понять - с клиента VPN-сервера в принципе должна быть возможность ходить в туннели?

У вас белый IP? 192.88.99.1 пингуется?

Смысл UDP/53 мне ясен (отчасти), но у некоторых провайдеров UDP/53 полностью перенаправляется на свои серверы, в итоге работать не будет.

Речь не об OpenVPN на 443 порту, а о детексте наличия OpenVPN со стороны сервера, на который вы заходите - https://habrahabr.ru/post/216295/ + https://witch.valdikss.org.ru/ @T@rkus, с такими параметрами mtu я бы не рекомендовал использовать TCP, тем более если у вас UDP нормально работает. Лучше всего использовать UDP на 1194 порту, 53 и 443 используются для специфических случаев (выход через HTTP-прокси и т.п.)

o_O Штатного функционала Windows по синхронизации уже недостаточно?! А вообще, читайте про Entware в соседнем разделе..

А на эти ошибки и я натыкался. нажмите еще раз "сохранить" и наверняка будет уже без них. Похоже баг, периодически при сохранении он почему-то пытается добавить маршруты еще до установки IP или чего-то еще. Судя по сайту, там должны были быть готовые разные ovpn-файлы. Но вообще, достаточно подправить строчку remote, например просто уберите 53 в конце (подключится на дефолтный 1194), или замените на 443. Хоспаде, ну и писатели у этих впн-сервисов... Или это типа шобы враг не догадался, что впн?

Так а какие именно файлы у вас указаны в ca, cert и key в ovpn-файле? с 4k или без? Я так понимаю просто файлы - длина ключа 2048bit, а которые 4k - 4096bit. Чем больше длина ключа, тем типа безопаснее и тем медленее. Это уже на вкус и цвет. И да, лучше юзайте 443 или 1194, 53 порт пров может перенаправлять к себе