+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

hAP ac lite, RouterOS v6.45.8, проблемы с VPN-клиентом

hAP ac lite, RouterOS v6.45.8, проблемы с VPN-клиентом, RouterOS

masterx1981

Guest

08.05.2020 10:47:00

Привет! Я настроил PPTP-подключение к Microsoft VPN-серверу, соединение работает, пинги проходят нормально (даже с длиной пакета 10 КБ, фрагментированным), но если я запускаю RDP-сессию или начинаю передавать файл, всё идёт очень медленно (при этом загрузка CPU микротика всего 1–2%), и 99% времени RDP либо вылетает, либо зависает. Если на том же ПК запустить VPN через софт, связь быстрая и стабильная. Я попробовал провести захват трафика Wireshark с ПК до микротика во время активности на VPN-сеть назначения и увидел много ретрансляций и таймаутов TCP, даже с маленькими пакетами (100 байт включая заголовок), то есть проблема в MTU, скорее всего, исключается. Так в чём может быть причина такой проблемы? Спасибо!

masterx1981

Guest

29.05.2020 10:47:00

Прослушивание пакетов ничего не дало. Я с трудом попытался переключиться с PPTP на L2TP, но проблема осталась та же — медленно жутко. Простой пинг с 1300 байт, отправленный через VPN-клиент MikroTik, занимает почти в два раза больше времени, чем через софтверный VPN. RDP-соединения нестабильны и так далее. Что дальше? Мне нужно заменить десятки устройств DD-WRT, и я рассчитывал использовать MikroTik, но с такими проблемами придется отказаться от этой затеи. Забавно, что с древним WRT54G и софтом DD-WRT, у которого вдвое меньше мощности, таких проблем у меня не было.

sindy

Guest

31.05.2020 12:32:00

Сниффинг — это не решение, это инструмент для анализа того, что происходит. Вы не предоставили результатов сниффинга, а лишь сделали вывод на основе неправильного предположения. Такая конфигурация, где Mikrotik выступает в роли PPTP-клиента, у других людей регулярно работает (в том числе у меня), так что, скорее всего, проблема связана с вашей конкретной настройкой, но вы даже не удосужились её выложить. Также вы не указали модель Mikrotik, не сообщили, исключали ли вы проблемы с кабелем и так далее.

masterx1981

Guest

03.06.2020 14:08:00

Очевидно, что анализ трафика («сниффинг») ничего не «решает», но и ничего аномального не показал. Модель роутера указана в названии поста: hAP ac lite. Сейчас я пробовал точно такую же конфигурацию на HAP ac2 RBD52G (таком более мощном устройстве) — результат тот же. Также пытался переключиться на L2TP — результаты всё так же плачевные.

Случай довольно специфический: связь на той стороне очень плохая, но если переключиться на Windows VPN, связь становится работоспособной, а через туннель Mikrotik — никак нельзя пользоваться. Кстати, на WRT54G с DD-WRT тоже работает достаточно нормально.

Вот конфигурация, сгенерированная через веб-интерфейс (обычно я работаю с Cisco OS, с синтаксисом Mikrotik пока не знаком):

Локальная сеть: 192.168.88.0/24
Удалённая сеть: 192.168.1.0/24

На другой стороне Windows Server OS с встроенным VPN-сервером. Оба устройства находятся за NAT (работают с NAT-T).

[admin@MikroTik] > /export hide
# jun/03/2020 15:58:04 by RouterOS 6.43.10
# software id = M5C7-470P
#
# model = RBD52G-5HacD2HnD
# serial number = A6470ADB3269

/interface bridge
add admin-mac=C4:AD:34:06:DB:1E auto-mac=no comment=defconf name=bridge

