База знаний

www. IT-Mehanika .ru --  журнал доброго админа

Mikrotik: SSTP vs PPTP или маленькие шалости больших корпораций

Проблема возникла нежданно:  туннель между Микротиками у меня дома и у родителей упал. А туннель мне жизненно необходим, т. к. у родителей стоят камеры, которые мне постоянно нужно мониторить, мама в возрасте, плохо слышит...понимаете.
IP-шник у родительского Mikrotik хоть и был динамический, но ни разу не поменялся за 2 года, к тому же он был белый.
Теперь же провайдер переделал свою сеть таким образом, что внешний IP стал серым и намертво запрятанным то-ли за НАТ, то-ли я уже не знаю, что они там намутили...

Окончательно понять их хитроумную задумку мне так и не удалось, буду рад, если кто-нибудь из читателей прольет свет на эту темную историю.
Итак, я обнаружил, что канал упал и вставать не желает. Ну, думаю, ладно, какая беда, был у меня просто IPSec, теперь натяну L2TP+IPSec.


Но не тут-то было, эта связка не желала запускаться никак. Перечитал все мануалы, которые есть — безрезультатно. Обратился по дружбе к своим гуру по тикам, но никто ничего предложить не смог.
Пробовал все, что хоть как-то подходило под мою схему с одним серым IP, чтобы получить желанный туннель на IPSec, нашел описание похожей схемы, только не 2 тика, а между тиком и циской, но у меня это не заработало. К тому же, странно, но где-то я слышал, что каналы IPIP работают только на белых адресах.
Продолжалось это безобразие до тех пор, пока мой друг не избавил меня от мучений и насильно сделал PPTP, который, как вы понимаете, успешно поднялся без всяких проблем.
Но мы же не ищем легких путей....к тому же меня напрягал тот факт, что PPTP сама офтопик признает небезопасным.
В общем, перепробовав все возможные варианты настроек и попыток с IPIP+IPSec, L2tp+IPSec, у меня остались всего два работающих варианта: PPTP и SSTP, благо этот протокол в Mikrotik есть.
SSTP поднялся без трудностей и я решил проверить скорость канала.
Первое открытие я сделал для себя (не претендую на новость, но раньше не сталкивался), что TeamViewer, который на время настроек остался единственным способом подключения к родительскому роутеру, без зазрения совести режет скорость на уровне 120 килобайт/сек.

После этого я стал использовать UltraVNC. Правда и с ним тоже открылась интересная особенность: если минимизировать окошко передачи файлов, скорость резко падает (sic!).

Настройки SSTP сервера (Mikrotik RB2011UAS-2HnD):

На сервере включил AES-256, TCP MSS менять не стал, т. к. его значение все равно не меняется

В профиле сервера пробовал все возможные комбинации — с компрессией и без нее, разницы никакой вообще.



В надежде увидеть что-нибудь сакральное, был включен лог sstp, который ничего не дал  — там все ровно.


Это профиль клиента (Mikrotik RB951G-2HnD), все по дефолту, он все равно зависит от профиля на сервере:

Значение MTU такое же, как на сервере.


Ну и наконец момент истины: сначала SSTP.


Очень грустный пинг:

Обратите внимание на загрузку процессора — она не ниже, чем при PPTP!
Хорошо видно, насколько неровно идет загрузка, скорость то прыгает вверх, то резко падает:


Непонятные ретрансмиты:


И наконец финальная средняя скорость передачи большого файла (430 МБ):


Теперь переходим к PPTP:



Средняя скорость передачи составила:


Да, забыл сказать, что канал у родителей 14 Мбит, так что PPTP практически использовал всю доступную ширину канала.
Итак, выводы очевидны: так широко рекламируемый компанией Microsoft её протокол SSTP, не более, чем попытка выдать очередную недоподелку за великое открытие.
Возможно, мои наблюдения однобоки, т. к. рассматривают только реализацию sstp на Mikrotik, может быть на винде все по другому? Было бы интересно, если бы кто-то это проверил.
У sstp есть определенные выигрышные моменты

  1. он прекрасно «пролезает» по 443 порту, определяясь (если не копать по сигнатуре), как обычный трафик HTTPS, таким образом нет необходимости открывать дополнительные порты
  2. соединение устанавливается очень быстро, несмотря на проверку сертификатов с обеих сторон.
  3. Хорошо защищен...если забыть, что это проприетарный протокол с возможным бэкдором

