Werld

А если попробовать выключить защиту от DNS Rebinding ( в cli: dns-proxy no rebind-protect ) ?

Скорее всего, днс-серверы провайдера доступны даже при неоплаченном интернете, и продолжают резолвить адреса внутренних ресурсов. Так как, при неоплаченном интернете, публичные днс-серверы не доступны, то они и не могут вам резолвить адреса внутренних ресурсов. Если адресов внутренних ресурсов не очень много, в качестве решения, предлагаю Вам сделать необходимые записи на самом роутере, с помощью команды ip host ‹domain› ‹address›

Судя по всему да. KeenDNS имя из переписки с техподдержкой резолвится в ip 31.180.xxx.xxx Название провайдера: OJSC Rostelecom Macroregional Branch South

Вы прям цитируете из той ссылки, что я привел)) Чудес не бывает, раз техподдержка, посмотрев конфиг, сообщила, что порт открыт, никаких правил взапрещающих в межсетевом экране нет, то что остается?

Я думаю ответ прост - блокирует провайдер. Вот есть похожие случаи на ростелекоме https://www.nn.ru/community/techno/internet/rostelekom_blokiruet_podklyucheniya_na_80_port.html

Когда вы пингуете "стыковочный адрес" трафик тоже идет в интерфейс wireguard. Я не понимаю, что вы мне пытаетесь доказать? Маршруты пропадают, с этим я согласен, здесь нужна реакция разработчиков. Но интерфейс не идет в down, говоря, что "было state: up стало state: down" - вы ошибаетесь, в посте выше я вам продемонстрировал.

Ну то есть вы теперь согласны, что интерфейс остается up? Проблему с пропаданием маршрутов я не отрицал. Вы пытаетесь буквоедствовать, тем не менее неверно. прочитайте внимавтельно, я написал "в подсеть, обозначенную маской на интерфейсе", да наверное коряво выразился, но, тем не менее, я не писал "в подсеть на интерфейсе"

Вот прошло время, маршруты исчезли, пир стал "сереньким" Но интерфейс все равно up: (config)> show interface Wireguard0 id: Wireguard0 index: 0 type: Wireguard description: Waffle interface-name: Wireguard0 link: down connected: no state: up mtu: 1420 tx-queue: 50 address: 10.15.57.2 mask: 255.255.254.0 uptime: 936 global: no security-level: public wireguard: public-key: mAS listen-port: 49112 status: up Интерфейс не выключается, и если в него пойдет траффик, он снова скажет link up, connected yes

Вот специально убрал PersistentKeepalive, на другом конце его тоже нет. Маршруты добавленые через этот интерфейс ушли, как вы и сказали. Но вот я посылаю пинг, и другая сторона мне сразу отвечает, т.к.маршрут в подсеть, обозначенную маской на интерфейсе остается. Так что трафик изнутри пойдет. Вопрос и остается только с пропаданием маршрутов.

Ну а я не это же самое вам и написал? Ладно опустим PersistentKeepalive. Вот вы пишете, что интерфейс идет в down, но это же не так, вам не придется включать его снова. Как только трафик пойдет в него он его прекрасно отработает. Проблема насколько я понимаю именно в этом: "из таблицы попадает маршрут привязанный к этому интерфейсу". Ну так и пишите об этом, а не о том, что интерфейс видите ли идет в down. Никуда он не идет, как я написал выше, он просто сидит и ждет когда снова в него трафик пустите. А вот то, что из таблицы пропадают маршруты, это и связано, насколько я понимаю, с тем, что кинетик судит о состоянии соединения по state, т.к. внутри там все тот же линуксовый netfilter - statefull firewall. Можно ли сделать, чтобы маршрут не пропадал из таблицы при простое интерфейса вот это, как раз, вопрос к разработчикам. Попробуем спросить @Le ecureuil

Это не для "пробития NAT", а как раз для того, чтобы state соединения оставался up, что и приводит к тому, что statefull фаерволлы считают что соединение продолжается. Wireguard,как пишут его авторы, старается оставаться как можно более тихим, это by design.