/interface ethernet
set [ find default-name=ether1 ] advertise=10M-half,10M-full,100M-half,100M-full mac-address=C4:AD:34:06:DB:1D name=Internet speed=100Mbps
set [ find default-name=ether2 ] advertise=10M-half,10M-full,100M-half,100M-full mac-address=C4:AD:34:06:DB:1E speed=100Mbps
set [ find default-name=ether3 ] advertise=10M-half,10M-full,100M-half,100M-full mac-address=C4:AD:34:06:DB:1F speed=100Mbps
set [ find default-name=ether4 ] advertise=10M-half,10M-full,100M-half,100M-full mac-address=C4:AD:34:06:DB:20 speed=100Mbps
set [ find default-name=ether5 ] advertise=10M-half,10M-full,100M-half,100M-full mac-address=C4:AD:34:06:DB:21 speed=100Mbps

/interface l2tp-client
add connect-to=xxx.xxx.xxx.xxx dial-on-demand=yes disabled=no keepalive-timeout=disabled max-mru=1460 max-mtu=1460 name=l2tp-out1 use-ipsec=yes user=noone

/interface wireless
set [ find default-name=wlan1 ] name=wlan3 ssid=MikroTik
set [ find default-name=wlan2 ] name=wlan4 ssid=MikroTik

/interface pptp-client
add allow=mschap1,mschap2 connect-to=xxx.xxx.xxx.xxx keepalive-timeout=30 mrru=1500 name=pptp-out1 user=noone

/interface ethernet switch port
set 0 default-vlan-id=0
set 1 default-vlan-id=0
set 2 default-vlan-id=0
set 3 default-vlan-id=0
set 4 default-vlan-id=0
set 5 default-vlan-id=0

/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN

/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
add authentication-types=wpa2-psk management-protection=allowed mode=dynamic-keys name=WiFi supplicant-identity=MikroTik

/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot

/ip ipsec peer profile
set [ find default=yes ] dh-group=modp1024 dpd-interval=disable-dpd enc-algorithm=aes-256,aes-128,3des

/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256,sha1 enc-algorithms=aes-256-cbc,aes-192-cbc,aes-128-cbc,3des pfs-group=none

/ip pool
add name=default-dhcp ranges=192.168.88.10-192.168.88.254

/ip dhcp-server
add address-pool=default-dhcp disabled=no interface=bridge name=defconf

/ppp profile
set *0 change-tcp-mss=default

/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=*1
add bridge=bridge comment=defconf interface=*2

/ip neighbor discovery-settings
set discover-interface-list=LAN

/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=Internet list=WAN

/ip address
add address=192.168.88.1/24 comment=defconf interface=bridge network=192.168.88.0

/ip dhcp-client
add comment=defconf dhcp-options=hostname,clientid disabled=no interface=Internet

/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1

/ip dns
set allow-remote-requests=yes servers=8.8.8.8,8.8.4.4

/ip dns static
add address=192.168.88.1 comment=defconf name=router.lan

/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=WAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

/ip firewall mangle
add action=mark-routing chain=prerouting new-routing-mark=VPN passthrough=yes src-address=192.168.88.0/24

/ip firewall nat
add action=masquerade chain=srcnat out-interface=l2tp-out1
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN

/ip route
add distance=1 dst-address=192.168.1.0/24 gateway=l2tp-out1 routing-mark=VPN

/ip traffic-flow
set cache-entries=16k

/system clock
set time-zone-name=Europe/Rome

/system leds
add interface=Internet leds="" type=interface-activity
add interface=ether2 leds="" type=interface-activity
add interface=ether3 leds="" type=interface-activity
add interface=ether4 leds="" type=interface-activity
add interface=ether5 leds="" type=interface-activity

/system logging
add topics=ipsec

/system ntp client
set enabled=yes primary-ntp=193.204.114.232 secondary-ntp=193.204.114.233

/system resource irq rps
set Internet disabled=no
set ether2 disabled=no
set ether3 disabled=no
set ether4 disabled=no
set ether5 disabled=no

/tool mac-server
set allowed-interface-list=LAN

/tool mac-server mac-winbox
set allowed-interface-list=LAN

/tool sniffer
set file-name=test filter-interface=Internet filter-ip-address=xxx.xxx.xxx.xxx/32

Есть какие идеи?

sindy

Guest

03.06.2020 15:32:00

