gaaronk

Добрый день! Есть Kennetic Start KN-1110. Для соединения двух сетей сейчас используется GRE туннель с IPSec. Аппаратный ускоритель обрабатывает только шифрование, хэширование как я понимаю делается программно. Поэтому для ESP настроено AES128-SHA1 Если заменить IPSec на Wireguard (который полностью программный) - будет ли снижение нагрузки на систему? Проверить самостоятельно сложно - рутер стоит далеко с ограниченным доступом.

Недавно в entware обновился dropbear. Добавили поддержку ed25519. Вот только авторы dropbear для большей совместимости перешли для ecdsa на nistp256 вместо nistp512 В ходе обновления генерируется dropbear_ed25519_host_key, но не трогается существующий dropbear_ecdsa_host_key. А он уже не того формата. Dropbear его не грузит с ошибкой. В итоге вместо host key algorithms: ssh-ed25519,ecdsa-sha2-nistp256,ssh-rsa предлагается только host key algorithms: ssh-rsa Если dropbear_ecdsa_host_key перегенировать руками то все приходит в норму

Так в чем проблема делать через GRE туннели? У меня так и сделано. GRE интерфейсы, шифруются strongswan в транспортном режиме. Внутри GRE и статическая маршрутизация и динамическая.

Добрый день. Включён IPv6 segment в режиме mode dhcp Судя по всему разным клиентам выдаются одинаковые адреса. Как посмотреть dhcp6 lease для домашнего сегмента?

Вопрос. А зачем при включённом ipv6 firewall открыты все порты на вход со стороны оборудования провайдера? В цепочке INPUT есть правило разрешающее все для source fe80::/10 В том числе и со стороны WAN интерфейса. По сути с link local адресов провайдера есть полный доступ к маршрутизатору. версия 3.1.10

Прошу прощения за задержку с ответом. Нет, полиси роутинга нет, но есть IPSec site-to-site. Такое впечатление что дергается в момент перестроения IKE SA, а не IPSec SA. Насчёт -w спасибо, попробую.

Забыл добавить - прошивка 2.15.C.5.0-0

Подскажите пожалуйста, как правильно добавлять правила в цепочку PREROUTING в таблицу mangle ? Надо добавить три правила. Через скрипт в /opt/etc/ndm/netfilter.d/ это сделать НЕ ПОЛУЧАЕТСЯ. Скрипт дергается 5-6 раз в секунду. Вот например время когда вызывался скрипт. Mon Jul 8 06:10:36 MSK 2019 Mon Jul 8 06:10:36 MSK 2019 Mon Jul 8 06:10:36 MSK 2019 Mon Jul 8 06:10:36 MSK 2019 Mon Jul 8 06:10:36 MSK 2019 Mon Jul 8 06:10:49 MSK 2019 Mon Jul 8 06:10:49 MSK 2019 Mon Jul 8 06:10:49 MSK 2019 Mon Jul 8 06:10:49 MSK 2019 Mon Jul 8 06:10:49 MSK 2019 Mon Jul 8 06:10:50 MSK 2019 В итоге получается полная каша. Правила или дублируются, или не вставляются. Или вставляется 1-2 из трех. Как ПРАВИЛЬНО это делать?

Нет не надо. В центре для удаленных точек которые за NAT можно не указывать адрес удаленной точки. tunnel source <WAN> или tunnel source auto а tunnel destination вообще не выставляем. Именно так все и работает, адрес автоматически выставляется на основе политики, полученной от IPsec. Можно даже автотуннели настроить, главное что бы имена интерфейсов на разных концах туннеля совпадали. То есть центре создаете интерфейсы Gre1 и Gre2. На первой удаленной точке делаете Gre1 интерфейс, на второй соотвественно Gre2 Все работает. Все описано. Каждая точка стучится в центр, при смене адреса у нее туннель переподнимается автоматом.

bird лучше Белый адрес нужен только для центра звезды.

Натяните везде GRE туннели и их шифруйте IPSec'ом. А там внутрь туннеля по маршрутизации что хотите то и отправляйте. У меня внутри туннелей бегает ospf на базе bird.

Вставлете правила с уникальным комментарием, например -m comment --comment unic_marker Потом в начале скрипта /opt/sbin/iptables -L -n -t filter | grep -q "unic_marker" && exit 0

А какой опцией передается маршрут? Надо через 249

Да, но нет. МСЭ имеет приоритет перед tunnels input И перед _NDM_IPSEC_INPUT_FILTER. Если я взаимодействую с пиром "B" по GRE с ипеском, то использование МСЭ разрешит любой GRE от "B", и запретит от остальных. Что никак не решает задачу - разрешить GRE ТОЛЬКО от "B" и ТОЛЬКО шифрованный.

