[5.1.4] VPN-сервер IKEv2/IPsec сломана маршрутизация в дополнительные сегменты. Фигурирует адрес ezcfg в трассировке.

[KeenTaur]

После обновления NDMS с 5.1.3 на 5.1.4 перестала работать маршрутизация в дополнительный сегмент с клиента, подключенного через VPN-сервер IKEv2/IPsec. Трассировка к адресам в дополнительном сегменте стала уходить через адрес ezcfg 198.51.100.11

NDMS 5.1.4

Устройство Keenetic Giga KN-1012

В основном сегменте адресация изменена на 10.4.3.0/24. Устройство (для проверки) в основном сегменте 10.4.3.220

В одном из дополнительных сегментов адресация 192.168.1.0/24. Устройство (компьютер) в дополнительном сегменте 192.168.1.125

Адресация VPN-сервера IKEv2/IPsec 172.20.4.0/24, прописан маршрут к дополнительному сегменту virtual-ip dhcp route 192.168.1.0 255.255.255.0

На клиенте Windows 10 в свойствах VPN-подключения отключено "Использовать основной шлюз в удаленной сети".

 

Пояснения к выводу команд под спойлером и логу/селфтесту (время +- минута)

08:36 роутер отправлен на перезагрузку; 08:38 роутер стал откликаться.

08:52 - 08:53 Выполняем подключение с удаленного клиента (Windows 10) к VPN-серверу IKEv2/IPsec на Кинетике.

08:53 - 08:55 Проверяем маршруты к сетям route print 10.4.3.* и 192.168.1.* - маршруты присутствуют, идут через 172.20.4.1.

Проверяем доступность роутера по его адресу в основном сегменте ping 10.4.3.1 - отклик есть. Проверяем доступность устройства в основном сегменте ping 10.4.3.220 - отклик есть.

Проверяем доступность роутера по его адресу в дополнительном сегменте ping 192.168.1.1 - "Превышен интервал ожидания для запроса." Проверяем доступность устройства в дополнительном сегменте ping 192.168.1.125 - "Превышен интервал ожидания для запроса."

Выполняем трассировку к устройству в дополнительном сегменте tracert -d 192.168.1.125 И вот тут, внимание!, по непонятной мне причине вместо привычных адресов, первым хопом всплывает 198.51.100.11 в недоумении ищем, "хтой-то?" и видим, что это адрес ezcfg.

На мой взгляд, это как-то неправильно. Из дополнительных вещей на этом роутере установлены AWGM, Antiscan (был отключен на время теста) и MagicTrickle (но он просто установлен и не запускается уже давно, убран из init.d, маршрутизация сейчас выполняется штатными средствами NDMS). Повторюсь 5.1.3 все работало, обновил до 5.1.4 - перестало.

08:56, не отключаясь от VPN, снимаю лог и селфтест. 

Спойлер

C:\WINDOWS\system32>route print 10.4.3.*
===========================================================================
Список интерфейсов
...
 73...........................XXXX-IKEv2
...
  1...........................Software Loopback Interface 1
===========================================================================

IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
         10.4.3.0    255.255.255.0         On-link        172.20.4.1     26
       10.4.3.255  255.255.255.255         On-link        172.20.4.1    281
===========================================================================
Постоянные маршруты:
  Отсутствует

IPv6 таблица маршрута
===========================================================================
Активные маршруты:
  Отсутствует
Постоянные маршруты:
  Отсутствует

C:\WINDOWS\system32>route print 192.168.1.*
===========================================================================
Список интерфейсов
...
 73...........................XXXX-IKEv2
...
  1...........................Software Loopback Interface 1
===========================================================================

IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
      192.168.1.0    255.255.255.0         On-link        172.20.4.1     26
    192.168.1.255  255.255.255.255         On-link        172.20.4.1    281
===========================================================================
Постоянные маршруты:
  Отсутствует

IPv6 таблица маршрута
===========================================================================
Активные маршруты:
  Отсутствует
Постоянные маршруты:
  Отсутствует

C:\WINDOWS\system32>ping 10.4.3.1
Обмен пакетами с 10.4.3.1 по с 32 байтами данных:
Ответ от 10.4.3.1: число байт=32 время=14мс TTL=64
Ответ от 10.4.3.1: число байт=32 время=14мс TTL=64
Ответ от 10.4.3.1: число байт=32 время=13мс TTL=64
Ответ от 10.4.3.1: число байт=32 время=14мс TTL=64

Статистика Ping для 10.4.3.1:
    Пакетов: отправлено = 4, получено = 4, потеряно = 0
    (0% потерь)
Приблизительное время приема-передачи в мс:
    Минимальное = 13мсек, Максимальное = 14 мсек, Среднее = 13 мсек