Извиняюсь, пропустил это при написании. Да, большинство пакетов, относящихся к fasttracked-соединениям, обходят mangle-правила и другую обработку фаерволом. Так что соединения, инициированные клиентами из вашей сети 192.168.88.0/24, устанавливаются через VPN-туннель, но как только приходит ответ и пакеты попадают под fasttrack, большинство исходящих пакетов идут по умолчанию через маршрут основной таблицы, и поэтому они никогда не доходят до назначения. Соединения действительно работают, пусть и очень медленно, потому что примерно 1, 5 или 10 процентов пакетов fasttracked-соединений не fasttracked. Один из возможных способов выборочно исключить только VPN-трафик из fasttracking описан здесь. Всегда лучше сразу выкладывать конфигурацию. Вы не думали, что это может быть связано с правилами фаервола и/или политикой маршрутизации, поэтому даже не упомянули, что используете policy routing.

masterx1981

Guest

05.06.2020 11:04:00

Извиняюсь, что не выложил конфиг раньше, но он был довольно стандартный: я начал с дефолтных настроек и включил только нужное. Но если дело в действии fasttrack, почему тогда, когда я настраивал несколько серверов l2tp/pptp на Mikrotik, такой проблемы не возникало? Всегда использую L2TP, пробовал полностью отключить fasttrack (только для теста) — соединение стало стабильнее (меньше потерянных пингов, как и ожидалось), но производительность всё равно оставляет желать лучшего. Пинг с размером 65000 байт (на самом деле немного больше, так как Windows ping добавляет заголовок), то есть фрагментированный, на Mikrotik занимает около 900 мс, а с Windows VPN (всё тот же L2TP) — около 160 мс…

sindy

Guest

06.06.2020 15:02:00

Такая огромная разница — это странно. Сниффинг должен показать задержки на отдельных этапах обработки пакетов. Пакет ICMP echo request приходит через LAN-интерфейс в момент времени T1; VPN-транспортный пакет, который его несёт (IPsec-зашифрованный L2TP или GRE, если вы используете PPTP), отправляется в момент T2; VPN-транспортный пакет с ICMP echo response приходит в момент T3, а декапсулированный ICMP echo response — в момент T4. Это должно показать, откуда именно возникает задержка. Для анализа сниффа понадобится Wireshark, так как фильтр сниффинга должен быть достаточно широким (без ограничений по интерфейсу или протоколу, с несколькими IP-адресами), чтобы захватить и полезную нагрузку (ICMP request/response), и VPN-транспортные пакеты.

masterx1981

Guest

07.06.2020 10:08:00

Завтра попробую покопаться поглубже. Раньше уже использовал Wireshark как просмотрщик в предыдущих тестах. Довольно странно, что при использовании Mikrotik в роли сервера (применял их трижды) такой тормозняк не замечал. Только сейчас, когда он в роли клиента.

masterx1981

Guest

08.06.2020 09:43:00

