Thesaurus

Выключал NAT - no ip nat. Похоже, что у меня не хватило ума разобраться как управлять транслацией через консоль кинетика. В итоге сделал: no ip nat Home ip static Home ISP После этого всё на вид заработало корректно и туннельный трафик транслироваться перестал. Надеюсь, что так правильно. Извиняюсь за беспокойство.

Добрый день! Происходят чудеса, в которых я уже несколько дней не могу разобраться. Прошу помощи. Есть Keenetic'и (причём несколько штук разных и на разных прошивках - 2-я и 4-я версии). На них настроен l2tp/ipsec клиент, который подключается к openbsd'шному npppd в режиме l2tp + ipsec. Поведение, о котором дальше будет написано, одинаковое. С подключением всё отлично, но проблема в том, что маршрутизация получается несимметричной - как будто в одну сторону на стороне кинетика для интерфейса ppp0 работает NAT. Если пакеты идут из сети, которую обслуживает кинетик, в сеть, которую обслуживает openbsd, то соединения устанавливаются, однако IP адрес отправителя в туннельном интерфейсе подменяется на IP адрес кинетика с его стороны туннеля (и видно это tcpdump'ом на кинетике). Для примера, пусть будет ppp0 192.168.20.1 <-> 192.168.20.2. В этом случае все устройства сети openbsd, которые будут получать трафик от устройств из сети кинетика, будут думать, что весь он отправлен с адреса 192.168.20.1, т.е. с кинетика, соответственно и отвечать будут этому адресу, который на стороне кинетика в обратном порядке будет заменён на настоящий и отправлен к себе в сеть нужному устройству. В обратном направлении (сеть openbsd -> сеть кинетика) трафик идёт с корректным адресом отправителя, доходит до устройства, устройство отвечает, ответ приходит на кинетик и "застревает" в ppp0, не возвращаясь в pppx0 openbsd, хотя адрес получателя стоит корректный. При этом обе стороны туннеля по туннельным адресам могут "пинговать друг друга" без проблем. Я настраивал правила файрволла на кинетике для пропуска всего во все стороны, отключал isolate-private, меня security-level, пытался отключить NAT, который и так не был включен, убирал ALG из компонентов - ничего не помогает. В итоге для эксперимента я поднял поверх этого l2tp/ipsec туннеля туннель GRE и настроил маршрутизацию через него. Опять трафик сначала пошёл только в одном направлении (но в обе стороны, т.е. если TCP соединение инициировала сторона кинетика, то пакеты в рамках этого соединения назад тоже ходят). После того, как я выставил secure-level private для интерфейса Gre0, всё на вид заработало как надо - пошёл трафик, инициированный с обоих сторон. Пользоваться стало можно, но, к сожалению, проблема с односторонней трансляцией IP адресов проявилась также и для Gre0 интерфейса. Кинетик и для Gre0, как и для ppp0, переделывает адреса отправителя в адрес своей строны GRE туннеля.

Добрый день! Для IPv4 всё работает замечательно. Можно добавить во вкладке "Настройка DNS" свой сервер и выставлять в "Контентном фильтре" его в профилях кому хочется. В случае с IPv6 получается совсем другая история: Нельзя в "Настройке DNS" добавить свой сервер с IPv6 адресом, кроме как для Системного профиля. Но это полбеды. Проблема в том, что клиенту в качестве IPv6 DNS сервера выдаётся локальный IPv6 адрес кинетика. И все запросы по умолчанию идут на него с неответом по таймауту. По идее, для IPv6 также должно работать перенаправление через dns прокси (или как там это реализовано) на те серверы, которые установлены для профиля, выставленного клиенту (даже если они IPv4). Но этого не происходит. В ip6tables есть правило: DNAT udp br0 * fe80::/10 fe80::/10 mark match 0xffffaaa PKTTYPE = unicast udp dpt:53 to:[fe80 IPv6 адрес]:41100 Такое же для TCP. При этом IPv6 адреса, который указан в скобках [ ], нет ни на одном интерфейсе. Подобное правило есть для всех br* интерфейсов и везде указаны какие-то левые IPv6 адреса, но для каждого интерфейса разные, либо я что-то не понимаю. Если правило убрать, то некоторое время разрешение имён с клиента начинает работать, пока роутер не добавит его опять. Мне кажется, что тут что-то не так. Спасибо.

В /opt/ больше скриптов я не нашел. В том то и проблема, что я не понимаю в чем проблема и чем мешает запуск alt_fwup через /opt/bin/sh.

Почему странно? Я же в скриптах /opt/etc/init.d/ заменил #!/bin/sh на #!/opt/bin/zsh. Все как бы работает, пока проблем не заметил, но думаю придется теперь постоянно скрипты править. Буду ждать разработчиков...

Проблему криво, но решил. Чисто случайно смотрю htop в процессе бесконечной перезагрузки LTE модема и вижу, что alt_fwup запускается как /opt/bin/sh -c alt_fwup. В общем, поставил я zsh. Прописал его в shells, пользователям и в init скриптах, а sh из /opt/bin удалил. Все теперь работает хорошо. Но так делать неправильно. Может кто-нибудь что-нибудь подскажет? Спасибо.

Не думаю. Чистая система так себя ведет. ~ # ls -l /dev | grep "^c" | grep " 4," crw------- 1 root root 4, 64 Jan 1 1970 ttyS0 crw------- 1 root root 4, 65 Jan 1 1970 ttyS1 Тоже самое, что и у вас. ~ # ls -l /dev crw------- 1 root root 254, 0 Jan 1 1970 aci0 crw------- 1 root root 254, 1 Jan 1 1970 aci1 crw------- 1 root root 254, 2 Jan 1 1970 aci2 crw------- 1 root root 254, 3 Jan 1 1970 aci3 drwxr-xr-x 3 root root 60 Apr 29 14:43 bus crw------- 1 root root 5, 1 Jan 1 1970 console crw-r----- 1 root root 10, 63 Apr 29 14:43 cpu_dma_latency crw-rw-rw- 1 root root 1, 7 Jan 1 1970 full crw-rw-rw- 1 root root 10, 229 Jan 1 1970 fuse crw------- 1 root root 220, 0 Jan 1 1970 hwnat0 crw------- 1 root root 1, 2 Jan 1 1970 kmem crw------- 1 root root 1, 11 Jan 1 1970 kmsg srw-rw-rw- 1 root root 0 Jan 1 1970 log crw-r----- 1 root root 10, 237 Apr 29 14:43 loop-control brw------- 1 root root 7, 0 Jan 1 1970 loop0 brw------- 1 root root 7, 1 Jan 1 1970 loop1 brw------- 1 root root 7, 2 Jan 1 1970 loop2 brw------- 1 root root 7, 3 Jan 1 1970 loop3 brw------- 1 root root 7, 4 Jan 1 1970 loop4 brw------- 1 root root 7, 5 Jan 1 1970 loop5 brw------- 1 root root 7, 6 Jan 1 1970 loop6 brw------- 1 root root 7, 7 Jan 1 1970 loop7 crw------- 1 root root 1, 1 Jan 1 1970 mem crw------- 1 root root 90, 0 Jan 1 1970 mtd0 crw-r----- 1 root root 90, 1 Apr 29 14:43 mtd0ro crw------- 1 root root 90, 2 Jan 1 1970 mtd1 crw-r----- 1 root root 90, 3 Apr 29 14:43 mtd1ro crw------- 1 root root 90, 4 Jan 1 1970 mtd2 crw-r----- 1 root root 90, 5 Apr 29 14:43 mtd2ro crw------- 1 root root 90, 6 Jan 1 1970 mtd3 crw-r----- 1 root root 90, 7 Apr 29 14:43 mtd3ro crw------- 1 root root 90, 8 Jan 1 1970 mtd4 crw-r----- 1 root root 90, 9 Apr 29 14:43 mtd4ro crw------- 1 root root 90, 10 Jan 1 1970 mtd5 crw-r----- 1 root root 90, 11 Apr 29 14:43 mtd5ro crw------- 1 root root 90, 12 Jan 1 1970 mtd6 crw-r----- 1 root root 90, 13 Apr 29 14:43 mtd6ro crw------- 1 root root 90, 14 Jan 1 1970 mtd7 crw-r----- 1 root root 90, 15 Apr 29 14:43 mtd7ro crw------- 1 root root 90, 16 Jan 1 1970 mtd8 crw-r----- 1 root root 90, 17 Apr 29 14:43 mtd8ro crw------- 1 root root 90, 18 Jan 1 1970 mtd9 crw-r----- 1 root root 90, 19 Apr 29 14:43 mtd9ro drwxr-xr-x 2 root root 240 Jan 1 1970 mtdblock brw-r----- 1 root root 31, 0 Apr 29 14:43 mtdblock0 brw-r----- 1 root root 31, 1 Apr 29 14:43 mtdblock1 brw-r----- 1 root root 31, 2 Apr 29 14:43 mtdblock2 brw-r----- 1 root root 31, 3 Apr 29 14:43 mtdblock3 brw-r----- 1 root root 31, 4 Apr 29 14:43 mtdblock4 brw-r----- 1 root root 31, 5 Apr 29 14:43 mtdblock5 brw-r----- 1 root root 31, 6 Apr 29 14:43 mtdblock6 brw-r----- 1 root root 31, 7 Apr 29 14:43 mtdblock7 brw-r----- 1 root root 31, 8 Apr 29 14:43 mtdblock8 brw-r----- 1 root root 31, 9 Apr 29 14:43 mtdblock9 drwxr-xr-x 2 root root 60 Jan 1 1970 net crw-r----- 1 root root 10, 62 Apr 29 14:43 network_latency crw-r----- 1 root root 10, 61 Apr 29 14:43 network_throughput crw------- 1 root root 210, 0 Jan 1 1970 ntc crw-rw-rw- 1 root root 1, 3 Jan 1 1970 null crw------- 1 root root 209, 0 Jan 1 1970 phr crw------- 1 root root 1, 4 Jan 1 1970 port crw------- 1 root root 108, 0 Jan 1 1970 ppp crw-rw-rw- 1 root root 5, 2 Apr 29 14:50 ptmx drwxr-xr-x 2 root root 0 Jan 1 1970 pts crw-rw-rw- 1 root root 1, 8 Jan 1 1970 random drwxr-xr-x 2 root root 180 Jan 1 1970 rd crw------- 1 root root 253, 0 Jan 1 1970 rdm0 brw-r----- 1 root root 8, 0 Apr 29 14:43 sda brw-r----- 1 root root 8, 1 Apr 29 14:43 sda1 crw-r----- 1 root root 21, 0 Apr 29 14:43 sg0 crw------- 1 root root 153, 0 Jan 1 1970 spi0 crw------- 1 root root 153, 1 Jan 1 1970 spi1 crw------- 1 root root 153, 2 Jan 1 1970 spi2 crw------- 1 root root 153, 3 Jan 1 1970 spi3 drwxr-xr-x 2 root root 80 Jan 1 1970 tts crw-rw-rw- 1 root root 5, 0 Jan 1 1970 tty crw-r----- 1 root root 253, 0 Apr 29 14:50 ttyLTE0 crw------- 1 root root 4, 64 Jan 1 1970 ttyS0 crw------- 1 root root 4, 65 Jan 1 1970 ttyS1 crw-r----- 1 root root 254, 0 Apr 29 14:50 ueservice0 crw-rw-rw- 1 root root 1, 9 Jan 1 1970 urandom crw-r----- 1 root root 189, 0 Apr 29 14:43 usbdev1.1 crw-r----- 1 root root 189, 1 Apr 29 14:43 usbdev1.2 crw-r----- 1 root root 189, 128 Apr 29 14:43 usbdev2.1 crw-r----- 1 root root 189, 136 Apr 29 14:50 usbdev2.9 crw------- 1 root root 109, 0 Jan 1 1970 vdsl crw-rw-rw- 1 root root 1, 5 Jan 1 1970 zero

Здравствуйте! Есть Keenetic LTE. На всех прошивках выше с ядром 3 версии и включенным OPKG (Entware не важно какой версии) происходит следующее: alt_fwup Failed to write ELF Data. alt_fwup Failed to process ELF Data section for UMAC module. alt_fwup failed to load firmware. и LTE модем не стартует. Самое интересное, что если сбросить настройки и подключиться к интернету, а затем включить OPKG и поставить Entware, то все до перезагрузки замечательно работает. А после перезагрузки происходит то, что написано выше - модем пытается завестись и постоянно идут эти строки. В результате соединение с Интернетом так и не устанавливается. Если тут же снять галку с OPKG, то все сразу же стартует. Может кто поможет решить эту проблему? Спасибо.