А как настроить firewall что бы разрешить только шифрованный GRE ? В цепочке _NDM_IPSEC_INPUT_FILTER мы разрешаем шифрованные GRE от наших пиров, и потом дропаем нешифрованный от них же. Разумно и логично. А потом в _NDM_TUNNELS_INPUT разрешаем от всех остальных... Как это запретить?

Web морда не умеет делать правильные ACL для GRE туннелей. Только в CLI

Привык смотреть первоисточник в шелле =(

Если у вас такая схема, то вам надо обязательно: 1. Обновить кинетик до 2.10 2. Конфигурировать авто туннель на кинетикие в режиме ikev2 3. Посмотреть в /tmp/ipsec/ipsec.conf на кинетике какие он задал leftid и rightid что бы на линуксе настроить строго зеркально 4. Посмотреть в /tmp/ipsec/ipsec.conf на кинетике какие он задал ike, esp, ikelifetime, lifetime что бы на линуксе задать такие же 5. На линуксе в параметрах туннеля использовать как source локальный адрес линукса

Strongswan 5.5.3 Клиент? Тут нет понятия клиент, оба соединения равноправны. У вас кто за NAT - линукс или кинетик? Внешний IP статический или динамический?

Поехали. Zyxel access-list acl-tunnel-gre permit gre <zyxel wan ip> 255.255.255.255 <linux wan ip> 255.255.255.255 interface Gre0 rename LinuxTunnel security-level private ip address 192.168.10.10 255.255.255.252 ip dhcp client no dns-routes ip dhcp client no name-servers ip mtu 1400 ip tcp adjust-mss pmtu tunnel source PPPoE0 tunnel destination <linux wan ip> up ip route 192.168.0.0 255.255.0.0 LinuxTunnel crypto ike proposal ike-aes256-sha256 encryption aes-cbc-256 dh-group 14 integrity sha256 ! crypto ike policy tun-ikev2-policy proposal ike-aes256-sha256 lifetime 86400 mode ikev2 crypto ipsec transform-set esp-aes128-sha1 cypher esp-aes-128 hmac esp-sha1-hmac dh-group 14 lifetime 21600 crypto ipsec profile linux.tunnel.com dpd-interval 20 identity-local fqdn zyxel.tunnel.com match-identity-remote linux.tunnel.com authentication-local pre-share authentication-remote pre-share mode transport policy tun-ikev2-policy crypto map linux-tunnel set-peer <linux wan ip> set-profile linux.tunnel.com set-transform esp-aes128-sha1 match-address acl-tunnel-gre nail-up virtual-ip no enable enable service ipsec Linux - /etc/network/interfaces auto gre2 iface gre2 inet static address 192.168.10.9 netmask 255.255.255.255 up ip link set gre2 mtu 1400 pre-up iptunnel add gre2 mode gre remote <zyxel wan ip> local <linux wan ip> dev eth1 ttl 64 pointopoint 192.168.10.10 post-down iptunnel del gre2 Linux - /etc/ipsec.conf conn %default right=%any compress=no dpddelay=20s dpdtimeout=60s installpolicy=yes fragmentation=yes keyexchange=ikev2 ike=aes256-aes128-sha256-modp2048,aes256gcm16-aes128gcm16-prfsha256-modp2048! mobike=no conn tmpl-static-tun-transport dpdaction=clear ike=aes256-sha256-modp2048,aes256gcm16-prfsha256-modp2048! esp=aes128-sha1-modp2048,aes128gcm16-modp2048! ikelifetime=24h keyexchange=ikev2 keyingtries=1 lifetime=6h inactivity=10m type=transport conn zyxel-tun also=tmpl-static-tun-transport left=<linux-wan-ip> leftauth=psk leftid="linux.tunnel.com" leftsubnet=%dynamic[gre] right=<zyxel-wan-ip> rightauth=psk rightid="zyxel.tunnel.com" rightsubnet=%dynamic[gre] auto=route

Отлично работают GRE IPsec туннели с Debian. Стабильно Вы в ACL должны указывать концы туннеля, а не трафик внутри туннеля. А трафик внутрь заворачивайте маршрутизацией.

Да собственно оно мне и не больно надо. Опечатки были в исходном скрипте который правился.

Ну зачем? Напишите свой скрипт который пускается при старте системы и делает в бесконечном цикле sleep на минуту. И ловит сигнал HUP, при старте wan ему дают сигнал и он включает счетчик. После того как счетчик будет 10 - сбрасываем его и смотрим адрес на WAN. Если все плохо - рестартуем сессию. Или при старте WAN пишите файл флаг в tmp, и чекайте его по крону. Вариантов масса.

Бред какой

Да не надо ломать легаси. Оставить его поведением по умолчанию. Дать немного больше "ручек" в CLI для страждущих.