Вот как раз для этого создатели wireguard предусмотрели опцию Persistent Keepalives, в вебе кинетика она называется "Проверка активности" в настройках пира.

А какой есть повод ее ставить? Чем она настолько лучше текущей в рамках использования в роутере, какие проблемы решает, что нужно все бросать и срочно ее внедрять?

Честно говоря, не совсем понятно чего вы хотите добиться, то у вас openvpn, то вдруг gre. Но если все же вам "нужно что бы адреса не транслировались!", то попробуйте отключить глобальный нат: no ip nat Home Далее включаем обратно нат, но только для интерфейсов, которым он нужен, командой вида: ip static Home ISP - включает трансляцию адресов домашней сети Home в о внешний интерфейс ISP. Если у вас подключение к провайдеру через pppoe, к примеру, то тогда еще команда: ip static Home pppoe0 ит.д включаем нат отдельно только через нужные интерфейсы.

Сдется мне, что snat происходит на микротике, раз пакет прилетает с sourceIP 172.16.16.254, который, судя по вашему описанию, на интерфейсе микротика. Думаю, стоит сделать захват входящих пакетов на интерфейсе l2tp Кинетика, с помощью одноименного компонента. Убедится что на l2tp интерфейс кинетика пакет действительно прилетает с sourceIP 172.16.16.254 и искать проблему на микротике, очевидно какое-то правило snat'a

Сдается мне, вы путаете прошивочный ssh сервер и тот, который устанавливается при развертывании entware. Прошивочный висит на стандартном порту 22. Если прошивочный ssh установлен, то в момент разворачивания entware вешает свой на 222 порт.

Dropbox не поддерживает доступ по webdav

root есть только в opkg. Без opkg в прошивочном cli этот пользователь никогда не был доступен. Только admin и любой другой пользователь, которого вы создадите и дадите нужные права

Hello. 802.11 standard defines 20MHz channels, and as long as you wish to remain standard, it will be 20/40MHz and AP has to allow devices to use only single channel. Same for 802.11ac with 20/40/80

Полностью согласен

Взять у контроллера и положить экстендеру и есть "синхронизация". Она не делится на типы, нет такого, что синхронизация при захвате, одно, а при смене настроек на контроллере - другое. Она происходит в заданном объеме при любом чихе же. А если начать разделять эти вещи, при захвате - синхронизация одна, полная, с доп параметрами, а при перезагрузке устройства уже другая синхронизация без этих параметров, то как раз и вылезают вопросы о реализации. Поэтому я и позволил себе заметить, что "Тут тоже есть о чем подумать" и "не уверен, что организация такой логики проста в реализации..."

В текущей реализации экстендеры переинициализируют настройки с контроллера при любом чихе. Иначе смена пароля или ssid на контроллера не приводила бы к смене этих параметров на экстендерах. Поэтому нет никакой первоначальной настройки при захвате, настройки переезжают постоянно, даже просто после перезагрузки любого устройства.

С другой стороны, а как экстендер будет понимать брать настройки с контроллера или оставлять свои? Тут тоже есть о чем подумать. Одно дело, тупо перенимать настройки с контроллера в 100% случаев, а другое прикрутить какую-то систему приоритетов, когда какие настройки важнее. Типа если настройки сделаны вручную - оставлять, если нет - перенимать с контроллера, но не уверен, что организация такой логики проста в реализации...

Тогда да, не так понял. Если при такой реализации возможность изменять эти доп настройки на экстендерах все равно оставят, то ничего не имею против)

Тогда и канал будет тоже копироваться с контроллера, а это не нужно. К примеру, у вас частный дом, свободный эфир, три кинетика, соединены кабелем, вы на них в 2.4 выставили 1, 6 и 11 канал - красота. Или, к примеру, есть старый девайс, который умеет только 802.11g и всегда стоит на втором этаже. Вы на нужном экстендере выставили g,n а на остальных оставили n-only - опять красота. То есть, ради мизерного удобства, избавляющего при конфигурировании wifi-системы от минутной доп настройки на экстендерах , мы теряем львиную долю гибкости возможных настроек.