leo249

Ну вот так сразу "никак" :} То что один человек попортил, другой всегда сможет починить! Пока суть да дело, я поинтересовался вопросом в других источниках на скорую руку и понял, что самое простое решение - нужен комплект service tag - serial number - password на загрузку обновлений что лежат чуть ли не в явном виде в дампе флэши. Да собственно и нужно переложить этот дамп с 1212 на 1213 и будет Вам клон 1212ого в теле 1213 со всеми вытекающими. Да он будет неприятно отстукиваться в Кинетик тем же сервистагом и серийником, что и первый, и возможно, одновременно они работать будут сильно нехорошо, особливо с доменным именем и прочими связанными с облаком фичами. Что-то из этого можно отключить, что-то не использовать или не использовать одновременно. Ну и многим все эти "облачные" фичи кинетика и доменные имена не нужны вовсе, много старых 1212, 1211 ых уже выходят из использования и их данные можно спокойно использовать. Через меня прошло несколько штук 1211, 1212 сожалею, что не снял дампы флэшин! Как в руки попадется 1212 - сниму дамп и как будет возможность проверю на 1213. Да, господам из Кинетика, конечно, мой пост очень не понравится. А вот мне очень не понравилось, что они от своей дикой жадности и желания выбивать деньги из покупателей и побольше, злонамеренно кастрировали популярную дешевую модель!! Я не думаю, что я как покупатель должен заткнуть себе рот и молчать, когда меня пытаются "обуть"! Как известно - "клиент всегда прав" и если клиент говорит, что изуродованная намеренно модель ему не нравится и требует вернуть назад отрезанный функционал, то так и должно быть.

На "новых" версиях Keenetic "4G", "Launcher" недобрые производители отрезали файловый функционал, чтобы заставить покупать дорогие модели. Процессор, память и пр. хардвер, разумеется никак не изменился с предыдущих полноценных версий. Пробовал ли кто его восстановить? Я так понимаю надо как-то в прошивке сменить код модели KN-1213 на предыдущую KN-1212 и компоненты файловой системы должны появиться в апдейте? Не то, чтобы я так хотел сэкономить гроши, но мне нужна в дорогу модель в малогабаритном корпусе 4G, а не гробы следующих моделях и уж точно не нужны 1000Мб порты! Если файловый функционал не восстановить никак, то тогда мне проще купить неурезанную KN-1212, вместо урезанного "новогоднего подарка" от Keentic пока 1212 еще есть в продаже.

>Если интерфейс sstp поднять выше всего остального, или назначить конкретному клиенту политику у которой sstp в приоритете, трафик никуда не идет. Простите, а что у Вас означает "ЕСЛИ"?? А если не "если" - то идет? Так когда идет и когда не идет? Вы описываете проблему, и чтобы ее воспроизвести нужны точные условия, потому что в других условиях SSTP клиенты в кинетике работают у сотен людей абсолютно исправно. У меня более 5 разных SSTP в Кинетик, несколько клиентов, несколько серверов работают 24 часа в сутки, "по политикам в приоритете" перекачивают трафик с удаленных видеокамер и никаких проблем не имеется! Проблемы имеются только в конкретных условиях на конкретном VPN провайдере и конкретном интернет провайдере, да еще возможно зависят того в какой стране VPN сервер находится.

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

Хотел бы добавить свой опыт потому же вопросу - отказ в пропуске трафика через тоннель SSTP запущенного с Keentic, при том, что работает успешно с Windows через этот же Keenetic! Имею ту же ситуацию уже на надежном ПЛАТНОМ VPN (Hide.me), который на Windows дает 100 Мбит, на Keentic - 0. Собственно то же происходило и на другом протоколе - OVPN и проблема ЗАВИСИТ ОТ ИНТЕРНЕТ ПРОВАДЕРА!! То есть на некоторых провайдерах отсутствует. Есть серьезное подозрение на DPI провайдеров, но непонятно как тогда они отличают пакеты идущие от Keentic от пакетов исходящих из Windows? По TTL? Но в одном из тестов я имел 4G модем c TTL фиксированным на 64 в нем, и тем не менее это не помогло. Подскажите, в чем еще может быть разница за которую может цепляться DPI и какие можно провести эксперименты для выяснения хотя-бы в каком месте проблема? Если это не DPI, то что??

