daledale

Доброго. Сабж. KN-1410 Omni. Софт 3.7.5. Статический белый внешний ip. Всё закрыто по-умолчанию специальными правилами TCP/UDP/ICMP - запретить. + закрыт доступ к веб морде снаружи по http/https + 80 порт по-умолчанию изменён через CLI - явно на другой. Тем не менее, снаружи видятся доступными порты 53 и 443. Не подскажете, куда копать - причина открытости этих портов наружу и последствия, их явного закрытия. ps Никаких правил переадресации этих портов не установлено.

Всё сорри. Вопрос отменяется. Короче очепятка=досадная ошибка закралась. У меня на 2.100 поднят ещё wireguard и плюс я менял роутер 2.100 недавно и каким-то чудом (делал путём редактирования файла конфигурации в текстовом режиме, чтобы не переносить всё вручную) в пользовательских маршрутах стояло то, что отправлять весь трафик на 172.16.1.100 через wireguard. Убрал эту строчку, точнее заменил, что весь трафик на 172.16.1.100 отправлять через шлюз 192.168.2.200 - моментально всё взлетело! Имхо было что - при попытке пропинговать с 192.168.1.1 - шлюз 192.168.2.100 - этот самый 192.168.2.100 - отвечал, отправляя пакеты через интерфейс wireguard, а не в шлюз 192.168.2.200 и далее в 192.168.1.1. vasek00, Спасибо Вам, за попытку помочь!

Сделано. ps Провайдер у кинетик1 (192.168.1.1) и кинетик2 (192.168.2.200) - один и тот же. ps В кинетик3 (192.168.2.100) в фаерволле, для домашней сети разрешено всё (tcp+udp+icmp) от сети 192.168.1.0 и от клиента vpn шлюза 172.16.1.100. ps Yota - резервный интернет и не используется в настоящее время.

Доброго. Имеем следующую конфигурацию. 1. Локалка1 192.168.1.0, интернет1 (кинетик1) ну и пк1 в нём, допустим 192.168.1.100 2. Локалка2 192.168.2.0. интернет2 (роутер кинетик2 + включен dhcp), а также в этой же локалке интернет3 на кинетик3 (разумеется без включенного dhcp) + пк2 + пк3. см. ниже. Все три кинетика - omni1410, но думаю это не особо важно. На всех трёх интернетах внешний статический ip. Между локалкой1 и локалкой2 поднят и успешно работает vpn l2tp туннель (vpn клиент в локалке1, сервер - в локалке2). За vpn клиентом на сервере vpn зафиксирован статический ip адрес 172.16.1.100 Есть допустим пк2 в локалке2 допустим с ip 192.168.2.2, шлюзом (!)интернета2, и также, допустим, есть пк3 тоже в локалке2 - 192.168.2.3 с шлюзом (!)интернета3. Задача - попасть с пк1 на пк3 по локалке. Поясняю. Без проблем могу попасть с пк1 на пк2 по локалке, в т.ч. разумеется всё пингуется и работает, но пк1->пк3 - нет. Пингую (по локальному адресу) из админки кинетик1 -> кинетик2 - ОК Пингую (по локальному адресу) из админки кинетик1 -> кинетик3 - Не проходит. При этом, разумеется пинг из админки кинетика2 -> кинетик3 - ОК Также из админки кинетик2 - пингуется пк3

up - разобрался. Тему можно закрыть. Стояло разрешающее правило для домашней сети в fw, которое очевидно приоритетнее. Спасибо.

+Доброго. Выставляю в настройках расписание работы в интернет для конкретного зарегистрированного устройства в сети, который разумеется получает адрес по dhcp от роутера. Время X наступает (причём точно такое же поведение, если выбрать профиль доступа - без доступа в интернет), в админке роутера в разделе Список устройств - указанное устройство перемещается вниз, в раздел "Заблокированные устройства - Устройства, которым запрещен доступ в интернет.", но конкретное устройство как имело доступ в интернет, так и имеет и всё работает. Никто не сталкивался? ps сетевые устройства - пк win10 ps Keenetic KN-1410, версии 3.7.3 + обновился до 3.7.4. + разумеется перезагружал роутер - всё без изменений.

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

