[Ivan_83]

Если надо поколхозить/себя любимого приконектить по быстрому то L2TP без ипсека.

[Saab95]

И вообще IPSec это прошлый век. Что бы его настроить нужно вводить намного больше команд, чем тот же SSTP.

 

а про проблемки SSTP(как и любого ip over tcp) умалчиваем? ;) ну там tcp meltdown?

 

А через IPSec что данные напрямую через интернет передаются? =)

[^rage^]

а про проблемки SSTP(как и любого ip over tcp) умалчиваем? ;) ну там tcp meltdown?

А через IPSec что данные напрямую через интернет передаются? =)

 

причём тут это? можно напрямую, можно не напрямую. любой пакетлосс - и всё, приехали.

[idv]

И вообще IPSec это прошлый век. Что бы его настроить нужно вводить намного больше команд, чем тот же SSTP.

 

Команды можно и скриптом нагенерить. Там же не соотношение 1 к 100, чтобы от этого так страдать.

 

А вот SSTP в чем реализован на данный момент?

[idv]

(как и любого ip over tcp) умалчиваем? ;) ну там tcp meltdown?

 

Не все так просто - http://www.barabanov.ru/arts/tcp/Tcp_over_tcp_is_not_so_bad-web.pdf

[Saab95]

И вообще IPSec это прошлый век. Что бы его настроить нужно вводить намного больше команд, чем тот же SSTP.

 

Команды можно и скриптом нагенерить. Там же не соотношение 1 к 100, чтобы от этого так страдать.

 

А вот SSTP в чем реализован на данный момент?

 

SSTP на SSL, с гарантированной доставкой пакетов. Вот сделали бы аналог без шифрования - цены бы не было.

[idv]

SSTP на SSL, с гарантированной доставкой пакетов.

 

Я про оборудование

[Saab95]

SSTP на SSL, с гарантированной доставкой пакетов.

 

Я про оборудование

 

Микротик операционка и любой RB (например с самым медленным процессором 400мгц пропускает около 16-20 мегабит через SSTP), Windows 7.

[^rage^]

(как и любого ip over tcp) умалчиваем? ;) ну там tcp meltdown?

Не все так просто - http://www.barabanov.ru/arts/tcp/Tcp_over_tcp_is_not_so_bad-web.pdf

у vpn поверх tcp всё плохо на линках с приличным rtt и даже небольшим пакетлоссом.

попробуйте сидеть через перегруженную соту/радиоканал(да даже с wifi).

плюс проблемы с realtime-трафиком и честностью разделения.

 

автор ответа не учитывает наличия пакетлосса(потому удивляется экспоненте, которая на самом деле из exponential backoff) и наличия шейпинга(а чаще полисинга) у провайдера.

ну малейший пакетлосс делает такой впн неюзабельным(tcp слишком пессимистичен).

 

А через IPSec что данные напрямую через интернет передаются? =)

кстати, можно и напрямую. transport mode никто не запрещал.

[idv]

Микротик операционка и любой RB (например с самым медленным процессором 400мгц пропускает около 16-20 мегабит через SSTP), Windows 7.

 

Я бы сказал - негусто. И это сильный минус для использования SSTP

[vovannovig]

Добавлю личное мнение.

В ситуации которая была у меня на днях,очень удобно было бы использование OpenVPN за ADSL NAT.

А все по тому что когда срочно надо что бы "работало" и выезжают местные умельцы со стороны оператора, для них только "настроить можем в режим роутер". И бодаться с ними и объяснять что у меня все ок,а это они в виду переключения на другую пару забыли "активировать номер" ... для них DSL горит - значит все ок.

 

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

 

Если честно всем проще разграничивать обязанности - светится на модеме Интернет = есть сессия = проблема у пользователя,не светится - оператора.

 

Это не аргумент технический,но скажем так ситуация из повседневной жизни...

[Ivan_83]

ну малейший пакетлосс делает такой впн неюзабельным(tcp слишком пессимистичен).

Уровень пессимизма заметно понижается если cc=htcp, newreno и cubic действительно не очень, на современных скоростях.

[Savaoff]

OpenVPN хорошо работает, и виндовый tap-интерфейс умеет создавать. И тунель строит поверх udp|tcp, на выбор.

 

Есть еще такой vtund, он умеет gzip'овать трафик, если очень надо, остальные возможности как у openvpn, только под винду нет версий.

[nuclearcat]

Я бы не советовал openvpn и прочие userspace туннели. Автору нужен войс и видео, ну и конечно QoS.

IPSEC over UDP (дабы пролезало везде) - возможно лучше, правда не уверен, что l2tp там ядерный. Настраивать не так и просто, но осилить можно.

[^rage^]

ну малейший пакетлосс делает такой впн неюзабельным(tcp слишком пессимистичен).

Уровень пессимизма заметно понижается если cc=htcp, newreno и cubic действительно не очень, на современных скоростях.

так ведь это sender-side, так что на обоих сторонах придётся крутить.

 

Есть еще такой vtund, он умеет gzip'овать трафик, если очень надо, остальные возможности как у openvpn, только под винду нет версий.

я его активно юзаю. им можно даже тегированный трафик гонять. собственно, все минусы tcp-туннелинга заметны на больших rtt и/или наличии пакетлосса.

 

и на wifi это бывает заметно(когда клиентов много или же трафика).

[Saab95]