C:\WINDOWS\system32>ping 10.4.3.220
Обмен пакетами с 10.4.3.220 по с 32 байтами данных:
Ответ от 10.4.3.220: число байт=32 время=15мс TTL=254
Ответ от 10.4.3.220: число байт=32 время=14мс TTL=254
Ответ от 10.4.3.220: число байт=32 время=15мс TTL=254
Ответ от 10.4.3.220: число байт=32 время=14мс TTL=254

Статистика Ping для 10.4.3.220:
    Пакетов: отправлено = 4, получено = 4, потеряно = 0
    (0% потерь)
Приблизительное время приема-передачи в мс:
    Минимальное = 14мсек, Максимальное = 15 мсек, Среднее = 14 мсек

C:\WINDOWS\system32>ping 192.168.1.1
Обмен пакетами с 192.168.1.1 по с 32 байтами данных:
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.

Статистика Ping для 192.168.1.1:
    Пакетов: отправлено = 4, получено = 0, потеряно = 4
    (100% потерь)

C:\WINDOWS\system32>ping 192.168.1.125
Обмен пакетами с 192.168.1.125 по с 32 байтами данных:
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.
Превышен интервал ожидания для запроса.

Статистика Ping для 192.168.1.125:
    Пакетов: отправлено = 4, получено = 0, потеряно = 4
    (100% потерь)

C:\WINDOWS\system32>tracert -d 192.168.1.125
Трассировка маршрута к 192.168.1.125 с максимальным числом прыжков 30
  1    15 ms    13 ms    13 ms  198.51.100.11
  2     *        *        *     Превышен интервал ожидания для запроса.
  3     *        *        *     Превышен интервал ожидания для запроса.
  4     *        *        *     Превышен интервал ожидания для запроса.
  5     *        *        *     Превышен интервал ожидания для запроса.
  6  ^C
C:\WINDOWS\system32>

 

Изменено 28 августа пользователем KeenTaur

[NeTZeN]

Привет!
Можно выбрать канал обновления LTS и откатиться до 4.3.9 и все будет работать.

[Mamay]

9 часов назад, NeTZeN сказал:

Привет!
Можно выбрать канал обновления LTS и откатиться до 4.3.9 и все будет работать.

Это багрепорт, а не попытка найти решение!

[IvDriver]

Подтверждаю проблему, все то же самое, обновил Giga KN-1010 с 5.0.12 на 5.1.4, маршрутизация сломалась. Пришлось откатываться до LTS 4.3.9.

[Mamay]

Честно это какой-то ад. По сию пору сижу на 5.0.12 из-за двух вещей, сломанных в 5.1.x даже в stable - DNS и отлуп яблок. Никогда такого не было и вот опять!

[Leshiyart]

37 минут назад, Mamay сказал:

сломанных в 5.1.x даже в stable - DNS

это о чем речь?

[Mamay]

3 часа назад, Leshiyart сказал:

это о чем речь?

Сужу по многочисленным темам на данном форуме на эту тему.

[jerry]