Имеющаяся в Кинетиках защита серверов от перебора паролей путем блокировки конкретного IP в современных реалиях массовой зараженности интернета бот сетями НЕЭФФЕКТИВНА!! Поэтому я бы настоятельно рекомендовал разработчикам или просто ограничить число логонов в минуту или включать защиту от частоты логонов при превышении порога по количеству. НЕОБХОДИМО ОГРАНИЧИВАТЬ ЧИСЛО ЛОГОНОВ В МИНУТУ! Ни в каком SOHO рутере не потребуется обслуживать скажем 60 подключений к серверу в минуту! Обычно требуются 1-2 подключения в минуту, не больше! Тем не менее VPN сервера в Keenetic готовы обрабатывать и 100 подключений и это массивная дыра в безопасности! Куча "сканнер сервисов" предлагают результаты сканирования по всему диапазону IP4 в виде списков IP с серверами, эти списки используют бот сети для массовых распределенных на тысячи IP брут форс атак, от которых Kinetic никак не защищен. Скорость перебора паролей ограничена только скоростью реакции сервера в Keenetic! Учитывая массу простых логинов/паролей, что часто устанавливают администраторы в рутерах и быструю реакцию сервера на логон, подобного рода атаки легко дают результаты и зараза растет! Я лично наблюдаю в своих логах множественные координированные РАСПРЕДЕЛЕННЫЕ атаки перебором логинов и паролей с сотен и тысяч различных IP. причем сервер обрабатывает каждую попытку перебора за доли секунды вот кусок лога: ppp-pptp: ppp5:: connect: ppp5 <--> pptp(45.78.7.244 (45) ) ppp-pptp: ppp5:: mschap-v2: user not found ppp-pptp: ppp5:vpn: vpn: authentication failed ppp-pptp: ppp5:: pptp: disconnected ppp-pptp: pptp: new connection from 104.255.69.56 (104) ppp-pptp: ppp5:: connect: ppp5 <--> pptp(104.255.69.56 (104) ) ppp-pptp: ppp5:: mschap-v2: user not found ppp-pptp: ppp5:aysylu: aysylu: authentication failed ppp-pptp: ppp5:: pptp: disconnected ppp-pptp: pptp: new connection from 45.78.6.34 (45) ppp-pptp: ppp5:: connect: ppp5 <--> pptp(45.78.6.34 (45) ) ppp-pptp: ppp5:: mschap-v2: user not found ppp-pptp: ppp5:vera: vera: authentication failed ppp-pptp: ppp5:: pptp: disconnected ppp-pptp: pptp: new connection from 45.78.5.68 (45) ppp-pptp: ppp5:: connect: ppp5 <--> pptp(45.78.5.68 (45) ) ppp-pptp: ppp5:: mschap-v2: user not found ppp-pptp: ppp5:matvey: matvey: authentication failed Учитывая тот факт, что я наблюдаю массированные атаки с сотен различных IP не предоставляя никому никаких публичных услуг (у меня сугубо личные VPN сервера, связывающие дачу, дом и квартиру), и мой IP ничем особенно не "засвечен", следует предположить, что сейчас, инфицированность интернета бот сетями вышла на совсем другой уровень, чем ранее, и такие атаки ОЧЕНЬ распространены, ДАЛЬШЕ БУДЕТ ХУЖЕ, и Вы отстаете от реалий жизни!! Просто мало кто из Ваших юзеров это замечает. В моей конкретной распределенной брутфорс атаке на PPTP в логах видно, что идет перебор по списку часто используемых логинов, причем зараза шла с одного конкретного крупного канадского хостинг провайдера "Cluster-Logic Inc" подразделение "4974 Kingsway, Unit 668" (IP резолвятся на 16.clouds.com) имеющего около 10 разных диапазонов по несколько тысяч IP, и как только я заткнул все диапазоны, атака пропала. Пока хоть один диапазон был открыт, оттуда продолжался перебор паролей. Можете предположить какое огромное количество зараженных компьютеров и они уж точно не на меня лично нацелились! Леонид.

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

Да, спасибо, помогло. Я подозревал, что дело в домене, но не хотел его менять.

Уважаемые гопода! Zyxel 4G III rev.A обновился c последней официальной 2.08 до delta версии 2.16.D.6.0-1 Появился SSTP сервер а насройках. НО! Включить его не дает, пишет: "To enable the SSTP VPN server, you need to: Register a KeenDNS name" Но Keen DNS вида xxx.mykeenetic.com как было так и есть и работает в Cloud режиме! Запустил в CLI ACME GET для этого домена, успешно получил сертификат, без проблем захожу по https:// туда через облако, вижу раутер а Cloud портале.... Но SSTP сервер никак не включить! Посоветуйте, как это побороть?? Посмотрел SHOW ACME - оно показывает ndsn-domain: xxx.mykeenetic.com , но ниже ndns-domain-acme: no! Хотя должно бы быть в "yes". Не очень понимаю, как это побороть! То есть возможно домен надо сменить? Но я бы этого не хотел делать. Спасибо!

