Jump to content
  • 0
dvg_lab

Вопросы по /rci

Question

Накопилось некоторое количество вопросов по интерфейсу /rci, и так как пока не готов мануал по rci, буду задавать вопросы здесь в отдельном треде и надеюсь на помощь сообщества:

Создаю правило в МСЭ через веб морду и смотрю как формируется JSON, например интерфейс OpenVPN0, на котором не было ни одного правила в первых строках удаляет вроде бы не существующий access-list

[{"access-list":
	{
    	"acl":"_WEBADMIN_OpenVPN0",
     	"no":true
    }
 },
 {
 	"access-list":
    	[{"permit":
       		{"source":"0.0.0.0",
... далее понятно

И ответ подтверждает удаление "message": "_WEBADMIN_OpenVPN0" access list removed."

Вопрос, это необходимая процедура перед началом создания первого правила на интерфейсе, сначала удалить, а потом он автоматически создастся при первом же permit/deny правиле?

И второй вопрос, можно ли одним JSON запросом сформировать сразу все правила (у меня их около 18) на все интерфейсы и тем же запросом сказать {"system":{"configuration":{"save":true}}} ?

Share this post


Link to post
Share on other sites

13 answers to this question

Recommended Posts

  • 0
1 час назад, dvg_lab сказал:

Накопилось некоторое количество вопросов по интерфейсу /rci, и так как пока не готов мануал по rci, буду задавать вопросы здесь в отдельном треде и надеюсь на помощь сообщества:

Создаю правило в МСЭ через веб морду и смотрю как формируется JSON, например интерфейс OpenVPN0, на котором не было ни одного правила в первых строках удаляет вроде бы не существующий access-list


[{"access-list":
	{
    	"acl":"_WEBADMIN_OpenVPN0",
     	"no":true
    }
 },
 {
 	"access-list":
    	[{"permit":
       		{"source":"0.0.0.0",
... далее понятно

И ответ подтверждает удаление "message": "_WEBADMIN_OpenVPN0" access list removed."

Вопрос, это необходимая процедура перед началом создания первого правила на интерфейсе, сначала удалить, а потом он автоматически создастся при первом же permit/deny правиле?

И второй вопрос, можно ли одним JSON запросом сформировать сразу все правила (у меня их около 18) на все интерфейсы и тем же запросом сказать {"system":{"configuration":{"save":true}}} ?

1. Нет, эта процедура скоро станет необязательной. Как раз сейчас способ сохранения правил переделывается. Это запрос удаляет цепочку ACL целиком.

2. При сохранении правила цепочка будет создана автоматически. Чтобы сохранить несколько правил -- отсылайте правила массивом, в каждом элементе -- запрос для отдельного интерфейса с массивами в permit и deny

Точную форму запроса можно найти, экспериментируя в Web CLI: my.keenetic.net/a (вкладка REST)

  • Upvote 2

Share this post


Link to post
Share on other sites
  • 0

Спасибо огромное, а за ссылку на /a отдельное спасибо, не знал, а теперь все гораздо проще!

По новому способу хранения правил, значит перед тем как отправлять правила в /rci нужно будет еще и версию release проверять, подскажите с какой версии поменяется алгоритм хранения?

 

Share this post


Link to post
Share on other sites
  • 0
16 минут назад, dvg_lab сказал:

Спасибо огромное, а за ссылку на /a отдельное спасибо, не знал, а теперь все гораздо проще!

По новому способу хранения правил, значит перед тем как отправлять правила в /rci нужно будет еще и версию release проверять, подскажите с какой версии поменяется алгоритм хранения?

 

Изменения попадут в 2.14. При создании списка с нуля (или удалении первой командой) -- ничего не поменяется.

  • Thanks 1

Share this post


Link to post
Share on other sites
  • 0
1 час назад, eralde сказал:

Изменения попадут в 2.14. При создании списка с нуля (или удалении первой командой) -- ничего не поменяется.

А как происходит процедура, когда правило надо втиснуть меж других правил? ...удаляется хвост вписывается правило и добавляется хвост из правил?

Share this post


Link to post
Share on other sites
  • 0
28 минут назад, MDP сказал:

А как происходит процедура, когда правило надо втиснуть меж других правил? ...удаляется хвост вписывается правило и добавляется хвост из правил?

Прямо сейчас -- удаляем все, сохраняем новый список целиком

  • Thanks 1

Share this post


Link to post
Share on other sites
  • 0
Только что, eralde сказал:

Прямо сейчас -- удаляем все, сохраняем новый список целиком

Это приводит к проблемам у некоторых пользователей, поэтому и переработали механизм сохранения.

  • Thanks 1
  • Upvote 1

Share this post


Link to post
Share on other sites
  • 0

Запихиваю вот такой JSON

Скрытый текст



[
    {
        "access-list": {
            "acl": "_WEBADMIN_OpenVPN0",
            "no": "True"
        }
    },
    {
        "access-list": [
            {
                "permit": {
                    "disable": "False",
                    "source-mask": "0.0.0.0",
                    "_": "0",
                    "destination": "0.0.0.0",
                    "schedule": {
                        "no": "True"
                    },
                    "acl": "_WEBADMIN_OpenVPN0",
                    "protocol": "ip",
                    "index": "0",
                    "destination-mask": "0.0.0.0",
                    "action": "permit",
                    "source": "0.0.0.0"
                }
            }
        ]
    },
    {
        "interface": {
            "OpenVPN0": {
                "ip": {
                    "access-group": [
                        {
                            "direction": "in",
                            "acl": "_WEBADMIN_OpenVPN0"
                        }
                    ]
                }
            }
        }
    },
далее идут остальные интерфейсы и сохранение


 

Правила попадают на свои интерфейсы и отображаются в веб интерфейсе, все нормально, но они все в состоянии "Выключено", несмотря на параметр "disable":"False"

Вроде никакого специфичного запроса на включение больше не отлавливается.

Что нужно сделать чтобы они заенаблились? 

Share this post


Link to post
Share on other sites
  • 0
2 минуты назад, dvg_lab сказал:

Запихиваю вот такой JSON

  Скрыть содержимое

 



[
    {
        "access-list": {
            "acl": "_WEBADMIN_OpenVPN0",
            "no": "True"
        }
    },
    {
        "access-list": [
            {
                "permit": {
                    "disable": "False",
                    "source-mask": "0.0.0.0",
                    "_": "0",
                    "destination": "0.0.0.0",
                    "schedule": {
                        "no": "True"
                    },
                    "acl": "_WEBADMIN_OpenVPN0",
                    "protocol": "ip",
                    "index": "0",
                    "destination-mask": "0.0.0.0",
                    "action": "permit",
                    "source": "0.0.0.0"
                }
            }
        ]
    },
    {
        "interface": {
            "OpenVPN0": {
                "ip": {
                    "access-group": [
                        {
                            "direction": "in",
                            "acl": "_WEBADMIN_OpenVPN0"
                        }
                    ]
                }
            }
        }
    },
далее идут остальные интерфейсы и сохранение

 

 

 

 

Правила попадают на свои интерфейсы и отображаются в веб интерфейсе, все нормально, но они все в состоянии "Выключено", несмотря на параметр "disable":"False"

Вроде никакого специфичного запроса на включение больше не отлавливается.

Что нужно сделать чтобы они заенаблились? 

Попробуйте 

"disable": false
  • Thanks 1

Share this post


Link to post
Share on other sites
  • 0
1 минуту назад, eralde сказал:

Попробуйте 


"disable": false

аналогично с schedule

true/false -- не строковые константы, а зарезервированные значения для булевого типа

  • Thanks 1

Share this post


Link to post
Share on other sites
  • 0
57 минут назад, eralde сказал:

аналогично с schedule

true/false -- не строковые константы, а зарезервированные значения для булевого типа

Все получилось, спасибо, на perl если кто столкнётся булев тип в хеше устанавливается так {"disable" => \0} и потом функция JSON->new->utf8->encode() обрабатывает это корректно в false, а true это соотв \1.

Share this post


Link to post
Share on other sites
  • 0

Запрашиваю POST'ом /rci/components/list 

и не пойму почему, но иногда, (чаще после какого-то значительного простоя ,  минут 20 по ощущениям), между GET/POST запросами роутер отвечает кодом 200 и таким контентом:

'_content' => '{                                                                                                
  "continued": true                                                                                                              
}',

При этом следующий такой же запрос уже отвечает по полной форме. Это куда копать? 

 

И еще вопрос, подскажите как в JSON переводится команды "no ip nat" и "ip static Home ISP", чего-то не могу подобрать правильный формат.

Edited by dvg_lab

Share this post


Link to post
Share on other sites
  • 0
14 часа назад, dvg_lab сказал:

Запрашиваю POST'ом /rci/components/list 

и не пойму почему, но иногда, (чаще после какого-то значительного простоя ,  минут 20 по ощущениям), между GET/POST запросами роутер отвечает кодом 200 и таким контентом:


'_content' => '{                                                                                                
  "continued": true                                                                                                              
}',

При этом следующий такой же запрос уже отвечает по полной форме. Это куда копать? .

Есть ряд команд, которые работают долго, поэтому возвращают такой статус если еще не могут выдать ответ. Для них после первого POST-запроса нужно продолжать посылать GET-запросы на тот же ресурс (URL) пока не будет получен ответ без признака continued -- это и будут нужные вам данные.

 

14 часа назад, dvg_lab сказал:

И еще вопрос, подскажите как в JSON переводится команды "no ip nat" и "ip static Home ISP", чего-то не могу подобрать правильный формат.

 В такой форме:

{ip: {nat: {no: true}}}

должно сработать.

 

Во втором случае проще всего посмотреть, что отвечает роутер по GET-запросу rci/ip/static если такое правило создать в CLI (или через веб-интерфейс)

Вот такой POST-запрос на адрес rci/ создает нужное правило:

{
    "ip": {
        "static": {
            "interface": "Home",
            "to-interface": "ISP"
        }
    }
}

 

  • Thanks 1

Share this post


Link to post
Share on other sites
  • 0

Спасибо огромное еще раз! По continued так и сделал, закциклил до нужного ответа. 

С ip static все получилось, намедни правда применил хак, отправил POST к /rci с таким запросом {"parse":"ip static Home ISP"} и это сработало, подсмотрел в /a на вкладке Parse ))

После того как увидел спросил сам себя - А что так можно было?... ))

Вобщем теперь роутер настраивается перловым скриптом за 5 минут, следующий этап прикрутить к нему веб морду и отдать в эксплуатацию.

 

ЗЫЖ Чем лучше сохошный кинетик для кровавого энтерпрайза, чем тот же ZyWall или Cisco  810 и даже RV320, а тем что кинетик можно купить в первом попавшемся магазине. Натравить на него конфигурилку, заббикс и вот тебе корп. VPN сеть для розничных точек. Раньше мне приходилось билдить прошивки для Асусов (RT-N16 и иже с ними), вкорячивать OpenVPN, обвязку и тд, и дохли те асусы словно мухи, ну а теперь красота. Одна печаль 8-портовую Ultra II похоронили, не найти уж в магазинах, успели только 10шт отхватить.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...