gaaronk Posted May 9, 2017 Share Posted May 9, 2017 Прошивка 2.09.A.7.0-2 Настроены туннели GRE. Для них руками поднят IPSec примерно так. access-list acl-test-gre permit gre 1.1.1.1 255.255.255.255 2.2.2.2 255.255.255.255 crypto map test-tunnel set-peer 2.2.2.2 set-profile remote.test.com set-transform esp-aes128-sha1 match-address acl-test-gre nail-up virtual-ip no enable enable где 1.1.1.1 локальный адрес на PPPoE соединении (он статический всегда выдается один и тот же) Пр этом у стронгсвана создается конфиг conn test-tunnel keyingtries = 1 margintime = 20s rekeyfuzz = 100% lifebytes = 21474836480 closeaction = none leftupdown = /tmp/ipsec/charon.left.updown rightupdown = /tmp/ipsec/charon.right.updown ike = aes256-sha256-modp2048! ikelifetime = 86400s keyexchange = ikev2 mobike = no esp = aes128-sha1-modp2048! lifetime = 21600s dpdaction = restart dpddelay = 20s dpdtimeout = 60s leftid = fqdn:local.test.com leftauth = psk rightid = fqdn:remote.test.com rightauth = psk type = transport left = %any right = 2.2.2.2 leftsubnet = 1.1.1.1/32[47] rightsubnet = 2.2.2.2/32[47] auto = route rekey = yes И вроде бы все хорошо, НО! В Routed Connections: как source адрес выставляется либо адрес туннельного интерфейса, либо адрес ezcfg0 интерфейса Вижу Routed Connections: test-tunnel{2}: ROUTED, TRANSPORT, reqid 2 test-tunnel{2}: 78.47.125.180/32[gre] === 2.2.2.2/32[gre] Если сделать руками /usr/lib/ipsec/stroke route test-tunnel То Routed Connections: test-tunnel{2}: ROUTED, TRANSPORT, reqid 2 test-tunnel{2}: 3.3.3.3/32[gre] === 2.2.2.2/32[gre] Где 3.3.3.3/32 адрес на ngre интерфейсе Но ни разу не видел что бы был адрес PPPoE интерфейса Еще вопрос - как убрать lifebytes ? UPD Если strongswan стартовал до того как поднялся интернет (бывает такое что провайдер не отвечает и pppoe долго стартует) то в Routed Connections: как source адрес выставляется адрес ezcfg0 интерфейса Если потом после поднятия инета сделать руками /usr/lib/ipsec/stroke route test-tunnel то в Routed Connections: как source адрес выставляется адрес старшего ngre интерфейса, если в системе три туннеля то берется адрес от ngre2 Quote Link to comment Share on other sites More sharing options...
gaaronk Posted May 9, 2017 Author Share Posted May 9, 2017 Так. Бага интересная. Есть отдельная таблица маршрутизации (номер 200) где прописан дефолт в сторону ngre2 интерфейса. В основной таблице дефолт в сторону ppp0 интерфейса. В ip rule правил для этой таблицы нет. Strongswan все равно использует ее для вычисления source address для route trap. Если ее очистить то все становится хорошо. При этом на "большом" линуксе есть и аналогичная таблица с отдельным дефолтом, есть и правила ссылающиеся на нее, но Strongswan так странно себя не ведет. Quote Link to comment Share on other sites More sharing options...
gaaronk Posted May 9, 2017 Author Share Posted May 9, 2017 Пока подпер костылем /opt/etc/ndm/wan.d/01_swan.sh #!/bin/sh [ -z "$interface" ] && exit 0 /usr/lib/ipsec/stroke statusall | grep -q "78\.47\.125\.180\/32" if [ $? -eq 0 ]; then ip route del default table 200 /usr/lib/ipsec/stroke route test-tunnel /opt/bin/logger -t "swan-fix" "Re-route VPN connections" fi exit 0 Маршрут в таблице 200 потом сам появится, через динамику. Quote Link to comment Share on other sites More sharing options...
gaaronk Posted May 9, 2017 Author Share Posted May 9, 2017 Плохой, негодный костыль. К тому же валится в сегфолт, видимо из-за использования /usr/lib/ipsec/stroke Нужен мегакостыль! В /opt/etc/init.d лежит у меня S01system отрабатывающий при старте системы оттуда запускаем # Strongswan fixup /opt/usr/sbin/swan-fix.sh & и сам swan-fix.sh #!/bin/sh while true; do sleep 3 SPID=`pidof charon` if [ ! -z "$SPID" ]; then sed -i 's/cisco_unity = no/cisco_unity = no\n\tinterfaces_ignore = "ngre1, ezcfg0"/g' /tmp/ipsec/strongswan.conf kill $SPID /opt/bin/logger -t "swan-fix" "Fix strongswan routing" exit 0 fi done Так и живем 1 Quote Link to comment Share on other sites More sharing options...
KorDen Posted May 9, 2017 Share Posted May 9, 2017 8 минут назад, gaaronk сказал: Так и живем Небольшой оффтоп, но... Понятно, что речь о фиксах прошивочного strongswan, но вы же вроде уже пользовались лебедем из Entware - чем он вас не устраивает с точки зрения работы в транспортном режиме, какого взаимодействия не хватает? Интересуюсь потому, что мне надоело ждать сертификаты, хочется поэкспериментировать с настройками, и поэтому я сейчас медленно перехожу на strongswan из Entware. Больше всего боялся, что аппаратное шифрование не взлетит, или придется устраивать много костылей - как оказалось, напрасно боялся, по крайней мере в простом виде с одним туннелем оно взлетело само. Quote Link to comment Share on other sites More sharing options...
gaaronk Posted May 9, 2017 Author Share Posted May 9, 2017 Я пользуюсь прошивочным лебедем на кинетике и на асусе с падаваном (собирал сам). Можно и из entware поставить, но он живет на флешке, а рутера от меня в 1200 км и 800 км. Если флешка умрет, то худо бедно, пусть с задержкой но туннели поднимутся. Можно будет попросить воткнуть другую флешку и все настроить заново. Quote Link to comment Share on other sites More sharing options...
gaaronk Posted May 9, 2017 Author Share Posted May 9, 2017 20 minutes ago, KorDen said: Небольшой оффтоп, но... Понятно, что речь о фиксах прошивочного strongswan, но вы же вроде уже пользовались лебедем из Entware - чем он вас не устраивает с точки зрения работы в транспортном режиме, какого взаимодействия не хватает? Интересуюсь потому, что мне надоело ждать сертификаты, хочется поэкспериментировать с настройками, и поэтому я сейчас медленно перехожу на strongswan из Entware. Больше всего боялся, что аппаратное шифрование не взлетит, или придется устраивать много костылей - как оказалось, напрасно боялся, по крайней мере в простом виде с одним туннелем оно взлетело само. А дома у меня рутер это стоковый дебиан в виртуалке на сервере виртуальных машин. Там бэкпортированный мной сван 5.5.2, там уже все - и сертификаты, и туннели, и remote access и L2TP и Cisco IKEv1 и IKEv2, и так и сяк и с радиусом сбоку для EAP. Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted May 10, 2017 Share Posted May 10, 2017 Насчет lifebytes - пока наверное никак, это сделано для обхода sweet32. Тем более у вас rekey нормально должен отработать, волноваться смысла мало. Насчет interfaces_ignore - тема поднята интересная, как минимум невалидные интерфейсы вроде ezcfg0 туда внесем однозначно, а вот с командой для ручного задания нужно подумать. Суть в том, что ручной туннельный режим практически никто не проверял, поскольку у него было изсчезающе мало применений было до появления Gre/EoIP/IPIP. Quote Link to comment Share on other sites More sharing options...
gaaronk Posted May 10, 2017 Author Share Posted May 10, 2017 Ну ручной ipsec в транспортном режиме я оттестировал очень плотно. Все работает на ура. Кроме бага с linked key for crypto map о котором я писал и вот этого с таблицами маршрутизации. В отдельной таблице у меня дефолт и правилами ip rule на эту таблицу у меня заворачивается "интересный" трафик. А команда для ручного режима желательна конечно. Ну или буду использовать свой мегакостыль на старте. lifebytes да, абсолютно не мешает, это просто "для красоты", но раз оно надо то и хорошо. Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted May 10, 2017 Share Posted May 10, 2017 1 минуту назад, gaaronk сказал: Ну ручной ipsec в транспортном режиме я оттестировал очень плотно. Все работает на ура. Кроме бага с linked key for crypto map о котором я писал и вот этого с таблицами маршрутизации. В отдельной таблице у меня дефолт и правилами ip rule на эту таблицу у меня заворачивается "интересный" трафик. А команда для ручного режима желательна конечно. Ну или буду использовать свой мегакостыль на старте. lifebytes да, абсолютно не мешает, это просто "для красоты", но раз оно надо то и хорошо. linked key for crypto map был практически сразу же починен. Quote Link to comment Share on other sites More sharing options...
gaaronk Posted May 10, 2017 Author Share Posted May 10, 2017 1 minute ago, Le ecureuil said: linked key for crypto map был практически сразу же починен. Отлично, сейчас проверим. Quote Link to comment Share on other sites More sharing options...
gaaronk Posted May 10, 2017 Author Share Posted May 10, 2017 (edited) А вот и косвенная бага. У меня два туннеля. оба траспорт, оба без connect - enable IPsec crypto map autoconnection В конфиге auto = route Когда по живому реконфигурируешь crypto ipsec profile то соединение естественно падает и поднимается, второе соединение остается в состоянии ESTABLISHED. Но! Для него пропадает секция ROUTED, TRANSPORT В логе видно May 10 12:21:19ndmIpSec::Configurator: start reloading IPsec config task. May 10 12:21:19ipsec12[CFG] received stroke: unroute 'first-tunnel' May 10 12:21:19ipsecconfiguration 'first-tunnel' unrouted May 10 12:21:19ipsec May 10 12:21:19ipsec16[CFG] received stroke: delete connection 'first-tunnel' May 10 12:21:19ipsec16[CFG] deleted connection 'first-tunnel' May 10 12:21:19ipsec10[CFG] received stroke: unroute 'second-tunnel' May 10 12:21:19ipsecconfiguration 'second-tunnel' unrouted May 10 12:21:19ipsec May 10 12:21:19ipsec13[CFG] received stroke: delete connection 'second-tunnel' May 10 12:21:19ipsec13[CFG] deleted connection 'second-tunnel' May 10 12:21:19ipsec00[DMN] signal of type SIGHUP received. Reloading configuration May 10 12:21:19ipsec05[CFG] received stroke: add connection 'first-tunnel' May 10 12:21:19ipsec00[CFG] loaded 0 entries for attr plugin configuration May 10 12:21:19ipsec05[CFG] added configuration 'first-tunnel' May 10 12:21:19ipsec11[CFG] received stroke: add connection 'second-tunnel' May 10 12:21:19ipsec11[CFG] added configuration 'second-tunnel' May 10 12:21:19ndmIpSec::Configurator: reloading IPsec config task done. May 10 12:21:19ndmIpSec::IpSecNetfilter: start reloading netfilter configuration... May 10 12:21:19ndmIpSec::IpSecNetfilter: netfilter configuration reloading is done. May 10 12:21:21ndmIpSec::Configurator: crypto map "second-tunnel" shutdown started. May 10 12:21:21ipsec16[CFG] received stroke: unroute 'second-tunnel' May 10 12:21:21ipsec10[CFG] received stroke: terminate 'second-tunnel{*}' May 10 12:21:22ndmIpSec::Configurator: crypto map "second-tunnel" routing started. May 10 12:21:22ipsec07[CFG] received stroke: route 'second-tunnel' May 10 12:21:22ndmIpSec::Configurator: crypto map "second-tunnel" routing complete. Меняли second-tunnel Зачем то оно делало received stroke: unroute 'first-tunnel' received stroke: delete connection 'first-tunnel' хотя по факту первый туннель "не сложился" а вот route 'first-tunnel' потом не пришло linked key работает UPD 2.09.A.7.0-2 Edited May 10, 2017 by gaaronk Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted May 10, 2017 Share Posted May 10, 2017 10 часов назад, gaaronk сказал: А вот и косвенная бага. У меня два туннеля. оба траспорт, оба без connect - enable IPsec crypto map autoconnection В конфиге auto = route Когда по живому реконфигурируешь crypto ipsec profile то соединение естественно падает и поднимается, второе соединение остается в состоянии ESTABLISHED. Но! Для него пропадает секция ROUTED, TRANSPORT В логе видно May 10 12:21:19ndmIpSec::Configurator: start reloading IPsec config task. May 10 12:21:19ipsec12[CFG] received stroke: unroute 'first-tunnel' May 10 12:21:19ipsecconfiguration 'first-tunnel' unrouted May 10 12:21:19ipsec May 10 12:21:19ipsec16[CFG] received stroke: delete connection 'first-tunnel' May 10 12:21:19ipsec16[CFG] deleted connection 'first-tunnel' May 10 12:21:19ipsec10[CFG] received stroke: unroute 'second-tunnel' May 10 12:21:19ipsecconfiguration 'second-tunnel' unrouted May 10 12:21:19ipsec May 10 12:21:19ipsec13[CFG] received stroke: delete connection 'second-tunnel' May 10 12:21:19ipsec13[CFG] deleted connection 'second-tunnel' May 10 12:21:19ipsec00[DMN] signal of type SIGHUP received. Reloading configuration May 10 12:21:19ipsec05[CFG] received stroke: add connection 'first-tunnel' May 10 12:21:19ipsec00[CFG] loaded 0 entries for attr plugin configuration May 10 12:21:19ipsec05[CFG] added configuration 'first-tunnel' May 10 12:21:19ipsec11[CFG] received stroke: add connection 'second-tunnel' May 10 12:21:19ipsec11[CFG] added configuration 'second-tunnel' May 10 12:21:19ndmIpSec::Configurator: reloading IPsec config task done. May 10 12:21:19ndmIpSec::IpSecNetfilter: start reloading netfilter configuration... May 10 12:21:19ndmIpSec::IpSecNetfilter: netfilter configuration reloading is done. May 10 12:21:21ndmIpSec::Configurator: crypto map "second-tunnel" shutdown started. May 10 12:21:21ipsec16[CFG] received stroke: unroute 'second-tunnel' May 10 12:21:21ipsec10[CFG] received stroke: terminate 'second-tunnel{*}' May 10 12:21:22ndmIpSec::Configurator: crypto map "second-tunnel" routing started. May 10 12:21:22ipsec07[CFG] received stroke: route 'second-tunnel' May 10 12:21:22ndmIpSec::Configurator: crypto map "second-tunnel" routing complete. Меняли second-tunnel Зачем то оно делало received stroke: unroute 'first-tunnel' received stroke: delete connection 'first-tunnel' хотя по факту первый туннель "не сложился" а вот route 'first-tunnel' потом не пришло linked key работает UPD 2.09.A.7.0-2 А можно попродробнее, прямо с тестовым конфигом с которого начинаем и командами в CLI, исполняемыми по порядку? Есть шанс, что сейчас заборем это дело. Quote Link to comment Share on other sites More sharing options...
gaaronk Posted May 11, 2017 Author Share Posted May 11, 2017 11 hours ago, Le ecureuil said: А можно попродробнее, прямо с тестовым конфигом с которого начинаем и командами в CLI, исполняемыми по порядку? Есть шанс, что сейчас заборем это дело. Вот куски конфига access-list acl-first-gre permit gre 5.5.5.5 255.255.255.255 1.1.1.1 255.255.255.255 ! access-list acl-second-gre permit gre 5.5.5.5 255.255.255.255 2.2.2.2 255.255.255.255 interface Gre0 rename First security-level private ip address 192.168.1.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 1.1.1.1 up ! interface Gre1 rename Second security-level private ip address 192.168.1.14 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 2.2.2.2 up crypto engine hardware crypto ike key first.test.com ns3 wFGX... fqdn first.test.com crypto ike key second.test.com ns3 l8e... fqdn second.test.com 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 first.test.com dpd-interval 20 identity-local fqdn local.test.com match-identity-remote fqdn first.test.com authentication-local pre-share authentication-remote pre-share mode transport policy tun-ikev2-policy ! crypto ipsec profile second.test.com dpd-interval 20 identity-local fqdn local.test.com match-identity-remote fqdn second.test.com authentication-local pre-share authentication-remote pre-share mode transport policy tun-ikev2-policy crypto ipsec mtu auto crypto map first-tunnel set-peer 1.1.1.1 set-profile first.test.com set-transform esp-aes128-sha1 match-address acl-first-gre nail-up virtual-ip no enable enable ! crypto map wombat-tunnel set-peer 2.2.2.2 set-profile second.test.com set-transform esp-aes128-sha1 match-address acl-second-gre nail-up virtual-ip no enable enable service ipsec Стартовали, все хорошо. Оба туннеля поднялись и ROUTED Заходим в CLI, хотим проверить linked key (config)> (config)> crypto ipsec profile second.test.com Core::Configurator: Done. (config-ipsec-profile)> preshared-key NEW_KEY Все. second-tunnel перпеподнялся с новой конфигурацией и с linked key first-runnel не дергался, но перестал быть ROUTED Quote Link to comment Share on other sites More sharing options...
Le ecureuil Posted May 11, 2017 Share Posted May 11, 2017 1 час назад, gaaronk сказал: Вот куски конфига access-list acl-first-gre permit gre 5.5.5.5 255.255.255.255 1.1.1.1 255.255.255.255 ! access-list acl-second-gre permit gre 5.5.5.5 255.255.255.255 2.2.2.2 255.255.255.255 interface Gre0 rename First security-level private ip address 192.168.1.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 1.1.1.1 up ! interface Gre1 rename Second security-level private ip address 192.168.1.14 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 2.2.2.2 up crypto engine hardware crypto ike key first.test.com ns3 wFGX... fqdn first.test.com crypto ike key second.test.com ns3 l8e... fqdn second.test.com 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 first.test.com dpd-interval 20 identity-local fqdn local.test.com match-identity-remote fqdn first.test.com authentication-local pre-share authentication-remote pre-share mode transport policy tun-ikev2-policy ! crypto ipsec profile second.test.com dpd-interval 20 identity-local fqdn local.test.com match-identity-remote fqdn second.test.com authentication-local pre-share authentication-remote pre-share mode transport policy tun-ikev2-policy crypto ipsec mtu auto crypto map first-tunnel set-peer 1.1.1.1 set-profile first.test.com set-transform esp-aes128-sha1 match-address acl-first-gre nail-up virtual-ip no enable enable ! crypto map wombat-tunnel set-peer 2.2.2.2 set-profile second.test.com set-transform esp-aes128-sha1 match-address acl-second-gre nail-up virtual-ip no enable enable service ipsec Стартовали, все хорошо. Оба туннеля поднялись и ROUTED Заходим в CLI, хотим проверить linked key (config)> (config)> crypto ipsec profile second.test.com Core::Configurator: Done. (config-ipsec-profile)> preshared-key NEW_KEY Все. second-tunnel перпеподнялся с новой конфигурацией и с linked key first-runnel не дергался, но перестал быть ROUTED Огромное спасибо за помощь в воспроизведении, все починено и появится во всех ближайших сборках. Quote Link to comment Share on other sites More sharing options...
ndm Posted May 12, 2017 Share Posted May 12, 2017 Исправлено в версии 2.09.A.7.0-3. 1 Quote Link to comment Share on other sites More sharing options...
gaaronk Posted May 17, 2017 Author Share Posted May 17, 2017 Костыль по настройке strongswan под себя усовершенствован Cоздаем дополнительный файлик с настройками strongswan - /opt/etc/strongswan_opt.conf Например charon { interfaces_ignore = "br0, br1, ngre0, ngre1, ezcfg0" make_before_break = yes } При старте системы копируем его куда надо и один раз (а не каждый раз при монтировании флешки с entware) дергаем демона # fix strongswan if [ ! -f "/tmp/ipsec/strongswan_opt.conf" ]; then cp /opt/etc/strongswan_opt.conf /tmp/ipsec/ /opt/usr/sbin/swan-fix.sh & fi swan-fix.sh конфиги не трогает, только рестартует сервис #!/bin/sh while true; do SPID=`pidof charon` if [ ! -z "$SPID" ]; then kill $SPID /opt/bin/logger -t "swan-fix" "Fix strongswan interfaces" exit 0 fi sleep 1 done В принципе этого не надо, обычно у меня скрипт при старте системы отрабатывает до старта strongswan. Но это так, на всякий случай. Зато если теперь сделать no service ipsec service ipsec То внесенные вами изменения в конфиг не пропадут. 1 Quote Link to comment Share on other sites More sharing options...
gaaronk Posted May 18, 2017 Author Share Posted May 18, 2017 Нда. Слона то я и не приметил =( charon.ignore_routing_tables "A space-separated list of routing tables to be excluded from route lookup." Надо было этот параметр задавать Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.