Спасибо за ответ. Мега, мега респект вам. Работает, УРА!!! Спасибо большущее! Была такая мысль у меня изначально, но зациклился на том, что в поле адрес шлюза дб выбор vpn подключения. И даже сейчас, когда явно выбрал интерфейс vpn - поле адрес шлюза не становится затемнённым (для невозможности выбора), но можно его оставить пустым, как выяснилось. И, чёрт возьми, оно работает! Извиняюсь за эмоции, ваш ответ просто решил в раз проблему!

Спасибо за ответ. Ну вот, классический пример. см. вложение. Здесь ip: 8.9.10.0 - подсеть, на которую нужно ходить ч-з vpn. 10.9.175.10 - адрес vpn, который был получен в текущем vpn подключении, но если vpn переподключить - ip адрес vpn будет другой.

Доброго. Keen OS 2.15. Имеем основное подключение к интернету и vpn (open vpn), поверх основного. Основной трафик - через основное, выборочные сайты - ч-з vpn, посредством прописывания маршрутизации. Всё отлично работает до случая либо ребута роутера по расписанию (не вопрос, могу отключить), либо переподключения основного интернета или vpn соединения. Собственно суть "проблемы" - у vpn подключения меняется ip и маршрутизация, естественно, перестаёт работать. ps vpn'у выдаются серые ip адреса вида 10.x.x.x на всякий. Вопрос, как бы красиво решить этот вопрос, мож у кого есть идеи? Спасибо.

Что смешного, блин? Не далее как пару дней назад была ситуация, практически с новым кинетик с прошивкой 2.13. Проблема проявлялась так. Часть правил переадресации перестала работать, часть работала. Кинетик пинговался и снаружи и изнутри. Этот кинетик выполнял дополнительно роль l2tp/ipsec vpn сервера, он отключился и перестал работать. Веб морда была доступна и снаружи и изнутри, но как только вводил логин и пароль в веб морде, страница не показывала никакую ошибку, но и кинетик не пускал внутрь (проблема с браузером и cookies - исключена 100%, пробовал разные брузеры, компьютеры, ос). Никакие команды, в т.ч. и по telnet'у по перезагрузке "system reboot" кинетик не выполнял, точнее писал что выполнял в консоли (тоже никаких ошибок НЕ было), а по факту перезагрузки не происходило. Сталкивались с таким, не? Я - столкнулся. Единственный способ, только приезд и передёргивание питания решило проблему. Что скажете на это, когда в такой вот кинетик будет воткнуто два/три... провайдера?

Добавлю, или снова повторюсь. Давайте абстрагируемся от двух кинетиков в одной локалке, количества dhcp серверов и проч. Допустим берём пример. 1. Кинетик №1 с внешним статическим ip и локальной сетью 192.168.0.0/24. Он же являеется клиентом l2tp/ipsec до удаленного кинетик см. п.2 далее. 2. Кинетик №2 тоже с внешним ip и локальной сетью 192.168.100.0/24. На нём поднят l2tp/ipsec vpn сервер. К нему подключается кинетик №1. Vpn поднимается и работает. В его локальной сети есть хост 192.168.100.10:8888 --------- Из админки Кинетика №1 пингуется не только локальный ip кинетика №2, а даже сам хост 192.168.100.10. Т.е. кинетик №1 благодаря туннелю vpn и правилам маршутизации знает о существовании хоста в локалке кинетика №2. Вопрос: Почему Кинетик №1 правилом переадресации не может перекинуть запросы со внешки на определённый порт, непосредственно на удаленный хост 192.168.100.10, ведь он его пингует и знает о нём? Или тут засада кроется не в кинетик №1, а в кинетик №2? 1-ый кинетик успешно перенаправляет запросы, а вот фаерволл второго лочит?

Так получилось, это делалось не сразу, а постепенно. На данный момент так. Где я писал, что у них включены dhcp? Скажу больше, dhcp ни на одном не включен, а dhcp сервер это вообще третий девайс - тот самый программный. Он ничего не фильтрует, просто выполняет роль dhcp сервера, причём очень гибкого в отличии от кинетик)) Знаю. Писал выше про "так получилось....", более того всё же как ни крути две независимые железки с двумя провайдерами более надёжны, нежели одна. Т.е. будет 1 девайс с настроенными двумя провами и он, например, благополучно зависнет. Получится картина маслом - два интернета и ни один не работает... На данный момент оба из kn-1410 здесь соединены (являются клиентами L2tp/ipsec) с удаленной.