И вот дамп:
70 2.906474 192.168.88.254 192.168.1.1 IPv4 1514 Фрагментированный IP-протокол (proto=ICMP 1, off=0, ID=d9f5) [Собран в #156]
...
155 2.911652 192.168.88.254 192.168.1.1 IPv4 1514 Фрагментированный IP-протокол (proto=ICMP 1, off=62160, ID=d9f5) [Собран в #156]
156 2.911740 192.168.88.254 192.168.1.1 ICMP 1402 Запрос Echo (ping) id=0x0002, seq=34347/11142, ttl=128 (ответ в 387)
157 2.911752 192.168.88.254 192.168.1.1 IPv4 1402 Фрагментированный IP-протокол (proto=ICMP 1, off=63640, ID=d9f5)
158 2.911908 192.168.1.34 192.168.1.1 IPv4 1410 Фрагментированный IP-протокол (proto=ICMP 1, off=0, ID=d9f5)
159 2.912378 192.168.254.12 xxx.xxx.xxx.xxx ESP 1502 ESP (SPI=0x5ce3432c)
...
225 2.925795 192.168.254.12 xxx.xxx.xxx.xxx ESP 1502 ESP (SPI=0x5ce3432c)
226 2.925841 192.168.1.34 192.168.1.1 IPv4 1410 Фрагментированный IP-протокол (proto=ICMP 1, off=46784, ID=d9f5)

240 3.066544 xxx.xxx.xxx.xxx 192.168.254.12 ESP 1502 ESP (SPI=0x087e06ba)
241 3.067061 192.168.1.1 192.168.1.34 IPv4 1410 Фрагментированный IP-протокол (proto=ICMP 1, off=0, ID=0c9b) [Собран в #339]
...
338 3.826649 xxx.xxx.xxx.xxx 192.168.254.12 ESP 462 ESP (SPI=0x087e06ba)
339 3.826947 192.168.1.1 192.168.1.34 ICMP 370 Ответ Echo (ping) id=0x0002, seq=34347/11142, ttl=127

340 3.827088 192.168.1.1 192.168.88.254 IPv4 1410 Фрагментированный IP-протокол (proto=ICMP 1, off=0, ID=0c9b) [Собран в #387]
...
386 3.828052 192.168.1.1 192.168.88.254 IPv4 1410 Фрагментированный IP-протокол (proto=ICMP 1, off=63296, ID=0c9b) [Собран в #387]
387 3.828064 192.168.1.1 192.168.88.254 ICMP 370 Ответ Echo (ping) id=0x0002, seq=34347/11142, ttl=126 (запрос в 156)

192.168.88.254 — это IP рабочего компьютера,
192.168.88.1 — IP шлюза,
192.168.1.1 — удалённый IP сервера,
192.168.1.34 — IP, который роутер получил от VPN-сервера,
192.168.254.12 — WAN IP Mikrotik,
xxx.xxx.xxx.xxx — публичный IP VPN-сервера.

Похоже, что отправка пакетов идёт довольно быстро, основная задержка — при приёме (~800 мс). Всё вроде нормально, просто офигенно медленно. Если включить VPN Windows, тот же ping (in -t) падает примерно с ~900 мс до ~160 мс (и то же происходит, если выключить софтверный VPN).

masterx1981

Guest

#10

08.06.2020 10:25:00

Ух ты, нашёл разницу! VPN на Windows (и ddwrt) был настроен с программным сжатием. Когда я отключил сжатие в клиенте Windows VPN, пинг по Windows VPN подскочил с ~160мс до ~900мс, как и у Mikrotik VPN. Есть ли в Mikrotik способ использовать сжатие mppc? Потому что канал на другой стороне реально медленный, и я предпочитаю немного дополнительной нагрузки на вычисления сжатия... Пытался включить флаг «Use Compression» в профиле, но пинг всё равно высокий...

masterx1981

Guest

#11

08.06.2020 14:57:00

Что касается mangle, я настроил его, добавив в правило fasttrack по умолчанию исключение для трафика с меткой маршрутизации «VPN» (! VPN). Та же метка «VPN» используется в маршруте от моей сети к удалённой сети на интерфейсе клиента l2tp. Затем я создал 2 mangle:

- Один отмечает маршрутизацию с локальной сети на IP-адреса удалённой сети с меткой «VPN» (используется маршрутом).
- Другой всегда маркирует трафик с интерфейса клиента l2tp с меткой «VPN» (в основном для исключения VPN-трафика из действия fasttrack).

Таким образом fasttrack не обрабатывает VPN-трафик. Соединение стабильное, всё работает как надо, но довольно медленнее из-за отсутствия сжатия. Если удастся настроить сжатие mppc — будет идеально.

sindy Guest	#12 0 08.06.2020 17:25:00 /ppp profile add copy-from=default-encryption use-compression=yes name=encryption-with-compression /interface l2tp-client set your-interface-name profile=encryption-with-compression Отключитесь, подключитесь заново, протестируйте.

masterx1981 Guest	#13 0 09.06.2020 07:57:00 Похоже, эта настройка сжатия никак не влияет… Даже если включить её в профиле, пинг всё равно постоянно около 900 мс.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры