>Ну, положим, с первыми тремя уровнями всё более-менее хорошо:). Ишь размечтались :) Нате вот, попробуйте что-то типа http://www.ntop.org/n2n/ на модель оси распихать.Ну как?Неплохая смесь?И каким уровнем считается допустим эзернет фрейм VPN`а завернутый в UDP-пакет?А если тунельнутый по HTTP?Huh?А если подобное наложить на wireless mesh сеть например?Вы там не припухнете пытаясь это по OSI отсортировать? :)
>Ибо сильно с железом связаны, там не разгуляешься.
Нюню?См.выше.Можно ведь сгородить и виртуальный адаптер (tun\tap адаптеры например), выгрести из него пакеты и пхнуть их поверх... чего-нибудь.Ну-ка расскажите, как это по OSI классифицировать? :)
>Ну а дальше — чисто софтварные приколы пошли, вот и изгаляются кто во что горазд.
Дело в том что "софтварными приколами" можно без проблем тунельнуть эзернет-фреймы или там что еще поверх чего-то еще.А тунелинг serial-over-tcp например - это каково?Когда по сути все что выше уровня физики компорта - выпихивается в TCP поток.А что, немного похож по свойствам - стало быть, технически реализуемо :)
Ну или вот например так: эзернет-фреймы тунелятся в OpenVPN который пропихнут в TCP конекцию, которая создается HTTP-туннелем поверх HTTP ("как испортить настроение админу файрвола").Ну-ка расскажите, что там у нас с пачками протоколов OSI?Осторожно, мозг не сломайте :D.А тот же Hyper-V например умеет программно назначать виртуальным сетевкам VLAN-ы даже.Такое вот "железо" нынче.
>Программисты — народ, которому его идея важнее чужих, знаю по себе. ;)
В этом мире железо и софт сплетаются в единое целое.Провести четкую грань очень сложно-часто софт является продолжением железа а железо-продолжением софта.Как вам например управление brushless двигателем, когда софт (firmware) иной раз просто *программно* коммутирует обмотки двигла в реалтайме, руля ключами?А раньше такое хардварно делалось - механикой aka коллектором. С которым вечно была куча проблем.
>Да не так уж много проблем.
Много, не много - но есть.
>для SCTP случае UDP и TCP всё равно будут быстрее SCTP,
Как минимум SCTP попросту избавит програмеров в ряде случаев от изобретения велосипедов и костылей которые они изобретают сейчас.
>чисто исходя из соотношения навороченности протоколов, а, значит, у них своя
>ниша останется. ;)
А никто вроде и не собирался их закапывать.Просто еще 1 протокол с новыми свойствами, отличными от TCP и UDP.
>Суть не меняется: это защитная мера. :)
Это просто поправка на суровые реалии :P.Да, в эпоху создания TCP\IP и того что поверх бегает о хакерах не думали.А вот на момент разработки SCTP все уже были в курсе проблемы.
>Зависит от реализации. В OpenBSD поднять IPSec "с нуля" в первый раз,
>обладая исключительно теоретической подготовокой, заняло меньше часа.
Понимаете, я минимальный OpenVPN в режиме "точка-точка" без какой либо особой теоретической подготовки (которая у IPSec достаточно зубодробильная) подниму при отсутствии сюрпризов минут за 5.Ну может 10.При том оно еще и с NATами и фаерволами дружить будет (обычный набор UDP датаграмм или одно TCP соединение).Так что вторая точка легко может быть в Зимбабве при том что я - за натами и файрволами.До кучи может траффик сжимать например.А IPSec - достаточно наворочен, геморроен в настройке и пролезает далеко не везде.
>Во фряхе есть толковое руководство, думаю, цифры те же. В Linux и Windows
>не пробовал, и желания нет, если честно. :)
А у меня вообще особого желания связываться с ipsec нет.Завязываться на одну единственную фряху у меня желания еще меньше.А тот же openvpn я спокойно настрою за те же 10 минут в практически любой системе - а оно более-менее одинаковое везде.Может из-за всего этого ipsec и не шибко популярен? Во всяком случае юзают его весьма мало.
>Не люблю гуй за то, что потом всё равно приходится от него
>отвыкать: в консоли реально быстрее…
Я что-то не уверен что в винде ipsec без гуя настраивается нормально.И, собственно, от VPN зачастую желательно чтобы оно все-таки работало везде и мне как-то не прикольно часами вдупливать "как это настроить на вон той системе?!".Собссно в винде тот же опенвпн с тем же конфигом будет работать(с минимальными поправками на ветер aka особенности платформы, доступно описанные на сайте этой штуки).Как и в пингвине и в *бсд и где там еще.А куда он денется то?Достаточно универсальная штукенция.Может и не всегда лучшая, хз.
>IPSec в моём случае работает в ядре и поэтому заметно более производительный.
А, гм, вы его бенчмаркали?И vs чего?И во что упирались конкуренты?Неужто - в CPU за счет переключения контекстов?А ipsec с его шифрованиями и MACами в CPU при том же не упирался?А то по идее шифрование и MAC хоть в ядре, хоть в юзере а проц всяко нагрузит.И кроме того - VPN обычно юзается на практике для соединения достаточно удаленных мест (филиалов компаний, etc) в единую сеть.Чаще всего каналы для этого отнюдь не толстые и упереться в производительность а не в канал - это еще постараться надо.С любым VPN.
>Ну, про причины широкого распространения NAT я рассказывать не буду. ;) А
>фаерволу ничто не мешает пропускать VPN-траффик между указанными узлами.
Угу, кроме того что если файрволов и натов по пути эн штук - все их конфигурячить несколько запипешься, особенно если они - где-то в заднице.А так ничего.С тем же опенвпн'ом все сильно проще получается ИМХО - достаточно чтобы кто-то 1 мог слушать на 1 порту TCP или UDP и ... все.Явно универсальнее и куда как проще достижимое требование.Можно хоть с жпрса с его натом конектиться. И ты опять в своей сети...
