прекрасно видел и ощущал на себе, когда использовал openvpn/vtund через отельный wifi в египте.
там были потери ~ 3-6% и при этом работать по ssh было невозможно(в лучшем случае всё жутко тормозило, в худшем — соединение «подвисало»).
>Собственно, это — ответ на «вы можете аутентификацию сделать как душе угодно».
а можно пример именно двухфакторной аутентификации?
afaik, в eap можно либо/либо. т.е. либо сертификаты(в т.ч. на смарткарте), либо различные варианты пароля(plain/hash/challenge-response)
sstp — это ppp over https + немного обвязки.
причём, сервер аутентифицируется на этапе установления ssl-соединения. после этого запускается ppp, ну а там уже кто как хочет: различные варианты eap или же ms-chap(со всеми его болячками).
т.е. в лучшем случае у вас будет всё на сертификатах, в худшем — пароли.
А вообще, я не понимаю тяги msft к созданию велосипедов на базе ppp:
1. сначала прикрутили шифрование к ppp(mppe), но оно оказалось слабым.
2. потом решили гонять ppp внутри gre. так родился pptp.
3. потом на пару с cisco у них родилась идея «а давайте всё как в pptp, но только внутри udp-пакетов?». так появился l2tp.
4. потом вспомнили про шифрование. так появился l2tp/ipsec
5. потом подумали что как-то плохо вся эта конструкция проходит через nat. придумали sstp.
т.е. всё тот же трупик ppp, но к нему всё время пытаются какие-то архитектурные штуки приделать, чтобы оно работало в современных ip-сетях.
лучше бы сделали у себя l2tpv3(с его pseudowire и прочими плюшками) + ipsec с nat-t.
либо сделали на базе sctp: там и multihoming(можно через несколько интернет-каналов без костылей работать), и multistreaming(в рамках одного коннекта можно несколько потоков данных гонять) и границы сообщений(tcp — это просто поток байт: 2 вызова write() по 500 байт не гарантируют что 2 read() на той стороне вернут вам по 50 байт. это может быть и сразу 500, и 200 + 300, и любые другие комбинации).
У нас в компании все под виндой работают, поэтому нам было бы удобно :)
мне кажется, вы таким образом сами раскладываете себе кучу грабель в виде vendor lock-in.
ipsec — стандарт, в отличие от sstp. причём, в ipsec вы можете аутентификацию сделать как душе угодно(да хоть те же смарткарты) или двухфакторную аутентификацию.
Однако, поскольку он инкапсулирует данные дважды, это не так эффективно, как SSL-решения (например, OpenVPN или SSTP), и поэтому работает немного медленнее.
1) а ничего, что openvpn работает в userspace, а ipsec — в ядре?
2)и намного — это во сколько раз?
3)ничего не сказано про пагубность tcp over tcp и чудесах, которые начинаются при малейшем packetloss.
4)о какой версии l2tp идет речь в статье?
5. В мире телекома принято доверять друг другу, особенно запросам, пришедшим по сетям SS7, и HLR оператора не является исключением из этого правила. На рисунке 3 показана выдержка из трассировки. HLR находит в своих базах данных идентификатор IMSI абонента (1) и адрес MSC/VLR (2), в зоне действия которого находится абонент с заданным номером, и, не подозревая подвоха, сообщает своему «собеседнику» эти данные. Здесь можно обратить внимание на значения некоторых цифр. Первые три цифры идентификатора IMSI обозначают код страны абонента (Mobile Country Code, MCC). Код 250 закреплен за Россией (1). Адрес коммутатора предоставляется в более привычной для нас телефонной нумерации, где 380 — международный телефонный код Украины (2).
В чём проблема такого подхода? Во-первых, любая сеть, с которой есть соглашение об обмене SMS, может запросто получить данные о местоположении абонентов (с точностью до MSC). Информация о местоположении может быть использована при организации массовых санкционированных и несанкционированных рассылок. Поскольку каждый коммутатор отвечает за определённый географический регион, у организатора рассылки появляется возможность отправлять различные варианты рекламного текста в зависимости от местоположения абонента.
Также, если внимательно взглянуть на рисунок выше, то можно заметить, что абонент получит SMS даже в том случае, если mt-ForwardSM Ack (подтверждение о доставке SMS) не будет доставлен к SMSC. Это позволяет организовывать мошенничества, в которых адреса отправителя и SMSC заменяются на чужие и таким образом счёт за терминацию SMS будет выставлен совсем другому оператору.
Чтобы решить эти, а также ряд других проблем, организация 3GPP разработала спецификацию TR 23.840.
Основная идея этого документа состоит в том, чтобы именно домашняя сеть отвечала за доставку смс на текущий MSC абонента. Для минимизации изменений в существующих сетях, домашняя сеть должна отвечать адресом виртуального MSC на все запросы sendRoutingInfoForSM из других сетей. Таким образом все входящие сообщения будут поступать на этот виртуальный коммутатор, а с него уже на настоящий.
Такая схема позволяет решить все проблемы с минимальными изменениями в существующей инфраструктуре. При этом появляется возможность не только контролировать текст получаемых сообщений (борьба со спамом), но также и блокировать работу многих “хитрых” сервисов, использующих sendRoutingInfoForSM для получения информации об абоненте.
P.S. Хотя документ написан и утверждён довольно давно, мне не доводилось встречать его практических реализаций. Если Вы используете такие системы или есть сведения об их использовании другими операторами – оставляйте комментарии.
для того чтобы точно определять местоположение надо ставить доп. оборудование на сети.
TA вам даст лишь вон ту голубую полоску на картинке
В плотной городской застройке, когда BTS ставят чуть ли не на каждом доме ширина этой полоски где-то 250м.
Плюс, MS сам выбирает соту исходя из возможных энергозатрат на связь с ней, так что это далеко не ближайшая географически :)
Во время моей работы в одном из операторов большой тройки доводилось разбирать ситуацию, когда абонент рыбачил на озере. Озеро находилось на границе Тверской и Ленинградской области. Так вот, телефон решил что энергоэффективнее работать с BTS на другом конце озера и абонент попал в роуминг(хотя физически находился в домашнем регионе).
Опять же, в том же сотовом операторе у одного из директоров угнали авто, где стояла gsm-сигнализация с sim-картой этого оператора. Дело было в центре города, по смс-командам несколько раз глушили двигатель и угонщики её бросили в одном из дворов. На дежурной смене инженеры посмотрели lac/cellid/ta и по ним быстро получили район поиска. В итоге, владелец машины и несколько его друзей несколько часов блуждали в этом районе и не нашли. Нашли только на следующий день.
Так что если в городской черте точность еще более-менее, то за пределами — всё весьма грустно.
PS: если бы у меня была цель скрыться от такого наблюдения, то в нужном месте достаточно поставить gsm-voip шлюз(цена вопроса ~ 100$)
PPS: а разьве provideSubscriberInfo не требует открытого camel-роуминга?
ну вот про 80/20 вы в курсе.
>Исходя из того, что Vyatta, условно, не имеет 80% функционала нормальных роутеров
можете это утверждение как-то обосновать?
опять же, о каком именно железе речь и на какой сегмент рынка мы ориентируемся?
вы не могли бы обосновать своё утверждение? как минимум, о каких цифрах ( gbit/s & mpps ) идёт речь?
всё расписано и задокументировано. где геморрой?
там были потери ~ 3-6% и при этом работать по ssh было невозможно(в лучшем случае всё жутко тормозило, в худшем — соединение «подвисало»).
а можно пример именно двухфакторной аутентификации?
afaik, в eap можно либо/либо. т.е. либо сертификаты(в т.ч. на смарткарте), либо различные варианты пароля(plain/hash/challenge-response)
причём, сервер аутентифицируется на этапе установления ssl-соединения. после этого запускается ppp, ну а там уже кто как хочет: различные варианты eap или же ms-chap(со всеми его болячками).
т.е. в лучшем случае у вас будет всё на сертификатах, в худшем — пароли.
А вообще, я не понимаю тяги msft к созданию велосипедов на базе ppp:
1. сначала прикрутили шифрование к ppp(mppe), но оно оказалось слабым.
2. потом решили гонять ppp внутри gre. так родился pptp.
3. потом на пару с cisco у них родилась идея «а давайте всё как в pptp, но только внутри udp-пакетов?». так появился l2tp.
4. потом вспомнили про шифрование. так появился l2tp/ipsec
5. потом подумали что как-то плохо вся эта конструкция проходит через nat. придумали sstp.
т.е. всё тот же трупик ppp, но к нему всё время пытаются какие-то архитектурные штуки приделать, чтобы оно работало в современных ip-сетях.
лучше бы сделали у себя l2tpv3(с его pseudowire и прочими плюшками) + ipsec с nat-t.
либо сделали на базе sctp: там и multihoming(можно через несколько интернет-каналов без костылей работать), и multistreaming(в рамках одного коннекта можно несколько потоков данных гонять) и границы сообщений(tcp — это просто поток байт: 2 вызова write() по 500 байт не гарантируют что 2 read() на той стороне вернут вам по 50 байт. это может быть и сразу 500, и 200 + 300, и любые другие комбинации).
мне кажется, вы таким образом сами раскладываете себе кучу грабель в виде vendor lock-in.
ipsec — стандарт, в отличие от sstp. причём, в ipsec вы можете аутентификацию сделать как душе угодно(да хоть те же смарткарты) или двухфакторную аутентификацию.
в каком смысле?
а теперь то же самое, но на cisco/juniper.
а теперь еще с nat-t:
1) а ничего, что openvpn работает в userspace, а ipsec — в ядре?
2)и намного — это во сколько раз?
3)ничего не сказано про пагубность tcp over tcp и чудесах, которые начинаются при малейшем packetloss.
4)о какой версии l2tp идет речь в статье?
отсюда
TA вам даст лишь вон ту голубую полоску на картинке
В плотной городской застройке, когда BTS ставят чуть ли не на каждом доме ширина этой полоски где-то 250м.
Плюс, MS сам выбирает соту исходя из возможных энергозатрат на связь с ней, так что это далеко не ближайшая географически :)
Во время моей работы в одном из операторов большой тройки доводилось разбирать ситуацию, когда абонент рыбачил на озере. Озеро находилось на границе Тверской и Ленинградской области. Так вот, телефон решил что энергоэффективнее работать с BTS на другом конце озера и абонент попал в роуминг(хотя физически находился в домашнем регионе).
Опять же, в том же сотовом операторе у одного из директоров угнали авто, где стояла gsm-сигнализация с sim-картой этого оператора. Дело было в центре города, по смс-командам несколько раз глушили двигатель и угонщики её бросили в одном из дворов. На дежурной смене инженеры посмотрели lac/cellid/ta и по ним быстро получили район поиска. В итоге, владелец машины и несколько его друзей несколько часов блуждали в этом районе и не нашли. Нашли только на следующий день.
Так что если в городской черте точность еще более-менее, то за пределами — всё весьма грустно.
PS: если бы у меня была цель скрыться от такого наблюдения, то в нужном месте достаточно поставить gsm-voip шлюз(цена вопроса ~ 100$)
PPS: а разьве provideSubscriberInfo не требует открытого camel-роуминга?
эээ… вы получите EPERM при попытке добавить обычный файл в epoll.