Должен сказать, что я имею обширный опыт общения с техподдержкой разных производителей, в том числе весьма именитых. Так вот тенденция такова, чем более "именитый" производитель, тем менее он обращает внимание на отзывы пользователей и тем боле он озабочен сугубо финансовой выгодой, пытаясь постояно удешевлять устройства жертвуя их надежностью и качеством. Скажем фирме CISCO или HP глубочайше наплевать на пожелания клиентов и сообщения о багах - они будут делать то, что указывает их маркетинговая стратегия - выжать максимум денег. И только заметный скандал или массовый отказ заставит их пошевелится. С Кинетиком ситуация обратная - марка, что ни говори, в мировом контексте неизвестная, поэтому ее производители еще не достигли того уровня, когда можно игнорировать пожелания клиентов. Производители Кинетика как раз привлекают клиентов очень хорошей (я бы сказал невиданого в мире уровня) поддержкой и постоянным совершенствованием продукта, так чтобы предоставить клиентам те функции, которые невозможно найти больше ни у какого иного продукта. Собственно поэтому я и перешел на Кинетик. Таким образом им небезразличны даже те немногочисленные группы клиентов, что имеют потребности отличные от массовых. Кроме того далеко не всегда "массовость свидетельствует о качестве" как говаривал в 80х Сева Новгородцев, массы могут просто не понимать, что им надо, а что не надо! Из всего вышесказанного я делаю вывод, что мое предложение, достаточно разумно, понятно и технически грамотно аргументированное может найти отклик у производителей. Тем более, что реализовать его не составит никакой сложности, так как управление USB питанием уже есть и в том числе и программно, надо только добавить логику в его работе. Хочется добавить, что хотя в стране под названием "Россия" дикарей экология и глобальное потепление абсолютно не интересуют, и платить за это никто не будет, но тем не менее экономное расходование питания устройством делает его ЭКОЛОГИЧНЫМ и позволяет добавить в маркетинг наклейку ЭКО и тем самым дополнительно привлечь группы клиентов заинтересованные в экологии. А что до скорости переключения на резерв... люди порой не знаю что им надо больше! Резерв - это АВАРИЯ, которая должна происходить очень редко и потеря дополнительных 30 секунд в случаи аварии, которая случается раз в месяц или реже не должно абсолютно никого беоспокоить... ну кроме тех у кого аврии случаются каждые несколько часов,что нормальным не является никак и надо решать проблему другим пуем для обеспечения надежной связи. Например у меня ДВА ПРОВОДНЫХ провайдера и только третий резерв - 4G модем, на случай если откажет электро питание всего дома, и оба проводных провайдера лягут, тогда поднимется 4G модем изпод UPSа. Ситуация - ОЧЕНЬ редкая, и гонять модем круглосуточно под питанием ради этого, очень нехорошо.

Я инженер электронщик с 40 летним опытом работы, ремонтирую сотни разных электронных устройств и хорошо знаком с тенденциями выхода устройств из строя. Наиболее распространеная причина отказа устройств: ВЫХОД ИЗ СТРОЯ ИМПУЛЬСНЫХ БЛОКОВ ПИТАНИЯ. Причем вопрос не в том произойдет ли отказ или нет, а только КОГДА он произойдет! Импульсные БП выходят из строя обязательно рано или поздно. Разумеется, можно "отсрочить" этот процесс изготовив БП с большим запасом, но никто из производителей этого не делает из экономических соображений, так что обычно импульсные БП проживают не более гарантийного срока! Отказы чаще всего происходят ввиду высыхания электролитических конденсаторов, а также длительного нагрева других радиоэлементов. Чем выше температура работы устройства, тем быстрее происходит отказ, чем больше потребляемая устройством мощность - тем больше оно нагревается - это закон физики. И наоборот, если мощность БП заметно меньше максимально допустимой, следует ожидать, что он проживет дольше. Таким образом снижение потребляемой устройством мощности равноцено продлению его жизни! Если 4G модем, работающий в режиме резервирования постояно включен - он потребляет достаточную мощность, порой до 2.5 Ватт, что приводит как к разогреву самого модема, так и блока питания раутера и его собственных цепей стабилизации напряжения питания USB слота. КПД этих стабилизаторов обычно очень низок, так 2.5 ватт дополнительной мощности могут потребовать дополлнительных 5-7 ватт от блока питания, и потери уже будут греть сам раутер. Следует учитывать, что в полупроводниковых микросхемах высокой плотности существует еще такой феномен как "электромиграция" - при наличи питания на устройстве происходит очень медленное перемещение материалов внутри микросхем, что может привести к отказу устройства, то есть работа полупроводникового устройства сокращает его срок жизни. Из всего вышесказанного логичен вывод, что следует минимизировать потребляемую мощность для продления срока жизни устройств. Поэтому я бы рекомендовал, сделать опцию, позволяющую отключать питание 4G модема, находящегося в режиме резервирования, подавая его только при переходе соединения в активный режим. Да это увеличит время переключения на резервное соединение, но в большинстве случаев, быстрота реакции не имеет особого значения, а вот то, что из 1000 часов работы модем 999 часов работает и греется впустую может оказаться важнее! Ну а те, кому важна скорость переключения могут этой опцией не пользоваться. Кроме всего прочего такой метод работы на 100% обезопасит от случайной активации пакета интернета в случае тарифа с подневной оплатой, что очень даже немаловажно! С уважением, Леонид Автюшенко.