gaaronk
-
Posts
299 -
Joined
-
Days Won
3
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by gaaronk
-
-
Можно скриптом /opt/etc/ndm/netfilter.d/02_nat.sh
#!/bin/sh [ "$table" != "nat" ] && exit 0 /opt/sbin/iptables -t nat -A _NDM_IPSEC_POSTROUTING_NAT -o ngre+ -j ACCEPT /opt/bin/logger -t "iptables" "Add GRE rules to table $table"Только имя -o <интерфейс> задайте нужное вам
-
Ну меня слишком много, но все же
psk_authenticator.c строка 73
if (key != NULL) { DBG1(DBG_IKE, "found linked key for crypto map '%s'", ike_sa_name); } elseРазве не надо перед выводом дебага сделать что то вроде
my_id = this->ike_sa->get_my_id(this->ike_sa);
Что бы потом использовать my_id при вызове (строка 91)
if (!keymat->get_psk_sig(keymat, FALSE, this->ike_sa_init, this->nonce, key->get_key(key), my_id, this->reserved, &auth_data))А то получается что если мы нашли linked key то my_id не определяется.
Если все это бред, то удалите топик пожалуйста.
-
1
-
-
Just now, Le ecureuil said:
И где там в логе проблемы с флешкой?
Этот крешдамп из mtdoops валяется еще с версии 2.09.A.3-0, то есть уже минимум месяц. К текущим событиям он отношения не имеет. Или имеет, но тогда опять-таки нужны нормальные логи.
Виноват, исправлюсь
-
Разобрался где косяк (?)
Итак крипто профайл вида
crypto ipsec profile remote.domain.com dpd-interval 20 identity-local fqdn local.domain.com match-identity-remote fqdn remote.domain.com authentication-local pre-share authentication-remote pre-share mode transport policy tun-ikev2-policy preshared-key ns3 <PSK>
Мы иницируем установку туннеля.
В момент IKE сессии передаем свое ID как local.domain.com но, начинаем вычислять на своей стороне MAC с использованием ID remote.domain.com
Mar 22 23:03:10ipsec11[IKE] IKE_CERT_PRE task Mar 22 23:03:10ipsec11[IKE] IKE_AUTH task Mar 22 23:03:10ipsec11[IKE] found linked key for crypto map 'test-tunnel' Mar 22 23:03:10ipsec11[IKE] IDx' => 22 bytes @ 0x75ef5ba0 Mar 22 23:03:10ipsec11[IKE] 0: 02 00 00 00 XX XX XX XX XX XX XX XX XX XX XX XX ....remote.domain Mar 22 23:03:10ipsec11[IKE] 16: 2E 63 6F 6D .com Mar 22 23:03:10ipsec11[IKE] SK_p => 32 bytes @ 0x471ef8 Mar 22 23:03:10ipsec11[IKE] 0: A2 DA A4 C6 E6 65 84 DD A6 CC CF 2E 5F 3D 36 DF .....e......_=6. Mar 22 23:03:10ipsec11[IKE] 16: 89 D5 05 F3 94 A0 A9 20 36 C7 75 5F 98 F1 97 D9 ....... 6.u_.... Mar 22 23:03:10ipsec11[IKE] octets = message + nonce + prf(Sk_px, IDx') => 528 bytes @ 0x471418 Mar 22 23:03:10ipsec11[IKE] 0: BD ED 37 4A 8B D9 5A 22 00 00 00 00 00 00 00 00 ..7J..Z"........Что приводит к
Mar 22 23:03:12ipsec 15[IKE] received AUTHENTICATION_FAILED notify error
Если мы из профайла уберем preshared-key и опишем его какcrypto ike key test-key ns3 <PSK> fqdn remote.domain.comТо все хорошо. Мы передаем свое ID как local.domain.com и начинаем вычислять на своей стороне MAC с использованием ID local.domain.comMar 22 23:17:50ipsec03[IKE] IKE_AUTH task Mar 22 23:17:50ipsec03[IKE] linked key for crypto map 'test-tunnel' is not found, still searching Mar 22 23:17:50ipsec03[IKE] authentication of 'local.domain.com' (myself) with pre-shared key Mar 22 23:17:50ipsec03[IKE] IDx' => 21 bytes @ 0x76becba0 Mar 22 23:17:50ipsec03[IKE] 0: 02 00 00 00 XX XX XX XX XX XX XX XX XX XX XX XX ....local.domain Mar 22 23:17:50ipsec03[IKE] 16: 2E 63 6F 6D .com Mar 22 23:17:50ipsec03[IKE] SK_p => 32 bytes @ 0x8113c0 Mar 22 23:17:50ipsec03[IKE] 0: 96 2E 4D 0C 3F D8 D8 FA 95 D8 22 7C 6C 80 73 98 ..M.?....."|l.s. Mar 22 23:17:50ipsec03[IKE] 16: AD E5 2B 56 F4 46 B0 22 D3 EE 1E 88 A8 11 E1 79 ..+V.F.".......y Mar 22 23:17:50ipsec03[IKE] octets = message + nonce + prf(Sk_px, IDx') => 528 bytes @ 0x813140В итоге
Mar 22 23:17:57ipsec 06[IKE] authentication of 'remote.domain.com' with pre-shared key successful
-
1
-
-
Судя по логу у вас не закрывались CHILD_SA после rekeying
Интересно было бы взглянуть на self-test
-
А разве проблеме не во флешке?
"<3>SQUASHFS error: xz_dec_run error, data probably corrupt", "<3>SQUASHFS error: squashfs_read_data failed to read block 0x99e3a4", "<3>SQUASHFS error: Unable to read fragment cache entry [99e3a4]", "<3>SQUASHFS error: Unable to read page, block 99e3a4, size 857c", "<3>SQUASHFS error: Unable to read fragment cache entry [99e3a4]", "<3>SQUASHFS error: Unable to read page, block 99e3a4, size 857c", "<0>Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000a", -
Зарулить можно. Только надо на каждом spoke (луче) описать выделение трафика для засовывание в ipsec как
<local network> - <сеть центельного узла>
<local network> - <сеть spoke2>
<local network> - <сеть spoke3>
и тд. Что не очень удобно, но работает. Кинетик же из списка доступа читает только первую строчку. По этому обычно делают туннели и внутри них гоняют маршруты.
Сделайте full-mesh - туннель между 4G и "второй ультрой"
С выделением трафика 192.168.13.128/25 - 192.168.10.0/24
-
10 minutes ago, des said:
Нет, он не поддерживается самим модулем, а перекодирование на роутере может достаточно сильно занимать процессор. В принципе, если сильно нужно, можно сделать, но чем он лучше, чем G711? Сильнее сжатие, но при этом больше потребление процессора, да еще и сам кодек платный.
Просто в моей специфической ситуации все мои SIP пиры принимают только G729.
Сейчас для телефонии стоит SPA3102, в нее воткнута DECT база. Хотелось бы SPA задействовать под другие задачи и убрать лишнее преобразование аналог-цифрв.
Если самим модулем не поддерживается то проще наверное поднять астериск из entware, зарегистрировать модуль на нем и делать рекодинг астериском.
-
Скажите, а модуль DECT поддерживает кодек G729 ?
-
Не могу найти информацию.
Модуль Keenetic Plus DECT поддерживает кодек g729 ?
-
6 minutes ago, KorDen said:
Нужно использовать туннели (например IPIP) поверх IPsec, голым IPsec это не получится, IPsec-туннели нельзя маршрутизировать. В простейшем режиме можно два автоматических туннеля (по одному серверу на каждой ультре, клиенты на средней ультре и 4g), либо полностью ручной режим, т.е. создавать транспорты и затем уже IPIP-туннели.
Голым IPSec это получится, но не на кинетике, где для селектора трафика можно использовать только один элемент ACL.
Можно на средней ультре делать двусторонний NAT, что бы клиент лез к адресам из диапазона 192.168.13.0/128, а его натило в src из сети192.168.13.0/128 dst 192.168.10.230
Ну и virce versa.
-
1
-
-
14 minutes ago, KorDen said:
А если прилетит на открытый порт? Например: 192.168.2.1/24 - маршрутизируется через туннель, со стороны ISP разрешен доступ, скажем, к порту udp/12345 (но сервис не запущен), из-за неполадок у ISP дефолтный маршрут через LTE, прилетает пакет со 192.168.2.3 со стороны ISP на myip:12345 - не уйдет ли вдруг на LTE с моим же внешним IP ISP или что подобное?
Поясню немного свою позицию. NAT не является средством контроля и безопасности. Использовать его для этого - опасно. Это всего лишь правила по которым меняются source и/или destination адреса/порты у пакетов в зависимости от кого/кому предназначен пакет, через какой интерфейс он входит/выходит.
Контролировать доступ, кто куда может ходить, по каким портам и адресам - надо в filter.
Если пакет предназначен адресу вашего рутера он обработается в цепочке INPUT, если он транзитный то в FORWARD. Вот там и контролируйте. По умолчанию в кинетике пакет нового соединения не будет маршрутизироваться если он пришел из public интерфейса, то есть ваш рутер при нескольких провайдерах не будет транзитным.
Транзит разрешен от private - ко всем и и от protected к public
-
3 minutes ago, KorDen said:
А если прилетит на открытый порт? Например: 192.168.2.1/24 - маршрутизируется через туннель, со стороны ISP разрешен доступ, скажем, к порту udp/12345 (но сервис не запущен), из-за неполадок у ISP дефолтный маршрут через LTE, прилетает пакет со 192.168.2.3 со стороны ISP на myip:12345 - не уйдет ли вдруг на LTE с моим же внешним IP ISP или что подобное?
Нет конечно. Раз прилетает на IP рутера, то в FORWARD оно не попадет и НЕ будет маршрутизироваться. Рутер ответит скорее всего icmp unreachable.
-
25 minutes ago, KorDen said:
Еще вопрос: Если к примеру есть домашняя сеть 192.168.0.1/24, гостевая (.1.1/24), и два туннеля (за ними .2.1/24 и .3.1/24) (выход через ISP и резерв на LTE) - правильно ли понимаю, что вместо описывания "матрицы интерфейсов" можно сделать что-то вроде:
ip static 192.168.0.0/22 ISP
ip static 192.168.0.0/22 UsbLte0Или в таком виде могут быть скрытые сюрпризы, если например со стороны ISP вдруг прилетит пакет с IP из этого диапазона?
Если такой пакет прилетит от ISP то его срежет фильтр.
-
В любом случае спасибо и за такую реализацию. Я прекрасно понимаю как важна обратная совместимость и стабильность взаимодействия с остальными компонентами.
Я просто порассуждал на тему логики работы NAT. Возможно это будет интересно и вам (в будущем).
-
Отлично, спасибо!
Вопрос ради интереса на логику.
Если мы задействует этот механизм, то например если у у нас локалка, гостевая сеть, приватный туннель и выход через ISP в MAN и PPPoE в WAN, то нам надо написать такие правила
ip static Home ISP
ip static Home PPPoE
ip static Guest ISP
ip static Guest PPPoE
ip static Gre0 ISP
ip static Gre0 PPPoE
По сути полную матрицу, если что то не опишем - в сторону провайдера уйдут не транслированные адреса, что некрасиво.
Вариант "ip static out <WAN_INT>" подразумевает что то вроде
-A POSTROUTING ! -s <WAN_IP>/32 -o <WAN_INTERFACE> -j MASQUERADE
В этом случае на выход через этот интерфейс (на котором от нас ожидается только трафик от выданного нам IP) мы всегда идем с правильным source IP.
Или такой механизм затратнее чем матчить по source интерфейсу? Ну а команды в CLI на то и даны только в CLI что пользоваться ими без понимания не надо.
-
1
-
-
Я вот IPv6 использую.
Провайдером делегировна префикс, раздаю его внутри. Для раздачи адресов используется SLAAC, а stateless DHCP для выдачи дополнительных DHCP серверов, NTP сервера, domain-search и некоторых других опций.
Со stateful DHCPv6 макось плохо дружит.
-
Ну вот пока такой костыль который не NATит в сторону gre (мой частный случай) тоннелей и NATит трафик из туннелей на выходе из public интерфейсов
#!/bin/sh [ "$table" != "nat" ] && exit 0 /opt/sbin/iptables -t nat -A _NDM_IPSEC_POSTROUTING_NAT -o ngre+ -j ACCEPT /opt/sbin/iptables -t nat -A _NDM_STATIC_SNAT -i ngre+ -p udp -j _NDM_NAT_UDP /opt/sbin/iptables -t nat -A _NDM_STATIC_SNAT -i ngre+ -j MASQUERADE
-
И кроме того - выборочное включение, ибо трафик пришедший через туннель вполне имеет право уйти в Интернет и должен будет пронатиться.
Или как вариант в CLI разрешить использовать обычную, а не инверсную логику NAT - делать на выходе из интерфейса
Что то вроде
ip nat out ISP
-
А в скриптах /opt/etc/ndm/netfilter.d/ при использовании "встроенного" iptables он выпадает в Segmentation fault
Хотя просто из шелла работает.
Надо обязательно ставить iptables из пакетов?
Версия release: v2.08(AAUW.0)C1
-
8 minutes ago, r13 said:
Пока есть только хотелка
Нет, ну есть костыль подпинывать ACCEPT через /opt/etc/ndm/netfilter.d
Но это плохая идея. Правила "дергаются" очень часто, можно не успеть со своим скриптом и пара тройка транзитных пакетов улетит в NAT
-
И еще вопрос.
Попробовал поднять просто IPSec туннель между Giga и удаленным офисом. Локалка на гиге 192.168.19.0/24, на удаленной точке пачка разных сетей вида 192.168.Х.0/24
Описываем концы туннеля как 192.168.19.0/24 - 192.168.0.0/16
IPSec поднимается и.... и все умирает.
Как минимум правила вида
Chain _NDM_IPSEC_INPUT_FILTER (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ndmmark match 0x88
0 0 DROP all -- * * 192.168.0.0/16 192.168.19.0/24Убивают пакет от локальной сети к самому рутеру.
И в таблице mangle есть в достатке таких нюансов.
-
А как настроить что бы при прохождении трафика из сегмента Home в GRE туннель к трафику не применялся NAT ?
-
Версия ПО v2.08(AAUW.0)C1
При конфигурировании сегмента локальной сети Home система позаолила задать адрес интерфейса вида 192.168.10.0 255.255.255.0 , то есть адрес сети.
Доступ с локального компютера с адресом 192.168.10.2/24 был потерян. Хотя когда на компьютере был настроен адрес 192.168.10.2/16, удалось подключиться к рутеру по адресу http://192.168.10.0
IPsec(Ikev2) и Iphone
in Обсуждение IPsec, OpenVPN и других туннелей
Posted
Конечно будут работать одновременно и IKEv1 и IKEv2