gaaronk

Скажите, а модуль DECT поддерживает кодек G729 ?

Не могу найти информацию. Модуль Keenetic Plus DECT поддерживает кодек g729 ?

Голым IPSec это получится, но не на кинетике, где для селектора трафика можно использовать только один элемент ACL. Можно на средней ультре делать двусторонний NAT, что бы клиент лез к адресам из диапазона 192.168.13.0/128, а его натило в src из сети192.168.13.0/128 dst 192.168.10.230 Ну и virce versa.

Поясню немного свою позицию. NAT не является средством контроля и безопасности. Использовать его для этого - опасно. Это всего лишь правила по которым меняются source и/или destination адреса/порты у пакетов в зависимости от кого/кому предназначен пакет, через какой интерфейс он входит/выходит. Контролировать доступ, кто куда может ходить, по каким портам и адресам - надо в filter. Если пакет предназначен адресу вашего рутера он обработается в цепочке INPUT, если он транзитный то в FORWARD. Вот там и контролируйте. По умолчанию в кинетике пакет нового соединения не будет маршрутизироваться если он пришел из public интерфейса, то есть ваш рутер при нескольких провайдерах не будет транзитным. Транзит разрешен от private - ко всем и и от protected к public

Нет конечно. Раз прилетает на IP рутера, то в FORWARD оно не попадет и НЕ будет маршрутизироваться. Рутер ответит скорее всего icmp unreachable.

Если такой пакет прилетит от 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 что пользоваться ими без понимания не надо.

Я вот 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

Нет, ну есть костыль подпинывать 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 ?

И в догонку. Если делать lifetime большим, например сутки, то strongswan не закрывает уже не используемые CHILD_SA пока не истечет их таймаут. Поэтому 70 минут было выбрано "для красоты", что бы swan оперативно закрывал все лишнее.

А при чем тут аппаратное ускорение? Мы говорим про IKE, а не ESP. Аппаратное ускорение используется для шифрования трафика, а не для протокола обмена ключами.

А чем принципиально отличается задача PSK через crypto ike key и crypto ipsec profile \ preshared-key ? Для статических туннелей "crypto ike key" работает, а задача PSK через "crypto ipsec profile \ preshared-key" нет. Во втором случае в ipsec.secrets записывается что то вида "cmap:test-tunnel : PSK "<..>" Про такой вариант селектора в документации стронгсвана не написано...

Если мы говорим про IOS или MacOS с его кривым ракуном, то проблема в том что они не могут сделать reauth если его инициирует сервер, а reauth для IKEv1 обязателен. Только если они инициирует его сами. При этом lifitime жестко вшит, и составляет 3600 секунд. Для Apple надо настраивать strongswan так, что бы сервер сам никогда не инициировал reath и rekey. Примерно так (кусок конфига выстраданный долгой отладкой, ковырянием сорцов и перепиской с авторами стронгсвана): ikelifetime=70m lifetime=70m rekeyfuzz=0% margintime=5m При авторизации только по PSK или сертификату, без Xauth, то будет работать. Если дополнительно настроить XAuth по паролю, то работать все равно не будут. Продукты apple не хранят в памяти логин\пароль, и НЕ умеют заново запросить его у пользователя.

Это видимо в 2.09, я не указал свою версию ПО. У меня стабильная 2.08 ip adjust-ttl send 64 Command::Base error[7405602]: inc: argument parse error. Впрочем это надо было для работы OSPF, и уже не актуально, так как в bird можно сказать на интерфейсе ttl security tx only; И он начнет слать мультикаст пакет с TTL 255, а не 1.

Сейчас максимально возможная длина 68 символов. Думаю стоит ограничить в 128. Процитирую вики стронгсвана As you can see from the above formula, the maximum key size a HMAC-based prf can handle is equivalent to its internal block size which is 512 bits or 64 bytes for SHA-1 and SHA-2_256 or 1024 bits or 128 bytes for SHA-2_384 and SHA-2_512. Thus a restriction to a 64 byte PSK makes sense if you don't care for the HMAC being used. If you explicitly specify sha384 or sha512 in your ike= parameter, then a PSK of up to 128 bytes is possible.

Можно ли для GRE туннеля явно задать TTL, вместо inherit ? Или как можно выполнить что то вроде ip tun change ngre0 ttl 64 сразу по поднятию интерфейса?

При использовании для IPSec достаточно длинного PSK - 120 символов, при выполнении sh run получаю в выводе ! ERROR: command "crypto ike key": not enough arguments !Command::Argument::Password ERROR[268304478]: out of memory [0xcffe005e]. А в логе Mar 08 14:08:34ndmCommand::Argument::Password: out of memory [0xcffe005e]. Mar 08 14:08:34ndmCommand::Argument::Password: out of memory [0xcffe005e]. При этом ввести в CLI такой PSK можно, файл /var/ipsec/ipsec.secrets создается верный, туннель работает. ПО release: v2.08(AAUW.0)C1