НО СКОРОСТЬ????!!!!??? Это уничтожает любые достоинства.
На этом можно было бы поставить точку, но мое любопытство и встроенная подозрительность к поделиям от офтопика сыграли свою роль.
Меня не отпускала мысль — почему же скорость настолько низкая?!? Ведь скорость передачи по sstp оказалась в 3 раза ниже, чем по pptp!

то-то меня торкнуло и я решил заглянуть в соединения при поднятом sstp. Моему изумлению не было предела — в соединениях висел коннект с... адресом Microsoft!...
Также там висели парочка коннектов с моим провайдером...непонятно, зачем?...

Ну, дело - пара пустяков, решил я, и начал прибивать эти соединения. С провайдером я с ходу разделаться не смог, т. к. соединения отваливались и появлялись снова.
Но вот когда я убил соединение с Microsoft, winbox....упал! Запускаю снова — канал есть, коннект к офтопику есть, прибиваю коннект — падает winbox. Интересная особенность, не правда ли?
Соорудив пару правил файрвола, не позволяющих устанавливать соединения по 443 порту никому, кроме себя, запустил канал снова.

«Вы будете смеяться», как говорят в Одессе, но канал установился, как ни в чем ни бывало, и скорость поднялась на 200 Кб/сек, т. е. около 2МБит сжирали по(ту)сторонние соединения!
Неплохо, да?
Посмотрев повнимательнее, замечаю еще интересные соединения, одно не заскриншотил, а второе попало мне в коллекцию:

Второй коннект был по адресу 137.170.185.211
192.168.5.21 — это адрес моей IP-камеры, которая наружу вообще ни разу не проброшена.
Мне стало очень любопытно, что же это за сайты, которых интересует моя камера?

Встречаем героев:
1 адрес: 173.230.150.191
NetRange:       173.230.128.0 - 173.230.159.255
CIDR:           173.230.128.0/19
OriginAS:      
NetName:        LINODE-US
OrgName:        Linode

http://en.wikipedia.org/wiki/Linode

Частная компания, основанная в 2003 г. неким Christopher Aker.
Облачный хостинг для разработчиков, облачные бэкапы и др.

2 адрес: 137.170.185.211
NetRange:       137.170.0.0 - 137.170.255.255
CIDR:           137.170.0.0/16
OriginAS:      
NetName:        FNOK
OrgName:        Freudenberg-NOK General Parternership

https://www.google.com/finance?cid=14747868
Freudenberg-NOK, the Americas joint venture of Freudenberg & Co. (Germany) and NOK Corporation (Japan), makes elastomeric sealing products, lubricants, and custom molded products used primarily in the automotive industry.
Founded in 1989, Freudenberg-NOK has operations in the US, Canada, Brazil, Malaysia, and Mexico.

Трудно представить себе, для какой цели моя IP камера производства FOSCAM лезет на сайты этих больших корпораций...остается только вспомнить  “теорию заговора”...
Но как ни крути, а других реальных объяснений я не вижу. Получается, что ВСЕ большие корпорации в США и других зависящих от них странах если не работают на правительство США и их спецслужбы, то, по крайней мере, находятся под их контролем.
Сюда же входят и все производители сетевой аппаратуры, производящей шифрование данных - CISCO, Juniper, HP и т. п.
Похоже, ребята из ANB/FBR/NSA...подставьте_нужное и Mikrotik тоже “пригнули” с этим протоколом.
Интересный вопрос, а только ли с этим протоколом???... ;)

Есть возражения, дополнения?
Оппонируйте, пожалуйста :)

Вот такие интересные наблюдения за маленькими шалостями больших корпораций :)







 

Комментарии   

