Jump to content
Калькуляторы

SSTP поверх L2TP Высокий пинг при пакетах больше 1500 байт

Здравствуйте, есть схема (во вложении). К центральному узлу подключается офис через Beeline (l2tp 1460MTU / 1464 MRU + IP FIREWALL MANGLE FWD change TCP MSS) с использованием SSTP VPN (1500 MTU/MRU).

 

На Core наблюдаю картину:

 

[admin@Core] > ping 10.254.248.15 size=1500
HOST                                     SIZE TTL TIME  STATUS                         
10.254.248.15                            1500  64 155ms
10.254.248.15                            1500  64 156ms
10.254.248.15                            1500  64 172ms
10.254.248.15                            1500  64 151ms
   sent=4 received=4 packet-loss=0% min-rtt=151ms avg-rtt=158ms max-rtt=172ms 

[admin@Core] > ping 10.254.248.15 size=1501
HOST                                     SIZE TTL TIME  STATUS                         
10.254.248.15                            1501  64 456ms
10.254.248.15                            1501  64 328ms
10.254.248.15                            1501  64 325ms
10.254.248.15                            1501  64 447ms
10.254.248.15                            1501  64 476ms
   sent=5 received=5 packet-loss=0% min-rtt=325ms avg-rtt=406ms max-rtt=476ms 

 

В три раза пинг вырастает, может быть кто сталкивался с подобной проблемой?

 

Делал с обеих сторон правила /ip firewall mangle action change TCP MSS до 1460 в диапазоне 1390-65534 - пакетов нет, пока "не въеду" чего им надо.

 

Конфиги Core Router:

 

 

 

[admin@Core] > interface sstp-server export 
/interface sstp-server server
set authentication=mschap1,mschap2 certificate=stb-bisv default-profile=default enabled=yes keepalive-timeout=60 max-mru=1500 max-mtu=1500 mrru=disabled port=443 \
   verify-client-certificate=no

[admin@Core] > ppp secret export 
/ppp secret
add caller-id="" comment=Office disabled=no limit-bytes-in=0 limit-bytes-out=0 local-address=\
   10.254.248.3 name=Office password=SuperPupperSecret profile=default-encryption remote-address=\
   10.254.248.15 routes="" service=any
[admin@Core] > ppp profile export 
/ppp profile
set 3 change-tcp-mss=yes name=default-encryption only-one=default use-compression=default \
   use-encryption=yes use-mpls=default use-vj-compression=default

 

 

 

Конфиги Office Router:

 

 

 

[admin@Office] > interface sstp-client export 
/interface sstp-client
add add-default-route=no authentication=pap,chap,mschap1,mschap2 certificate=cert1 connect-to=\
   <Core IP>:443 dial-on-demand=no disabled=no http-proxy=0.0.0.0:443 keepalive-timeout=60 \
   max-mru=1500 max-mtu=1500 mrru=disabled name=Core password=SuperPupperSecret profile=\
   default-encryption user=Office verify-server-address-from-certificate=yes \
   verify-server-certificate=no

[admin@Office] > interface l2tp-client export 
/interface l2tp-client
add add-default-route=no allow=pap,chap,mschap1,mschap2 connect-to=<Beeline VPN Server IP> dial-on-demand=\
   no disabled=no max-mru=1460 max-mtu=1460 mrru=disabled name=vpn-beeline password=\
   MegaSecret profile=default-encryption user=BeelineUsername

[admin@Office] > ip firewall mangle export 
/ip firewall mangle
add action=change-mss chain=forward disabled=no in-interface=vpn-beeline new-mss=1420 passthrough=\
   yes protocol=tcp tcp-flags=syn tcp-mss=1391-65535
add action=change-mss chain=forward disabled=no new-mss=1420 out-interface=vpn-beeline \
   passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=1391-65535

 

post-87545-048748800 1387301890_thumb.png

Share this post


Link to post
Share on other sites

TCP MSS не распространяется на icmp.

Эти ваши l2tp и sstp подтверждения доставки поди шлют, потому и задержки дикие.

И не в три а в два раза. Чтобы в три не было нужно быть проще в конфигах.

Share this post


Link to post
Share on other sites

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

 

Попробуйте запустить пинг в туннеле SSTP с размером MTU, который через билайн проходит, увидите задержку еще меньше. А правила Change TCP MSS вообще лишние тут, пакеты сами фрагментируются как нужно.

Share this post


Link to post
Share on other sites
А правила Change TCP MSS вообще лишние тут, пакеты сами фрагментируются как нужно.

Без этого правила пакеты будет фрагментировать тик, и заполняемость последнего фрагмента будет скорее всего далека от полной.

Share this post


Link to post
Share on other sites
А правила Change TCP MSS вообще лишние тут, пакеты сами фрагментируются как нужно.

Без этого правила пакеты будет фрагментировать тик, и заполняемость последнего фрагмента будет скорее всего далека от полной.

 

Они так и так будут фрагментироваться, ведь MTU первого туннеля 1460. Следовательно пакеты меньшего размера пройдут без проблем, а большего пойдут с довеском. Если поверх пустить еще туннель, то его MTU в канале нужно уменьшить, что бы фрагментацией не занимался первый туннель, а сам роутер, тогда уже он будет пакеты фрагментировать по MTU последнего туннеля.

Share this post


Link to post
Share on other sites

Не будут они ферментироваться на хренотике для TCP если правильно заюзать MSS fix - сразу будут маленькими прилетать.

Share this post


Link to post
Share on other sites

Не будут они ферментироваться на хренотике для TCP если правильно заюзать MSS fix - сразу будут маленькими прилетать.

 

Попробуйте.

Share this post


Link to post
Share on other sites

Вы это кому то другому пишите :)

Я во время реализации IP стёка + арп в нетграф ноде эту самую фрагментацию руками к себе перетягивал из исходников ос, а дефрагментацию уже не осилил и скопипастил почти без изменений.

И как и куда mss выставляется я тоже прекрасно знаю, и как потом по быстрому контрольная сумма пересчитывается.

Посему свои теории проверяйте сами, в нормальных лабах/стенда а не на тике, а я правильный ответ знаю.

Share this post


Link to post
Share on other sites

Вы это кому то другому пишите :)

Я во время реализации IP стёка + арп в нетграф ноде эту самую фрагментацию руками к себе перетягивал из исходников ос, а дефрагментацию уже не осилил и скопипастил почти без изменений.

И как и куда mss выставляется я тоже прекрасно знаю, и как потом по быстрому контрольная сумма пересчитывается.

Посему свои теории проверяйте сами, в нормальных лабах/стенда а не на тике, а я правильный ответ знаю.

 

Зачем мне стенды и лабы, когда можно запустить тест с микротика на микротик, и получить через 2 туннеля полную утилизацию 100 мегабитного канала?

Share this post


Link to post
Share on other sites

И получить картину мира глазами мыкротика. И с tcpdump не сильно на тырке разойдёшься.

Share this post


Link to post
Share on other sites

И получить картину мира глазами мыкротика. И с tcpdump не сильно на тырке разойдёшься.

 

Ну так если я беру IP и получаю 97/97, далее беру первый туннель, уменьшаю MTU так, что бы пакеты не фрагментировались, и получаю те же 97/97, потом создаю второй туннель и аналогично уменьшив MTU запускаю тест, получаю опять 97/97. Должно быть как-то иначе? Естественно если запускать тест пакетами 1500 байт, то каждый туннель уменьшит скорость примерно на 10 процентов.

Share this post


Link to post
Share on other sites

Перевел на PPTP, проблема ушла.

На SSTP менял MTU - толку нет.

Edited by a-zazell

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this