Jump to content

Recommended Posts

Прошивка 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

Link to comment
Share on other sites

Так. Бага интересная.

Есть отдельная таблица маршрутизации (номер 200) где прописан дефолт в сторону ngre2 интерфейса.

В основной таблице дефолт в сторону ppp0 интерфейса.

 В ip rule правил для этой таблицы нет. Strongswan все равно использует ее для вычисления source address для route trap.  Если ее очистить то все становится хорошо. 

При этом на "большом" линуксе есть и аналогичная таблица с отдельным дефолтом, есть и правила ссылающиеся на нее, но Strongswan так странно себя не ведет.

 

Link to comment
Share on other sites

Пока подпер костылем

/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 потом сам появится, через динамику.

Link to comment
Share on other sites

Плохой, негодный костыль. К тому же валится в сегфолт, видимо из-за использования  /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

 

Так и живем

  • Thanks 1
Link to comment
Share on other sites

8 минут назад, gaaronk сказал:

Так и живем

Небольшой оффтоп, но... Понятно, что речь о фиксах прошивочного strongswan, но вы же вроде уже пользовались лебедем из Entware - чем он вас не устраивает с точки зрения работы в транспортном режиме, какого взаимодействия не хватает?

Интересуюсь потому, что мне надоело ждать сертификаты, хочется поэкспериментировать с настройками, и поэтому я сейчас медленно перехожу на strongswan из Entware. Больше всего боялся, что аппаратное шифрование не взлетит, или придется устраивать много костылей - как оказалось, напрасно боялся, по крайней мере в простом виде с одним туннелем оно взлетело само.

Link to comment
Share on other sites

Я пользуюсь прошивочным лебедем на кинетике и на асусе с падаваном (собирал сам). Можно и из entware поставить, но он живет на флешке, а рутера от меня в 1200 км и 800 км. Если флешка умрет, то худо бедно, пусть с задержкой но туннели поднимутся. Можно будет попросить воткнуть другую флешку и все настроить заново.

Link to comment
Share on other sites

20 minutes ago, KorDen said:

Небольшой оффтоп, но... Понятно, что речь о фиксах прошивочного strongswan, но вы же вроде уже пользовались лебедем из Entware - чем он вас не устраивает с точки зрения работы в транспортном режиме, какого взаимодействия не хватает?

Интересуюсь потому, что мне надоело ждать сертификаты, хочется поэкспериментировать с настройками, и поэтому я сейчас медленно перехожу на strongswan из Entware. Больше всего боялся, что аппаратное шифрование не взлетит, или придется устраивать много костылей - как оказалось, напрасно боялся, по крайней мере в простом виде с одним туннелем оно взлетело само.

 

А дома у меня рутер это стоковый дебиан в виртуалке на сервере виртуальных машин. Там бэкпортированный мной сван 5.5.2, там уже все - и сертификаты, и туннели, и remote access и L2TP и Cisco IKEv1 и IKEv2, и так и сяк и с радиусом сбоку для EAP.

Link to comment
Share on other sites

Насчет lifebytes - пока наверное никак, это сделано для обхода sweet32. Тем более у вас rekey нормально должен отработать, волноваться смысла мало.

Насчет interfaces_ignore - тема поднята интересная, как минимум невалидные интерфейсы вроде ezcfg0 туда внесем однозначно, а вот с командой для ручного задания нужно подумать.
Суть в том, что ручной туннельный режим практически никто не проверял, поскольку у него было изсчезающе мало применений было до появления Gre/EoIP/IPIP.

 

Link to comment
Share on other sites

Ну ручной ipsec в транспортном режиме я оттестировал очень плотно. Все работает на ура. Кроме бага с linked key for crypto map о котором я писал и вот этого с таблицами маршрутизации.

В отдельной таблице у меня дефолт и правилами ip rule на эту таблицу у меня заворачивается "интересный" трафик.  

А команда для ручного режима желательна конечно. Ну или буду использовать свой мегакостыль на старте.

lifebytes  да, абсолютно не мешает, это просто "для красоты", но раз оно надо то и хорошо.

Link to comment
Share on other sites

1 минуту назад, gaaronk сказал:

Ну ручной ipsec в транспортном режиме я оттестировал очень плотно. Все работает на ура. Кроме бага с linked key for crypto map о котором я писал и вот этого с таблицами маршрутизации.

В отдельной таблице у меня дефолт и правилами ip rule на эту таблицу у меня заворачивается "интересный" трафик.  

А команда для ручного режима желательна конечно. Ну или буду использовать свой мегакостыль на старте.

lifebytes  да, абсолютно не мешает, это просто "для красоты", но раз оно надо то и хорошо.

linked key for crypto map был практически сразу же починен.

Link to comment
Share on other sites

А вот и косвенная бага.

 

У меня два туннеля. оба траспорт, оба без 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 by gaaronk
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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

 

Огромное спасибо за помощь в воспроизведении, все починено и появится во всех ближайших сборках.

Link to comment
Share on other sites

Костыль по настройке 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

То внесенные вами изменения в конфиг не пропадут.

  • Thanks 1
Link to comment
Share on other sites

Нда. Слона то я и не приметил =(

charon.ignore_routing_tables 

"A space-separated list of routing tables to be excluded from route lookup."

 

Надо было этот параметр задавать

 
Link to comment
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
Reply to this topic...

×   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...