Всех приветствую,  вчера обновился с 5.1.3 > 5.1.5 и встал на те же грабли((, удалось как то победить?

[KeenTaur]

5 часов назад, jerry сказал:

...вчера обновился с 5.1.3 > 5.1.5 и встал на те же грабли...

Если делали бэкап перед обновлением, можете откатиться на 5.1.3.

[JohnStotch]

Подтверждаю проблему на KeeneticOS 5.1.5.

После обновления перестал работать доступ с клиентов IKEv2/IPsec в дополнительный сегмент сети.

Конфигурация:

• Основной сегмент: 192.168.1.0/24
• дополнительный сегмент Work: 172.17.0.0/24
• пул IKEv2: 172.20.8.0/24
• клиент IKEv2 получает 172.20.8.2

До обновления с Mac по IKEv2 нормально подключался по RDP к ПК 172.17.0.16 в сегменте Work. 

Изменено 24 сентября пользователем JohnStotch

[jerry]

Сегодня прилетела 5.1.6. как не работало - так и не работает.

[KeenTaur]

Да, в 5.1.6 не исправлено.

[KeenTaur]

Коллеги, кто заинтересован в решении вопроса, попробуйте привлечь внимание к проблеме, нажав на стрелку "вверх" около заголовка темы. На скриншоте зеленым обведено. Ну и в официальную поддержку напишите, пожалуйста.

Спойлер

 

[KeenTaur]

Поддержка довольно быстро помогла решить проблему. Пишу со смартфона, если что, пардон за ошибки/опечатки.

Нужно создать ACL для каждого сегмента, куда нужен доступ через IKEv2-VPN-сервер, в котором разрешить прохождение от vpn-клиентов в сегмент. "Повесить" этот ACL на бридж-интерфейс соответствующего дополнительного сегмента в направлении выхода (out). Не забыть сохранить конфигурацию, если заработало. Как работало раньше, объявлено неправильным.

Применительно к описываемым в первом сообщении этой темы условиям, надо сделать так (поддержка писала по другому сегменту, адаптирую):

access-list VPN_Br2
permit ip 172.20.4.0 255.255.255.0 192.168.1.0 255.255.255.0
exit
interface Bridge2 ip access-group VPN_Br2 out
crypto map VirtualIPServerIKE2 virtual-ip dhcp route 192.168.1.0 255.255.255.0
system configuration save

 

Маршруты у меня уже передавались, ACL(ы) создал и привязал. Название ACL в своем примере сделал чуть понятнее, чем у поддержки, но корректность такого имени не проверял.

 

PS надо было сразу параллельно и в поддержку написать.

Изменено Понедельник в 08:58 пользователем KeenTaur
очепятки

[jerry]

Настроен VPN-сервер IKEv2/IPsec с диапазоном 172.16.1.0.
Есть vpn-подключение (SSTP), настроена маршрутизация через интерфейс SSTP до некоторых адресов и сетей назначения, так же добавил в межсетевой экран правило провайдера: разрешать Ipv4 с источника 172.16.1.0/24 до назначения 192.168.1.0/24.
Немного непонятно как создать бридж-интерфейс и сегмент и их связать?
 

Изменено Понедельник в 08:20 пользователем jerry

[KeenTaur]

57 минут назад, jerry сказал:

Немного непонятно как создать бридж-интерфейс и сегмент и их связать?

IKEv2, SSTP.  Подождите, давайте по очереди.

Когда вы создаете дополнительный сегмент (по крайней мере, через веб-интерфейс), соответствующий BridgeX создается автоматически. По умолчанию, Домашняя сеть это Bridge0; Гости - Bridge1; первый дополнительный сегмент - Bridge2; второй дополнительный сегмент - Bridge3. Увидеть имя Bridge-интерфейса вы можете в адресной строке в веб-интерфейсе, когда перейдете в "Мои сети и WiFi" - Сегменты и выделите интересующий вас сегмент. См. скриншот под спойлером:

Спойлер

 

Изменено Понедельник в 09:00 пользователем KeenTaur

[jerry]

Все верно, всего два сегмента: Домашняя сеть это Bridge0; Гости - Bridge1, используется только домашняя сеть. 

Попробовал создать новый сегмент, Bridge2

командами:

access-list SSTP0
permit ip 172.16.1.0 255.255.255.0 192.168.1.0 255.255.255.0
exit
interface Bridge2 ip access-group SSTP0 out
crypto map VirtualIPServerIKE2 virtual-ip dhcp route 192.168.1.0 255.255.255.0

все добавил - но не работает, что не так делаю или мысль я неправильно уловил?

 

 

[KeenTaur]

14 минут назад, jerry сказал:

Все верно, всего два сегмента: Домашняя сеть это Bridge0; Гости - Bridge1, используется только домашняя сеть. 

По-моему, вы смешиваете IKEv2-VPN-сервер и SSTP-VPN-сервер. Вам все-таки через VPN (какой vpn: ikev2 или sstp) нужен доступ в какой сегмент?

Если через SSTP и только в Домашний, то с проблемой из этой темы вы и не столкнетесь.

Инструкция по VPN-серверу SSTP Как я понимаю вас, на текущий момент (доступ через SSTP-VPN-сервер к домашней сети) следуя этой статье у вас должно все получиться.

Если вы планируете все-таки создать дополнительный сегмент и также получить туда доступ через SSTP (одновременно, и в Домашнюю сеть, и в дополнительный сегмент), то команда для передачи маршрута будет иметь другой вид. В статье "Автоматическая отправка дополнительных маршрутов клиентам VPN-сервера" указаны разные ситуации:

Цитата

Для сервера SSTP VPN, команда имеет формат sstp-server dhcp route ‹address› ‹mask›. Например:

sstp-server dhcp route 192.168.10.0/24
system configuration save

А вот дальше, возможно, вы столкнетесь с аналогичной ситуацией. Работу через SSTP с несколькими сегментами я не проверял, вероятно, нужно будет действовать так же, т.е. создавать дополнительные правила маршрутизации и фаервола.

[jerry]

На кинетике настроен IKEv2-VPN-сервер, так же кинетик подключается в другое место и является клиентом SSTP. (настроена маршрузитация, которая направляет на определенные ip в сеть SSTP)

И хотелось бы подключаться к кинетику из другого места (IKEv2) и получать доступ сеть SSTP. ...

   Как бы до обновления все работало отлично.

Изменено Понедельник в 11:40 пользователем jerry

[KeenTaur]

@jerry

Вот теперь более понятна ваша схема. Дополнительный сегмент вам делать не надо. А вот какие правила для маршрутизации и для фаервола создать, лучше спросить поддержку, отослав им self-test. Так быстрее будет (у меня получилось утром вопрос, к вечеру - ответ).

[jerry]

... понятно, спасибо, попробую...