у vpn поверх tcp всё плохо на линках с приличным rtt и даже небольшим пакетлоссом.

попробуйте сидеть через перегруженную соту/радиоканал(да даже с wifi).

плюс проблемы с realtime-трафиком и честностью разделения.

 

автор ответа не учитывает наличия пакетлосса(потому удивляется экспоненте, которая на самом деле из exponential backoff) и наличия шейпинга(а чаще полисинга) у провайдера.

ну малейший пакетлосс делает такой впн неюзабельным(tcp слишком пессимистичен).

 

Я некоторое время назад активно использовал SSTP для подключения базовых станций через сети сотовых операторов в 3G. Авторизация у клиентов - PPPoE. Через канал сотового поднимался SSTP туннель, поверх него EoIP и передавались данные. Задержка не сильно отличалась от задержки в канале оператора, временами, когда шли потери, задержка естественно подскакивала, но не до каких-то страшных значений, а всего раза в 2-3, и потом быстро понижалась. Про проблемы TCP через TCP говорят те, кто с такими туннелями не сталкивался.

[Ivan_83]

Про проблемы TCP через TCP говорят те, кто с такими туннелями не сталкивался.

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

[Saab95]

Про проблемы TCP через TCP говорят те, кто с такими туннелями не сталкивался.

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

 

Ну ходят чуть с более высокой задержкой, это же не страшно.

[Savaoff]

 

Есть еще такой vtund, он умеет gzip'овать трафик, если очень надо, остальные возможности как у openvpn, только под винду нет версий.

я его активно юзаю. им можно даже тегированный трафик гонять. собственно, все минусы tcp-туннелинга заметны на больших rtt и/или наличии пакетлосса.

 

и на wifi это бывает заметно(когда клиентов много или же трафика).

 

openvpn и vtund используют один и тот же модуль ядра - "tun" написаный Maxim Krasnyansky <max_mk@yahoo.com>.

При этом vtund собственно он же и написал тоже.

В режиме tap'а прекрасно гоняется тегированый трафик, что openvpn, что vtund, подтверждаю.

Оба умеют что поверх tcp, что по верх udp строить туннели.

Изначально юзал vtund, но он долго не восстанавливет тунель, если физика обвалилась-поднялясь - во всяком случае мне не удалось его отстроить. openvpn в этом плане шустрее.

Зато vtund умеет и lzo и zip компрессию, а openvpn только lzo.

Через туннели openvpn между офисами по всей РФ прекрасно работает и голос и видео.

[Ivan_83]

Ну ходят чуть с более высокой задержкой, это же не страшно.

Это у тебя на столе/по городу задержка не высокая, а когда через пол страны летит (пинг 70 - 120) то и VPN восстанавливается долго а TCP ещё дольше и скорость передачи как на диалапе получается, и так же с обрывами.

[^rage^]

 

Я некоторое время назад активно использовал SSTP для подключения базовых станций через сети сотовых операторов в 3G. Авторизация у клиентов - PPPoE. Через канал сотового поднимался SSTP туннель, поверх него EoIP и передавались данные. Задержка не сильно отличалась от задержки в канале оператора, временами, когда шли потери, задержка естественно подскакивала, но не до каких-то страшных значений, а всего раза в 2-3, и потом быстро понижалась.

 

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

но вот у авторов uTP тоже всё работало в локалке, а в реальности они всем причинили попаболь ;)

например, у меня дома запущенный в dynamips ios терминировал pppoe и натил(с вполне приличными цифрами, кстати). но это не значит, что так надо делать.

 

Про проблемы TCP через TCP говорят те, кто с такими туннелями не сталкивался.

я ~ уже 3 года пользуюсь таким туннелем в самых разных позах(было даже tcp over icmp + vtund) и насмотрелся всякого. например, можно огрести классные проблемы из-за pmtu.

единственное место, где есть плюс от vpn over tcp - это каналы, умирающие от пакетрейта.

 

кстати, на 3G чаще не не потери, а именно rtt прыгает. я не раз сталкивался с ситуацией, когда на перегруженной соте если запустить ping, то ответы приходят не поштучно, а пачкой.

[vovannovig]

^rage^ Извините за прямолинейность,упустил ход Ваших мыслей, так за какую технологию Вы?

vtund(или может OpenVPN) или ipsec ...

или вы просто против SSTP?

Изменено 4 апреля, 2013 пользователем vovannovig

[^rage^]

^rage^ Извините за прямолинейность,упустил ход Ваших мыслей, так за какую технологию Вы?

vtund(или может OpenVPN) или ipsec ...

или вы просто против SSTP?

я за l2tpv3 + ipsec.

sstp мне не нравится в первую очередь из-за того что это очередной инвалид от microsoft без стандарта.

ipsec - это просто кубик, добавляющий шифрование. причем, я бы его использовал в transport mode для шифрования payload' пакетов туннеля.

[idv]

ну а я за gre+ipsec

[vovannovig]

я за l2tpv3 + ipsec.

А на сем кроме Cisco и "софт-маршрутизаторах" еще реализовывается?

Насчет D-link интересовался на ихнем форуме - говорят нет

( http://forum.dlink.ru/viewtopic.php?f=3&t=159328&p=857932#p857932 )

ну а я за gre+ipsec

"старая хорошо обкатанная архитектура".

Изменено 4 апреля, 2013 пользователем vovannovig