Вопросы Теги

openSwan VPN работает не может проверить связь с удаленной подсетью

Когда я запускаю команду ipsec auto status, я получаю следующий вывод: 

......           
172.16.255.1/32===104.131.13.155<104.131.13.155>:17/1701...41.203.65.124<41.203.    65.124>===10.100.108.51/32; erouted; eroute owner: #13
.......
000 #13: "globacom-vpn":500 STATE_QUICK_I2 (sent QI2, IPsec SA established);     EVENT_SA_REPLACE in 2243s; newest IPSEC; eroute owner; isakmp#10; idle; import:admin initiate
000 #13: "globacom-vpn" esp.e5adc724@41.203.65.124 esp.7b33a369@104.131.13.155 tun.0@41.203.65.124 tun.0@104.131.13.155 ref=0 refhim=4294901761
000 #10: "globacom-vpn":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 79407s; newest ISAKMP; lastdpd=10s(seq in:15699 out:0); idle; import:admin initiate
000

service ipsec status 

IPsec running  - pluto pid: 14150
pluto pid 14150
1 tunnels up
some eroutes exist

ip xfrm policy 

src 172.16.255.1/32 dst 10.100.108.51/32 proto udp sport 1701
    dir out priority 2080
    tmpl src 104.131.13.155 dst 41.203.65.124
            proto esp reqid 16405 mode tunnel
src 10.100.108.51/32 dst 172.16.255.1/32 proto udp dport 1701
    dir fwd priority 2080
    tmpl src 41.203.65.124 dst 104.131.13.155
            proto esp reqid 16405 mode tunnel
src 10.100.108.51/32 dst 172.16.255.1/32 proto udp dport 1701
    dir in priority 2080
    tmpl src 41.203.65.124 dst 104.131.13.155
            proto esp reqid 16405 mode tunnel
src ::/0 dst ::/0
    socket out priority 0
src ::/0 dst ::/0
    socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
    socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
    socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
    socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
    socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
    socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
    socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
    socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
    socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
    socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
    socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
    socket out priority 0

ping 10.100.108.51 

PING 10.100.108.51 (10.100.108.51) 56(84) bytes of data.
From 104.131.13.155 icmp_seq=1 Destination Host Unreachable
From 104.131.13.155 icmp_seq=2 Destination Host Unreachable
From 104.131.13.155 icmp_seq=3 Destination Host Unreachable

What я делаю что-то не так?

0
задан 10 February 2016 в 20:26
1 ответ

Наконец-то эта проблема исправлена.

Вот что я сделал:

  1. В файле ipsec.conf мне пришлось закомментировать левый протокол, который был установлен на 

     leftprotoport = 17  / 1701

    Это существенно ограничивает подключение vpn к L2TP с использованием порта UDP 1701. Проверка политики ip xfrm показывает, что для портов источника и получателя установлено значение 1701. Это означает, что я не мог отправлять трафик через TCP. Единственным разрешенным трафиком был UDP-порт 1701.

  2. Я заметил некоторые ошибки контрольной суммы udp, когда я запускал tcpdump на eth0. Очевидно, это было результатом настройки debian на использование аппаратной разгрузки контрольной суммы TCP / UDP. Следующие команды отключили его. 

     $ ethtool --offload eth0 rx off tx off
 $ ethtool -K eth0 gso выкл.

Теперь, когда я запускаю трассировку к удаленному хосту / сети, я вижу только один переход по сравнению с 11, когда была настроена неправильная политика ipsec. Я также вижу пакеты ESP (spi = 0XXXX, seq = xxxx) как часть вывода tcpdump на удаленный хост при отправке трафика в форме ping / telnet.

0
ответ дан 5 December 2019 в 10:42

Теги

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