Я обновил FreeBSD коробка из 10.4 к 11.2-RELEASE-p4 недавно и, кажется, сломал vpnc Подключение к VPN.
Вот vpnc.conf:
IPSec gateway 10.1.0.1
IPSec ID vpnuser
IPSec secret su0hoh8liNgeiT8
Xauth username vpnuser
Xauth password miuthei3Niew2ee
Nat Traversal Mode none
NoninteractiveПосле настройки интерфейса; em0 - это аппаратный интерфейс с частным IP-адресом, tun0 - интерфейс vpnc с общедоступным адресом.
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC>
inet 10.2.2.1 netmask 0xfffffe00 broadcast 10.2.3.255
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet 127.0.0.1 netmask 0xff000000
nd6 options=21
groups: lo
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1412
options=80000<LINKSTATE>
inet x.11.11.60 --> x.11.11.60 netmask 0xffffffff
nd6 options=29
groups: tun
Opened by PID 90343
Пока что выяснил:
vpnc, по-видимому, может установить соединение VPN, запустив vpnc с --no-detach не показывает критических ошибок. Я использую ту же конфигурацию, что и раньше, с предыдущим FreeBSD версия, где он работал безупречно. Я также пробовал несколько версий vpnc-scripts. Я также тестировал его с помощью правил брандмауэра pf, очищенных с помощью pfctl -F all.
пинги, отправленные с локальной машины (ping 8.8.8.8) показывать в tcpdump -ni tun0 как исходящий трафик:
00:58:24.017976 IP x.11.11.60 > 8.8.8.8: ICMP echo request, id 42593, seq 4, length 64
пинги, отправленные с локального компьютера, отображаются в tcpdump -ni em0; Интересно то, что пакет VPN, кажется, каждый раз получает правильный ответ, и ответ достигает аппаратного интерфейса локальной машины:
00:58:24.018029 IP 10.2.2.1 > 10.1.0.1: ESP(spi=0x1bcc60be,seq=0x3c), length 132
00:58:24.078558 IP 10.1.0.1 > 10.2.2.1: ESP(spi=0xe48f7620,seq=0x6b), length 132
однако возвращаемый пакет не отображается в tcpdump.
пакеты ping от случайного внешнего (интернет) хоста к x.11.11.60 действительно вызывают аналогичный трафик, который можно увидеть на em0 но не на tun0:
01:35:32.612015 IP 10.1.0.1 > 10.2.2.1: ESP(spi=0xe48f7620,seq=0x124), length 132
Изменение sysctl значение net.inet.ip.forwarding похоже, не имеет никакого эффекта.
VPN (tun0) должен быть маршрутом выхода хоста по умолчанию. На основании вывода о том, что в примере ping возвращается ответ до em0 похоже, это не проблема маршрутизации.
Вы можете заметить что-то, что мне не хватает? Есть идеи, как я могу снова заставить VPN-соединение работать?
ОБНОВЛЕНИЕ - Новые результаты:
Теперь кажется вероятным, что это не vpnc конкретная проблема. Скорее может быть что-то с обработкой ESP на FreeBSD 11.
--natt-mode force-natt несмотря на то, что между хостами нет NAT. Почему-то нет проблем с инкапсулированным UDP:Что показывает на em0...
14:15:18.500251 IP 10.2.2.1.4500 > 10.1.0.1.4500: UDP-encap: ESP(spi=0x66842bb7,seq=0x3), length 132
14:15:18.527137 IP 10.1.0.1.4500 > 10.2.2.1.4500: UDP-encap: ESP(spi=0x3a4661f0,seq=0x3), length 132
... теперь можно увидеть в незашифрованном виде также на tun0:
14:15:18.500200 IP x.11.11.60 > 172.217.21.142: ICMP echo request, id 64016, seq 2, length 64
14:15:18.527188 IP 172.217.21.142 > x.11.11.60: ICMP echo reply, id 64016, seq 2, length 64
Я создал отдельное решение с racoon с помощью Руководство FreeBSD и он показал аналогичное поведение, когда дело дошло до очевидного отказа от обработки входящих пакетов ESP. По какой-то причине теперь появляется ошибка vpnc[3372]: esp sendto: Invalid argument когда я пытаюсь пинговать, если vpnc был начат с --natt-mode none.
Похоже, в IPsec, ESP и NAT-T произошли некоторые изменения. FreeBSD 11.0R и 11.1R. Может быть, эти изменения сейчас чему-то мешают.
Любая помощь по-прежнему приветствуется.