Было: 1. Инет 1 - внешний 1.2.3.4 + l2tp/ipsec vpn до п.4 см. ниже 2. Инет 2 - внешний 5.6.7.8 + l2tp/ipsec vpn до п.4 см. ниже 3. Оба интернета пп.1-2 в одной локалке 192.168.0.0/24 здесь. 4. Удаленный keenetic - внешний ip 9.10.11.12. Удаленная локалка 192.168.100.0/24 Вы предлагаете. Удаленную локалку сделать тоже 192.168.0.0/24 без пересечения ip адресов с локалкой здесь из п.3, верно? В общем - я просто не пойму такой штуки, почему когда что 1-ый, что 2-ой кинетик здесь, зная удаленную локальную подсеть (поднят vpn до неё), более того даже зная конкретный хост в этой удаленной сети - не могут переадресовать запросы в эту подсеть. Т.е. с любого кинетика из админки пингуется не только удаленный шлюз-кинетик по его локальному ip, а даже удаленный хост по его локальному для той подсети ip (есть правила маршрутизации). Вот, по сути, в чём смысл, так сказать, вопроса.

Вопрос закрыт - решил правилами фаерволла. Ну и остальным, вдруг кому пригодится, собс-но это и есть решение. Не буду утверждать что это единственное и/или самое правильное, но в моём случае этого достаточно. Кратко - правило переадресации как обычно - источник провайдер. В фаерволле разрешаем доступ только нужным ip, остальным, всем остальным - запрет.

Где два кинетика в одной локалке - оба KN-1410. В удаленной сети Omni II c с прошивкой 2.14. очепятка, конечно же KeenetiC. Роутеры самые что ни на есть - Genuine Original )) ------------ Тут, если я правильно понял, речь идёт об удаленном Keenetic = сделать его подсетку такую же, как и здесь, разумеется без пересечений?

Ясно. Точнее пока ничего не ясно, надо "курить" тему. Просто, как было раньше, если интересно: Локалка 192.168.0.0/24. В ней два провайдера со статическими внешними ip. 1. Провайдер 1 - интернет поднимается на кинетике + vpn туннель до другого Keenetik и удаленной подсети 192.168.100.0/24. На удаленном хосте, например 192.168.100.10 работает некий сервис на порту например 8888. 2. Провайдер 2 - интернет поднимается на программном шлюзе. НЕкто с внешки подключается именно к этому Ip/провайдеру, он не знает про существование прова №1 и его ip. Собс-но на шлюзе касательно этого, буквально две настройки: Правило запросы от Источник (внешний IP "НЕкто") и на оперделённый порт завернуть на 192.168.100.10:8888, да да, прямо ip адрес конкретного хоста удаленной подсети, это не ошибка! а собственно программный шлюз "знал" про удаленную подсеть, т.к. в нём прописано одно правило маршрутизации вида route add 192.168.100.0 mask 255.255.255.0 [локальный ip keenetik 1-го прова]. Всё, всё работало. Т.е. этот некто даже не подозревая о существовании 1-го прова и его ip, подключался к внешнему ip и на определённый порт прова 2 и запросы сразу улетали в удаленную подсеть. ========= Что изменилось сейчас? Вместо программного шлюза прова №2 - добавился Keenetik в котором тоже как и в первом поднят vpn до той же самой удаленной подсети. Впрочем и на первом Keenetik также поднят vpn до той же удаленной подсети. Ну собс-но проблема в первом посте. Это я так KN-1410 обозвал))

Чёт я погорячился)). Можно с этого места поподробнее? Игрался вроде и так и сяк, с маршрутами. с 1-го роутера удаленный хост, находящийся за вторым роутером в другой подсети пингуется, но никак не удаётся завернуть подключающегося с внешки на 1-ый роутер в VPN туннель.