0 #12 Руслан 20.04.2017 17:06
У меня все было банально!
Раньше я блокировал внешние запросы к ДНС, но после обновления прошивки, видимо эта настройка снова стала по дефолту, что следствие, загрузка проца и канала, на pptp ресурсов не хватало. Убрал галочку Allow Remote Request в IP->DNS и потом проверил скорость через Bandwidth test. Все полетело!)
+1 #11 Alexey 01.12.2016 17:01
Цитирую Иван:
Вот оно чё Михалыч.
У меня микротик как sstp сервер и виндовые клиенты(2 шт), и тоже скорость как то не по каналу :-)

Микротик с аппаратной поддержкой шифрования или с софтовой?
У меня на 951ом скорость примерно аналогичная на IPSec - но тут дело точно в шифровании.
у ТС же стоит принудительный AES.
0 #10 Alexey 01.12.2016 16:59
Цитирую mrbublik:
Цитирую Константин:
Причина внедрения NAT у операторов связи - закончились адреса IPv4. Решение только одно - IPv6. Спрашивайте у операторов связи! :)

version6.ru

Я думаю там будут свои подводные камни. Если каждой станции по реальному ИП... это же голову сломаешь на безопасности ))))

Так, те же правила на формардинг.
Исходящие все, входящие только естаблишед и релатед. Вопрос решен.
0 #9 Alexey 01.12.2016 16:58
Цитирую Paul:
Пинги действительно странные, ничего подобного не было. Коннект с майкрософтовским сервером действительно наблюдается, только он у меня отваливается через несколько секунд после коннекта клиента.
Скорость у sstp на микротиках (на ПО, актуальном данный момент, по крайней мере) действительно низковата. Игры с MTU и MRU ни к чему не привели. Максимальная скорость передачи большого файла, которой мне удалось добиться (100 Мбит каналы с обеих сторон) - около 3 Мбайт/с. При этом процессор разогнанного hex был загружен на 100%. Изучение форумов укрепило в уверенности, что проблемы со скоростью микротиковского sstp - проблемы не только моих кривых рук.:)


Поставте микротик с поддержкой аппаратного шифрования и увидите разницу.
0 #8 Paul 08.07.2016 11:00
Пинги действительно странные, ничего подобного не было. Коннект с майкрософтовски м сервером действительно наблюдается, только он у меня отваливается через несколько секунд после коннекта клиента.
Скорость у sstp на микротиках (на ПО, актуальном данный момент, по крайней мере) действительно низковата. Игры с MTU и MRU ни к чему не привели. Максимальная скорость передачи большого файла, которой мне удалось добиться (100 Мбит каналы с обеих сторон) - около 3 Мбайт/с. При этом процессор разогнанного hex был загружен на 100%. Изучение форумов укрепило в уверенности, что проблемы со скоростью микротиковского sstp - проблемы не только моих кривых рук.:)
0 #7 Misha 21.06.2016 17:03
Судя по графикам SSTP смею предположить, что провайдер использует криво настроенный Burst.
0 #6 mrbublik 22.05.2016 00:21
Цитирую Arthur:
Мда, недостаток знаний формирует паранойю. Проблема с SSTP в том, что он tcp, а потому у него возникает проблема tcp meltdown, в то время как pptp юзает gre, а l2tp юзает udp. Левые соединения - от винды и прочих софтин.

Артур! Буду только рад если вы более развернуто успокоите "параноиков". Насчет трафика от винды. В сети не было виндовых машин. только Linux, точнее Ubuntu.
+2 #5 Arthur 22.05.2016 00:03
Мда, недостаток знаний формирует паранойю. Проблема с SSTP в том, что он tcp, а потому у него возникает проблема tcp meltdown, в то время как pptp юзает gre, а l2tp юзает udp. Левые соединения - от винды и прочих софтин.
+3 #4 mrbublik 12.01.2015 03:23
Цитирую Константин:
Причина внедрения NAT у операторов связи - закончились адреса IPv4. Решение только одно - IPv6. Спрашивайте у операторов связи! :)

version6.ru

Я думаю там будут свои подводные камни. Если каждой станции по реальному ИП... это же голову сломаешь на безопасности ))))
-1 #3 Константин 17.11.2014 15:28
Причина внедрения NAT у операторов связи - закончились адреса IPv4. Решение только одно - IPv6. Спрашивайте у операторов связи! :)

version6.ru

You have no rights to post comments