Вопросы Теги

Соединенный туннель Strongswan vpn, но трафик не направляется через него

Я должен думать, что можно сделать это в единственной Wiki. Просто настройте права доступа так Уровень, 1 штат не может получить доступ к защищенному Tier 2 страницы. Это - все, что необходимо сделать, насколько я понимаю вопрос.

15
задан 24 May 2013 в 18:46
2 ответа

Вывод сеанса tcpdump на звездном флоте выявляет проблему. Из-за правила NAT здесь 

-A POSTROUTING -s 192.168.100.0/24 ! -d 192.168.100.0/24 -j MASQUERADE

запрос ICMP с адресом источника 192.168.100.100 привязан к xx.xx.xx.195 . Поскольку согласованная политика IPsec предназначена для трафика от 192.168.100.0/24 , а не xx.xx.xx.195 , эти пакеты не будут зашифрованы. Как видно на этой схеме потока пакетов через Netfilter , правила в цепочке POSTROUTING в таблице nat применяются до любых поисков преобразований IPsec ( xfrm lookup ).

Чтобы исправить это, выполните одно из следующего:

  • Явно исключите трафик в целевую подсеть из правил MASQUERADE (! -D 172.30.20.

  • Оставьте правила MASQUERADE такими, какие они есть, но вместо этого настройте leftsubnet = xx.xx.xx.195 / 32 (требует настройки конфигурации в блоке Cisco ASA и не помогает, если сайт-to -сайтовый туннель - на самом деле ваша цель)

10
ответ дан 2 December 2019 в 20:54

Моя ситуация очень похожа на описанную @telemaco. У меня есть несколько тестовых виртуальных машин, работающих на KVM на моем портативном компьютере. Мой ноутбук получает свой IP-адрес через DHCP, поэтому Strongswan назначает IP-адрес конечной точки VPN моему ноутбуку через leftsourceip =% config .

Виртуальные машины используют частную сеть 192.168.100.0/ 24 . Мой ноутбук (узел KVM) получает IP-адрес 192.168.50.2/24 через DHCP и IP-адрес конечной точки 10.0.0.10/26 от Strongswan.

Виртуальные машины должны получить доступ к сеть 192.168.0.0/24 , которая маршрутизируется через VPN.

Основываясь на ответе @ecdsa, я добился этого, добавив следующее правило: 

-t nat -I POSTROUTING -s 192.168.100.0/24 -d 192.168.0.0/24 -j SNAT --to-source 10.0.0.10

В моем случае ip xfrm policy выглядит так (выдержка): 

src 192.168.0.0/24 dst 10.0.0.10/32 
    dir fwd priority 2851 
    tmpl src xx.xx.xx.xx dst 192.168.50.2
        proto esp reqid 5 mode tunnel
src 192.168.0.0/24 dst 10.0.0.10/32 
    dir in priority 2851 
    tmpl src xx.xx.xx.xx dst 192.168.50.2
        proto esp reqid 5 mode tunnel
src 10.0.0.10/32 dst 192.168.0.0/24 
    dir out priority 2851 
    tmpl src 192.168.50.2 dst xx.xx.xx.xx
        proto esp reqid 5 mode tunnel

Это означает, что только локальный IP-адрес 10.0.0.10 имеет соответствующее правило xfrm lookup . Вот почему требуется NAT, если подсеть виртуальной машины не добавлена ​​в IPsec.

2
ответ дан 2 December 2019 в 20:54

Теги

Похожие вопросы