Доброго. Скажите плз, можно ли реализовать такую штуку - можно только направление подсказать, конкретные действия можно не писать. В общем 2.14 прошивка. Роутер является клиентом L2TP = поднят vpn туннель до другого Keenetik. Можно ли создать правило переадресации и/или + маршрутизации, чтобы некто, подключающийся с внешки к этому клиенту VPN на опеределённый порт, был завернут в этот vpn туннель и далее получил бы доступ к компу на другом конце туннеля. Наверное непонятно, объясню на примере. 1. Есть роутер keenetik vpn клиент, с внешним ip допустим 1.2.3.4 2. Есть роутер - сервер Keenetik vpn куда коннектится роутер-клиент из п.1. Допустим у этого роутера-сервера vpn внешний ip 5.6.7.8 (впрочем в данном вопросе не важно какой у него внешний ip). Локальная подсеть у него, допустим 192.168.100.0/24 3. Есть некто, кто знает внешний ip роутера из п.1. 1.2.3.4. По ряду причин ему не нужно знать внешний ip роутера 2 (5.6.7.8). Итак он стучится на 1.2.3.4, например на порт 1234. Как его запрос завернуть в vpn туннель, чтобы он получил доступ к внутреннему ресурсу, находящимся за роутером 2, например с локальным ip: 192.168.100.10:8888? Спасибо.

Прошу прощения, что поздно. Уведомления, похоже не включены у меня. Нет, не работает. Кстати маска дб 255.255.255.255, на конце 0 - это же маска подсети. И именно роутер на это же самое ругается. Короче выбираю Вход - другой адрес, вбиваю этот внешний статический IP и... ничего, не работает правило! Нет, не это. Выше в первом - вы правильно поняли.

Доброго. Прошивка 2.13.С.0.0.4. Возможно ли создать правило переадресации портов (проброс порта), работающее только для конкретного IP? Т.е. нужно чтобы переадресация работала только для IP адресов, которые явно указаны в каждом правиле?

Отписываюсь и здесь. Решил вопрос. Разумеется с вашей помощью. В общем и здесь, также как и в другой своей созданной теме (ссылка будет в конце, напомню там другое соединение). В общем и здесь сменил PPTP VPN на L2TP - и тут тоже всё взлетело. А именно скорость интернета ч-з удаленный шлюз 8/8 Мбит/с (вх/исх), но главное - почта тоже зашуршала через удаленный шлюз*. Ну и опять же субъективно, интернет стал открываться мгновенно практически. Ура! * - разумеется удалил ранее созданный маршрут специально для почты и тестировал БЕЗ него (см.выше). В общем L2TP - рулит. ps Прямо руки дрожали, когда для того чтобы изменить набор компонентов нужно было на удаленном роутере (да, да за 800 км), обновить прошивку. Но нет, всё прошло без сучка и задоринки. Роутер тот же - Omni1. Сейчас там прошивка 2.13.С.0.0.4 (была там 2.13.A.x.x.x - не помню точно), здесь же кстати точно такая же версия. В общем сейчас мой вопрос окончательно закрыт. Во всякому случае всё что планировал - сделал... на этот раз точно! Le ecureuil, Кинетиковод, r13 - большое Вам спасибо! Ссылка на мою другую тему с другим подключением, как и обещал:

Сейчас там 1492. Запустил speedtest интернета. Скорость входящая/исходящая примерно 8 / 5 Мбит/с Перебирал 1400, 1300, 1200. Что интересно входящая осталась примерно та же, но вот исходящая 0.5 Мбит/с почти во всех случаях. Вернул пока на 1492. Частично пока обошёл проблему как - создал статический маршрут на клиенте, заворачивающий весь почтовый трафик на местный интернет. В принципе почта пока работает. Но это такое себе решение. Ибо: 1. Нужно всё таки почту завернуть тоже. Ибо почта, думаю, частный случай и проблема всё равно всплывёт. 2. "Завтра" почтовый сервер сменит, допустим свои IP адреса и мой статический маршрут перестанет работать = проблема будет снова.

Перешёл на L2TP - знаете, "зашуршало", т.е. со скоростью вопрос как бы решился. Правда провёл ещё ряд оптимизаций - ряду не критичных клиентов "зарезал" скорость работы в интернете + оптимизировал подключение софта, в плане графики и вроде как пока тишина. Впрочем как поднялся L2TP скорость субъективно сразу стала гораздо интересней.

Это другое соединение)). .На этот раз оба конца - здесь, в одном городе)). Единственная оговорка, один из концов туннеля идёт через тот же роутер, что и для предыдущего случая, с которым была интересная ситуация с перелётами. Т.е. из того же офиса тянется ещё один PPTP и на роутере в данный момент два подключения PPTP. Собс-но в новом подключении проблема со скоростью. Впрочем и про проблемы с предыдущим писал, там тоже похожая проблема со скоростью удаленного интернета. Рекомендовали уменьшить MTU - пока не сделал.