forum.opennet.ru

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Оглавление

Увидел свет OpenVPN 2.4.0, opennews (??), 28-Дек-16, (0) [смотреть все]

интересно, производительность по сравнению с open any connect как Кто-нибудь за, Аноним (-), 11:13 , 28-Дек-16, (3) –2 //

А это что такое, впрочем, мне не интересно, линуха-линуха и через ssh нормально , cmp (ok), 13:25 , 28-Дек-16, (24) +3 //

неправда, прекрасно стандартизован , qwerty123 (??), 15:53 , 28-Дек-16, (45) –1 //

А я утверждал обратное Нет Я говорил о том, что сервер под разных клиентов gre , cmp (ok), 04:38 , 29-Дек-16, (81) –1

Можете чуть подробнее рассказать, что вы имеете ввиду под GRE у каждого свой Не, zanswer (?), 12:46 , 29-Дек-16, (87)

GRE, OSPF, BGP, STP, LLDP и наверняка еще столько же не вспомнил, протоколы и ст, cmp (ok), 15:46 , 29-Дек-16, (93) –1

Если честно, исключая LLDP, с ним плотно не работал, у названных протоколов проб, zanswer (?), 15:53 , 29-Дек-16, (94)

Повезло вам, а нам на циски денег не дают, лучшее из того, что есть - это хуавей, cmp (ok), 10:00 , 30-Дек-16, (118)

Я слышал много хорошего о Huawei, по отношению к другим Китайским брендам , zanswer CCNA RS (?), 10:39 , 30-Дек-16, (120) –1

В целом железо прекрасное, в 2 раза дешевле и в 2 раза производительнее циски , cmp (ok), 12:23 , 30-Дек-16, (124)

Со стороны Juniper проблем тоже ни видел и вряд ли будут, но вот Cisco очень люб, Нечестивый (ok), 13:15 , 31-Дек-16, (127)

Если пакеты на одной из сторон не возвращаются, значит имеет место быть их потер, zanswer (?), 15:57 , 29-Дек-16, (95)

НА Интерфейс туннеля нет, а на интерфейс физический gre трафик сыпется , cmp (ok), 09:54 , 30-Дек-16, (117)

С удовольствием бы сделал TSHOOT по данной теме, если трафик дошёл до физическог, zanswer CCNA RS (?), 10:42 , 30-Дек-16, (121) –1

Было время когда GRE грустно ходил через NAT на сохо железках Лично я с той пор, ram_scan (?), 16:34 , 28-Дек-16, (49) +3 //

с тех пор что-то изменилось GRE и сейчас грустно ходит через NAT, Аноно (?), 00:52 , 29-Дек-16, (74) +1
Даже сейчас есть железо через которое gre не натится, причем операторское , cmp (ok), 04:26 , 29-Дек-16, (80)

Тому есть вполне простое объяснение, вытекающие из формата заголовка GRE, а дела, zanswer (?), 12:42 , 29-Дек-16, (86)

Дело в том, что железка которая не умеет стоила 3 миллиона дервянных в 13-14 год, cmp (ok), 16:01 , 29-Дек-16, (96)

Cisco тоже не умеет делать ASIC accelerated NAT для GRE, насколько я знаю, поско, zanswer (?), 16:17 , 29-Дек-16, (98)

GRE без IPSec бесполезен, если же вы про PPTP GRE вариант, то он не актуален сов, zanswer (?), 12:25 , 29-Дек-16, (85) +1
Кстати, насчёт UDP, есть вот такой draft, GRE-in-UDP https tools ietf org htm, zanswer (?), 13:37 , 29-Дек-16, (91)

Не в обиду, но все эти ваши ipsec и gre очень геморны в настройке, застревают на, Аноним (-), 00:20 , 03-Янв-17, (133) –1

Есть хорошая статья по установке и настройке OpenVPN , Аноним (-), 11:27 , 28-Дек-16, (5) //

Измена Родине подойдёт , Andrey Mitrofanov (?), 11:28 , 28-Дек-16, (7) +84 //

спасибо, поржал хотя на сегодня более актуальна ст 280, Аноним (-), 12:04 , 28-Дек-16, (12) //

282-я же, для опеннета, по крайней мере После 130-й P S Притянуто за уши, н, ZloySergant (ok), 17:54 , 28-Дек-16, (58) +1

Есть, а что , Аноним (-), 11:30 , 28-Дек-16, (8) +1
да и книги естьhttps openvpn net index php open-source books htmlэта гуляет в , Аноним (-), 11:39 , 28-Дек-16, (11)
косвенно https bettercrypto org , Аноним (-), 13:34 , 28-Дек-16, (26)
На Digitalocean все есть https www digitalocean com community tutorials how-to, dep (?), 14:21 , 28-Дек-16, (34) +4
Нижняя палата РФ уже работает над этим , Аноним (-), 20:08 , 28-Дек-16, (64) +2

Плак-плак , Аноним (-), 11:33 , 28-Дек-16, (9) +1 //

это диверсия , Аноним (-), 12:11 , 28-Дек-16, (13) +1 //

с этим надо что-то делать, 404 not found (?), 04:24 , 29-Дек-16, (79) +1

Я слышал, что есть какие-то системы, определяющие OpenVPN, вроде как провайдет м, VPN это сила (?), 12:32 , 28-Дек-16, (14) +12 //

https duckduckgo com q openvpn traffic obfuscation, Andrey Mitrofanov (?), 12:36 , 28-Дек-16, (16) +4 //

Спасибо, очень интересно , VPN это сила (?), 12:40 , 28-Дек-16, (17) –1
Посадят тебя по твоей же статье Хоть и за утку вместо спутника , Аноним (-), 00:23 , 03-Янв-17, (134)

Для этого как раз сделали опцию tls-crypt в новой версии , sage (??), 19:29 , 28-Дек-16, (62) +1

Вот это мне кажется очень мощная фича Такое только в OpenVPN есть, или где-то е, VPN это сила (?), 12:33 , 28-Дек-16, (15) +8 //

Не совсем понимаю в каких случаях это может пригодиться , Меломан1 (?), 13:32 , 28-Дек-16, (25) –1 //

GPRS, Аноним (-), 14:23 , 28-Дек-16, (35) //

Не актуально Прокачиваться будет не более 33 6кбит c даже заголовки сообщений , Меломан1 (?), 14:51 , 28-Дек-16, (37) –2

на IRC хватит, Клыкастый (ok), 15:51 , 28-Дек-16, (43)

Например, чтобы не палиться перед ISP, постоянно переподключая VPN-соединение дл, Аноним (-), 16:29 , 28-Дек-16, (47)
Multi-Wan вариации всех типов и Multipath-TCP использование в Ad-Hoc Mesh сетях, Аноним (-), 02:58 , 30-Дек-16, (106)
Вот авторы RFC4555 Mobility and Multihoming Protocol MOBIKE , дают исчерпывающи, zanswer CCNA RS (?), 08:52 , 30-Дек-16, (115)
В любых когда соединение нестабильное Например беспроводка Не круто, понимаешь, Аноним (-), 00:30 , 03-Янв-17, (135) –1

Чет не очень понимаю зачем, давеча поставил фалег лится на ноут с хранилища, смо, cmp (ok), 13:38 , 28-Дек-16, (29) –3 //

Ни хера не понял в твоих манипуляциях Подробности, пожалуйста , Меломан1 (?), 14:03 , 28-Дек-16, (31) –1 //

Это явно юный админ локалхоста говорит фразы продолжения которых не знает , Аноним (-), 14:48 , 28-Дек-16, (36)
brctl addif br0 tun0че непонятного, cmp (ok), 03:30 , 29-Дек-16, (77)

В новости говорится что можно сменить IP или и порт и соединение не прервётся Я , Аноним (-), 15:18 , 28-Дек-16, (42) –1 //

ты всё правильно понял, а гражданин суммирует часы и устриц , Клыкастый (ok), 15:53 , 28-Дек-16, (44) +1

Устрицы в голове у тебя ядро шлет пакеты на хост до которого нет маршрута, межд, cmp (ok), 04:18 , 29-Дек-16, (78)

IP рассчитывает ширину канала по потерям Можете подробнее изложить свою мысль, , zanswer (?), 13:05 , 29-Дек-16, (88) //

Определенно, но хотел включить UDP в множество, хотя зря, так как особенности ре, cmp (ok), 16:10 , 29-Дек-16, (97)

Речь я так понимаю идёт о том, что OpenVPN теперь может динамически в рамках одн, zanswer (?), 13:10 , 29-Дек-16, (89) //

А какая ценность у этой сессии я хотел обратить внимание на то, что при ее разр, cmp (ok), 16:17 , 29-Дек-16, (99)

а какие надлежащие параметры и требуют ли они установки с обоих сторон соединени, J.L. (?), 16:50 , 29-Дек-16, (100) –1

Как любил говорить один не_товарищь - открытия требую экспериментов Вообще не по, cmp (ok), 00:38 , 30-Дек-16, (104)

macOS не чем принципиально от любого другого Unix в этом отличаться не будет, та, zanswer CCNA RS (?), 06:27 , 30-Дек-16, (109)

У меня конечно же нет ответа, который устроит всех, но давайте представим следую, zanswer (?), 17:29 , 29-Дек-16, (101)

Это какбы его работа, которая выполняется ровно на столько, на сколько выделятся, cmp (ok), 01:19 , 30-Дек-16, (105)

MPLS L2 VPN через всю страну, это очень дорогое удовольствие в каждый филиал, ег, zanswer CCNA RS (?), 05:42 , 30-Дек-16, (107) –1

Согласен, но в большенстве случаев перед ИТ клиентов л2впн стоят другие задачи, , cmp (ok), 07:11 , 30-Дек-16, (110)

Вы всё время замыкаетесь на L2 VPN, к тому же операторский, что не всегда возмож, zanswer CCNA RS (?), 07:31 , 30-Дек-16, (111)

OpenVPN TUN этот который p2p , путаю их все время с TAP, если да, то почему не с, cmp (ok), 09:38 , 30-Дек-16, (116)

Выбор типа VPN, L2 L3 лежит в плоскости требований вашей сети, обычно L2 VPN исп, zanswer CCNA RS (?), 10:30 , 30-Дек-16, (119)

Если у вас так, то я за вас рад А у нас все сильно по-другому, и у остальных то, cmp (ok), 13:06 , 30-Дек-16, (125)

Что касается GRE, то у него компактный заголовок, он без каких либо проблем позв, zanswer (?), 11:09 , 30-Дек-16, (122) –1

Странно, при размещении сообщения куда-то OpenVPN потерялся Я имел ввиду, что O, zanswer CCNA RS (?), 11:23 , 30-Дек-16, (123) –1

Поясню насчёт кейсов, что я имел ввиду Первый кейс, классическая топология Hub-a, zanswer (?), 06:19 , 30-Дек-16, (108) –1

не такие уж и разные, о безопасности вообще спорно, нормальные безопасники сами , cmp (ok), 07:55 , 30-Дек-16, (112)

Под требованиями безопасности я понимаю, не только обеспечение конфиденциальност, zanswer CCNA RS (?), 08:04 , 30-Дек-16, (113) –1
В общем и целом, проблема защиты от утечек конфиденциальной информации или атак , zanswer CCNA RS (?), 08:07 , 30-Дек-16, (114) –1

ipsec mobike https tools ietf org html rfc4555, бугага (?), 18:10 , 28-Дек-16, (59)

Жаль что многопоточность так и не завезли , Аноним (-), 12:54 , 28-Дек-16, (18) //

А на кой, если надо из in-буффера скопировать в out-buffer, у вас копирование фа, cmp (ok), 13:46 , 28-Дек-16, (30) //

что делают виндопользователи на опеннете , Аноним (-), 14:04 , 28-Дек-16, (32) //

Ламерить не надоело , Аноним (-), 15:11 , 28-Дек-16, (40) –2
ext3 С разморозкой , cmp (ok), 03:28 , 29-Дек-16, (76)

Не ed25519, не chacha20-poly1305 Как-то не очень секьюрно , Ilya Indigo (ok), 13:37 , 28-Дек-16, (27) –1 //

Ну тогда во https www phoronix com scan php page news_item px WireGuard-2016Э, Аноним (-), 14:45 , 03-Янв-17, (136) +1

Многопоточности все еще не хватает , arrnorets (ok), 14:07 , 28-Дек-16, (33)
маршруты как будут добавляться У них и раньше можно было запускать, только без , Аноним (-), 15:04 , 28-Дек-16, (38) –1 //

Возможно они допилили OpenVPN Service под виндой Теперь OpenVPN GUI просто прос, K.O. (?), 18:32 , 28-Дек-16, (61)
Вендузятники должны страдать , Led (ok), 22:28 , 28-Дек-16, (68) +1

Многопоточности все еще не хватает , анан (?), 15:09 , 28-Дек-16, (39)
Уже сто лет как есть в IPsec Приятно, что OpenVPN догоняет , h31 (ok), 16:26 , 28-Дек-16, (46) –1 //

Скажите честно вы ipsec вообще использовали , Аноним (-), 17:19 , 28-Дек-16, (52) +2 //

Я использую уже несколько лет Linux 8212 Linux 124 Android , если важно Пр, Ктулху (?), 23:19 , 28-Дек-16, (69) //

Админов локалхоста просят проходить мимо , Аноним (-), 11:15 , 29-Дек-16, (82)

Да, постоянно пользуюсь Настроил pcrypt многопоточное шифрование - вообще кра, h31 (ok), 00:01 , 29-Дек-16, (73) //

Авторизация конечно же psk , Аноним (-), 11:16 , 29-Дек-16, (83)

Тут и можно поспорить кто догоняет Ipsec если бы был прост в настройке так же к, obl (ok), 23:43 , 28-Дек-16, (71) //

А уж как прекрасно у ipsec c межвендорной совместимостью, это просто праздник ка, Аноним (-), 11:18 , 29-Дек-16, (84)
Всё относительно, Cisco EasyVPN Server IPsec Cisco AnyConnect Client IPsec , zanswer (?), 18:42 , 29-Дек-16, (103)

Разве IPSec поддерживает динамические изменение IP адреса IKE при этом сохранит, zanswer (?), 13:28 , 29-Дек-16, (90)
Догоняет что Нормальная кривая это 25519 А нистовские кривые возможно с бэкдор, Аноним (-), 14:58 , 03-Янв-17, (137) –1

Интересно, а почему это --no-iv объявлена устаревшей , Аноним (-), 22:13 , 28-Дек-16, (67) –1 //

ну и за что минус по существу вопроса сказать нечего , Аноним (-), 09:12 , 02-Янв-17, (132) –1

А подскажет кто, можно ли настроить openvpn так, чтобы в зависимости от имени по, ALex_hha (ok), 00:18 , 31-Дек-16, (126) –1 //

можно, Аноним (-), 10:58 , 01-Янв-17, (128)
через ccd выдаешь фиксированный ip, и ограничиваешь ему доступ фаерволом, анон (?), 09:50 , 09-Янв-17, (138)

Я не могу найти подтверждения в источнике о том, что эти метаданные остаются отк, demfloro (ok), 11:33 , 01-Янв-17, (129)
В какую сторону смотреть , ALex_hha (ok), 23:36 , 01-Янв-17, (130) –1 //

client-connect client-disconnect learn-address, common_name например , Аноним (-), 09:10 , 02-Янв-17, (131)

Заявленный пакет для CentOS кто-нибудь видел , Аноним (-), 19:46 , 21-Мрт-17, (139)
Доброго дня, Бояре Кто может просветить, каким оброзом опция tls-crypt в 2 4 п, Аноним (-), 12:34 , 15-Апр-17, (140)

Сообщения [Сортировка по времени | RSS]

15. "Увидел свет OpenVPN 2.4.0" +8 +/–

Сообщение от VPN это сила (?), 28-Дек-16, 12:33

> Добавлена возможность бесшовной смены IP-адреса и номера сетевого порта клиента без разрыва соединения VPN.
Вот это мне кажется очень мощная фича. Такое только в OpenVPN есть, или где-то еще?

Ответить | Правка | Наверх | Cообщить модератору

25. "Увидел свет OpenVPN 2.4.0" –1 +/–

Сообщение от Меломан1 (?), 28-Дек-16, 13:32

Не совсем понимаю в каких случаях это может пригодиться?

Ответить | Правка | Наверх | Cообщить модератору

35. "Увидел свет OpenVPN 2.4.0" +/–

Сообщение от Аноним (-), 28-Дек-16, 14:23

GPRS

Ответить | Правка | Наверх | Cообщить модератору

37. "Увидел свет OpenVPN 2.4.0" –2 +/–

Сообщение от Меломан1 (?), 28-Дек-16, 14:51

Не актуально. Прокачиваться будет не более 33.6кбит/c. даже заголовки сообщений будут с трудом просачиваться на таком соединении.

Ответить | Правка | Наверх | Cообщить модератору

43. "Увидел свет OpenVPN 2.4.0" +/–

Сообщение от Клыкастый (ok), 28-Дек-16, 15:51

> Прокачиваться будет не более 33.6кбит/c
на IRC хватит

Ответить | Правка | Наверх | Cообщить модератору

47. "Увидел свет OpenVPN 2.4.0" +/–

Сообщение от Аноним (-), 28-Дек-16, 16:29

Например, чтобы не палиться перед ISP, постоянно переподключая VPN-соединение для смены IP.

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

106. "Увидел свет OpenVPN 2.4.0" +/–

Сообщение от Аноним (-), 30-Дек-16, 02:58

Multi-Wan вариации(всех типов) и Multipath-TCP использование.
в Ad-Hoc/Mesh сетях тоже обычное дело(а там и оборонные и помышленные среди них есть а не только меш потато и вские гипербореи).

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

115. "Увидел свет OpenVPN 2.4.0" +/–

Сообщение от zanswer CCNA RS (?), 30-Дек-16, 08:52

Вот авторы RFC4555 Mobility and Multihoming Protocol (MOBIKE), дают исчерпывающий ответ, зачем это может понадобиться.
There are scenarios where these IP addresses might change. One example is mobility: a host changes its point of network attachment and receives a new IP address. Another example is a multihoming host that would like to change to a different interface if, for instance, the currently used interface stops working for some reason.
The main scenario for MOBIKE is enabling a remote access VPN user to move from one address to another without re-establishing all security associations with the VPN gateway.  For instance, a user could start from fixed Ethernet in the office and then disconnect the laptop and move to the office's wireless LAN.  When the user leaves the office, the laptop could start using General Packet Radio Service (GPRS); when the user arrives home, the laptop could switch to the home wireless LAN. MOBIKE updates only the outer (tunnel header) addresses of IPsec SAs, and the addresses and other traffic selectors used inside the tunnel stay unchanged. Thus, mobility can be (mostly) invisible to applications and their connections using the VPN.
Протоколы разные, но принцип схожий, что IPsec, что OpenVPN, должны сначала выполнить согласование ряда параметров, как то алгоритмы шифрования, хеширования, выполнить аутентификацию, согласовать общий ключ для симметричных алгоритмов шифрования и HMAC функций и тд. Всё это требует времени, вычислительных ресурсов и может привести к потерям сегментов/датаграм, что в зависимости от типа приложений может быть, как критично для QoE, так и нет. То есть посторонние шумы или обрыв VoIP звонка, это плохо, снижение скорости закачки файла на короткий промежуток времени нет.

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

135. "Увидел свет OpenVPN 2.4.0" –1 +/–

Сообщение от Аноним (-), 03-Янв-17, 00:30

> Не совсем понимаю в каких случаях это может пригодиться?
В любых когда соединение нестабильное. Например беспроводка. Не круто, понимаешь, если все дружно отлипает только на том основании что реконект случился.

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

29. "Увидел свет OpenVPN 2.4.0" –3 +/–

Сообщение от cmp (ok), 28-Дек-16, 13:38

> Вот это мне кажется очень мощная фича. Такое только в OpenVPN есть,
> или где-то еще?
Чет не очень понимаю зачем, давеча поставил фалег лится на ноут с хранилища, смотрю скорость бе, воткнул провод, 1 строкой в shell перевесил ip на ethernet и ни ssh не порвалось, ни закачка.
Хотя чисто из академического интереса можно запихивать vpn-интерфейсы в мост с stp, но  при сходимость кольца все равно потеряет данные, IP всегда теряет данные, он байдизайн ширину канала по потерям расчитывает, так-то.

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

31. "Увидел свет OpenVPN 2.4.0" –1 +/–

Сообщение от Меломан1 (?), 28-Дек-16, 14:03

Ни хера не понял в твоих манипуляциях. Подробности, пожалуйста.

Ответить | Правка | Наверх | Cообщить модератору

36. "Увидел свет OpenVPN 2.4.0" +/–

Сообщение от Аноним (-), 28-Дек-16, 14:48

Это явно юный админ локалхоста говорит фразы продолжения которых не знает.

Ответить | Правка | Наверх | Cообщить модератору

77. "Увидел свет OpenVPN 2.4.0" +/–

Сообщение от cmp (ok), 29-Дек-16, 03:30

brctl addif br0 tun0
че непонятного

Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

42. "Увидел свет OpenVPN 2.4.0" –1 +/–

Сообщение от Аноним (-), 28-Дек-16, 15:18

>> Добавлена возможность бесшовной смены IP-адреса и номера сетевого порта клиента без разрыва соединения VPN.
> перевесил ip на ethernet и ни ssh не порвалось, ни закачка.
В новости говорится что можно сменить IP или/и порт и соединение не прервётся.
Я правильно понял что ты не менял ни IP ни порт и говоришь "У меня и так работает"?

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

44. "Увидел свет OpenVPN 2.4.0" +1 +/–

Сообщение от Клыкастый (ok), 28-Дек-16, 15:53

> Я правильно понял что ты не менял ни IP ни порт и говоришь "У меня и так работает"?
ты всё правильно понял, а гражданин суммирует часы и устриц.

Ответить | Правка | Наверх | Cообщить модератору

78. "Увидел свет OpenVPN 2.4.0" +/–

Сообщение от cmp (ok), 29-Дек-16, 04:18

> ты всё правильно понял, а гражданин суммирует часы и устриц.
Устрицы в голове у тебя. ядро шлет пакеты на хост до которого нет маршрута, между удалением ip с одного интерфейса и навешиванием на другой, и должно бы возвращать - но_роут_ту_хост, но не возвращает же, покрайней мере сразу, значит переустановить соединение-туннель есть время, а уж ip и порт нового значения не имеют, при правильно отстроенных буфферах и таймаутах соединения в туннеле даже не поймут, что что-то произошло.

Ответить | Правка | Наверх | Cообщить модератору

88. "Увидел свет OpenVPN 2.4.0" +/–

Сообщение от zanswer (?), 29-Дек-16, 13:05

IP рассчитывает ширину канала по потерям? Можете подробнее изложить свою мысль, что вы имеете ввиду?
Для каких целей IP протоколу, который является stetaless протоколом, потребовалось рассчитывать ширину канала, да ещё и по потерям. Может быть вы имели ввиду TCP?

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

97. "Увидел свет OpenVPN 2.4.0" +/–

Сообщение от cmp (ok), 29-Дек-16, 16:10

>  Может быть вы имели ввиду TCP?
Определенно, но хотел включить UDP в множество, хотя зря, так как особенности реализации отдельного кое-чего на udp к делу отношения не имеют.

Ответить | Правка | Наверх | Cообщить модератору

89. "Увидел свет OpenVPN 2.4.0" +/–

Сообщение от zanswer (?), 29-Дек-16, 13:10

Речь я так понимаю идёт о том, что OpenVPN теперь может динамически в рамках одной сессии, менять tunnel source, что в прошлом приводило к разрыву сессии.
Вы же я так понимаю tunnel source не меняли, а изменили только его положение (перенесли на другой интерфейс). Поэтому да, tunnel destiantion не заметил подмены, как вы сами правильно заметили при правильных размерах буфера и dead interval, сессия не будет потеряна.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

99. "Увидел свет OpenVPN 2.4.0" +/–

Сообщение от cmp (ok), 29-Дек-16, 16:17

>  сессия не будет потеряна.
А какая ценность у этой сессии? я хотел обратить внимание на то, что при ее разрыве и скорой установки новой, соединения внутри туннеля при надлежащих параметрах не разорвуться.

Ответить | Правка | Наверх | Cообщить модератору

100. "Увидел свет OpenVPN 2.4.0" –1 +/–

Сообщение от J.L. (?), 29-Дек-16, 16:50

>>  сессия не будет потеряна.
> А какая ценность у этой сессии? я хотел обратить внимание на то,
> что при ее разрыве и скорой установки новой, соединения внутри туннеля
> при надлежащих параметрах не разорвуться.
а какие надлежащие параметры и требуют ли они установки с обоих сторон соединения внутри туннеля - и на клиенте (подконтрольном) и на сервере (неподконтрольном)
(частенько рвётся впн и приходится клиентскую подтуннельную программу переподключать)
и стоит ли мне задуматься над схемой "виртуальноеEth -> впнEth1+впнEth2(на разные сервера целевой подсети) -> целевой_сервер" ? (и как такое вообще делать?)

Ответить | Правка | Наверх | Cообщить модератору

104. "Увидел свет OpenVPN 2.4.0" +/–

Сообщение от cmp (ok), 30-Дек-16, 00:38

Как любил говорить один не_товарищь - открытия требую экспериментов.
> виртуальноеEth -> впнEth1+впнEth2(на разные сервера целевой подсети) -> целевой_сервер
Вообще не понял ничего, не благодарное дело гадать, но в большенстве случаев на сервера ходят или за сервисами или для управления, сервисы лучше предоставлять через единую точку входа, где их можно будет прикрыть фаерволом ежели чего, управления на серверах, вроде и так не плохо защищено, смысла его туннелировать нет, это я о ssh говорю, как там оно в виндах и макосях беспонятия.

Ответить | Правка | Наверх | Cообщить модератору

109. "Увидел свет OpenVPN 2.4.0" +/–

Сообщение от zanswer CCNA RS (?), 30-Дек-16, 06:27

macOS не чем принципиально от любого другого Unix в этом отличаться не будет, такой же SSH и TLS.
Windows, по крайней мере в свежих реинкарнациях охотно использует TLS (WS-Management Protocol), возможно и SSH можно использовать, поинтересуюсь у коллег.

Ответить | Правка | Наверх | Cообщить модератору

101. "Увидел свет OpenVPN 2.4.0" +/–

Сообщение от zanswer (?), 29-Дек-16, 17:29

У меня конечно же нет ответа, который устроит всех, но давайте представим следующий кейс, у нас есть стандартная, я бы сказал обыденная топология Hub-and-Spoke. В центральном офисе у нас CallManager, в филиалах IP телефон. Руководство ставит задачу, чтобы не пре каких обстоятельствах аудио конференции не прерывались.
Не знаю, как дела обстоят с процедурой установления туннеля у OpenVPN, не изучал данный протокол, но в случае GRE over IPSec, в классическом DMVPN к примеру, важно помнить, что при разрыве сессии, нужно будет пройти IPSec Phase 1, IPSec Phase 2, затем создание GRE туннеля, регистрацию на NHRP NHS сервере, иначе наш Hub не будет знать о том, какое соотношение у нас между VPN IP и tunnel IP. Затем нужно установить отношения соседства в OSPF/EIGRP и только после этого можно будет обмениваться пакетами!
То есть иными словами, для чувствительного к задержкам и потерям трафика это может быть определённой проблемой.
Само-собой, что вы можете резонно заметить, что при таких вводных, можно построить два туннеля, через разные аплинки с Hub, поднять внутри EIGRP и указать, что один из туннелей у нас имеет большую метрику чем другой, при этом же ничто не мешает ему быть feasible successor. В таком случае время переключения будет равно в худшем случае hold time, которое можно всегда изменить на нужное нам.
Но топологии и конфигурации бывают разные, да и учесть все детали каждого кейса сложно в абстрактном сообщении.
P/S/ Я не претендую этим сообщением на всеобъемлющее исследование или истину в последней инстанции, просто изложил свои мысли.

Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

105. "Увидел свет OpenVPN 2.4.0" +/–

Сообщение от cmp (ok), 30-Дек-16, 01:19

> Руководство ставит задачу
Это какбы его работа, которая выполняется ровно на столько, на сколько выделятся ресурсов.
Всегда конечно можно чего-то сколхозить и часто это даже работает, но самопал есть самопал.
> GRE over IPSec, в классическом
Ну для кого как. Последнее время "модно" филиалы подключать через микротики, там опенвпн и гре, и много всякого, и по сути обеспечивается л2 с резервом или без, в зависимости от готовности платить. У цисок есть решения для такой задачи. У операторов есть решение, л2 из москвы на чутотку легко, но стоить будет много.
> учесть все детали каждого кейса сложно в абстрактном сообщении
Подключение филиалов вполне типовая задача.
> установить отношения соседства в OSPF/EIGRP
А вот это уже задача транспортного подразделения, которое либо организовывает и поддерживает л2 для вашего ip, либо выгоняется на мороз, а на эти деньги покупается л2 у провайдера с резервированием, допустимыми потерями и прочим, что оговоренно в договоре, на клинтских концах ставятся деморкаторы и наступает счастье.

Ответить | Правка | Наверх | Cообщить модератору

107. "Увидел свет OpenVPN 2.4.0" –1 +/–

Сообщение от zanswer CCNA RS (?), 30-Дек-16, 05:42

MPLS L2 VPN через всю страну, это очень дорогое удовольствие в каждый филиал, его ещё нужно чем-то обосновать.
Нечего против Mikrotik не имею, они дёшевы, умеют достаточно много, пусть и с оговорками во многих аспектах.
Что касается поддержания L2, то я снова не совсем вас понимаю, что вы имеете ввиду? 2 Data-Link Layer, исключая решения MPLS L2 VPN, поддерживать в рамках всего канала между Hub и Spoke, совершенно не возможно, поскольку он закончится на точке демаркации оператора.
Объясните, как вы видите работу транспортного отдела? Что он должен обеспечить мне, как сетевому инженеру, чтобы отношения соседства EIGRP/OSPF между Hub и Spoke не нарушались?
P/S/ Вообще не вижу причин, для того, чтобы строить именно L2 VPN между филиалами всегда, кроме нескольких специальных кейсов.

Ответить | Правка | Наверх | Cообщить модератору

110. "Увидел свет OpenVPN 2.4.0" +/–

Сообщение от cmp (ok), 30-Дек-16, 07:11

> кроме нескольких специальных кейсов.
Согласен, но в большенстве случаев перед ИТ клиентов л2впн стоят другие задачи, и связность филиалов отдается на "аутсорсинг оператору", если клиентскому специалисту интересно, то он занимается и хотябы между соседними точками, которые в прямой видимости находятся вайфайки вешает, если нет, то нет.
> Объясните, как вы видите работу транспортного отдела?
Транспортники обеспечивают транспорт, резервирование каналов и надлежащую ширину, все остальные подстраиваются под них, если у транспортников канал спутниковый, и узкий и дорогой, то настрайка приоритезации трафика в нем уже не их головная боль. А ОСПФ их, и дать вам подсеть и шлюз в федеральную корп сеть их задача.
> Что он должен обеспечить мне, как сетевому инженеру, чтобы отношения соседства EIGRP/OSPF между Hub и Spoke не нарушались
Обеспечить транспорт, л3 как минимум который не рвется при разрыве магистральных каналов отдельных операторов или последней мили, то есть его зона ответственности от его железки в филиале до его железки в другом филиале, ваша от кресла директора до железки транспортника, и вашего коллеги от кресла его директора до железки траспортника в другом филиале, если разные города, если один, то вы и ваш коллега можете быть одним лицом, если филиалов много и во многих городах, то транспортники соответственно тоже делять на местных и федеральных.
> что вы имеете ввиду? 2 Data-Link Layer
Хотелось бы ответить ethernet, но далеко не всегда он чист, периодиски приходится сталкиваться с проблемами, когда ethernet оказывается не ethernet и вланы через него ходят и даже q-in-q ходит, а какой-нибудь bpdu уже нет.  И если на каких-нибудь хуавеях уровня backhaul это решается легко, то всякие релейки сляпаны кто как, там с вланами траблы, а о плюшках и речи нет. Поэтому л2 это траспорт для л3, чтобы там можно было использовать любую адресацию ip4, или ip6 или, прости господи ipx. Так, что в большенстве случаев это просто влан, а вот если клиент хочет, то отдельно в договоре пишет свои хотелки.
Кстате, отрганизовать л2 оператору проще, чем л3, так как не надо вбивать ip шлюзов и городить л3 инстанции, чтобы изолироваться, влан прописал и забыл.

Ответить | Правка | Наверх | Cообщить модератору

111. "Увидел свет OpenVPN 2.4.0" +/–

Сообщение от zanswer CCNA RS (?), 30-Дек-16, 07:31

Вы всё время замыкаетесь на L2 VPN, к тому же операторский, что не всегда возможно по разным причинам. Представьте, что у вас нет возможности получить MPLS L2 VPN через вашего оператора. Но, у вас есть два оператора, в каждом филиале и центральном офисе, филиалы представлены не только офисами в вашей стране, но и за её пределами или же, внутри страны но с трудно доступных точках. Поэтому мы вынуждены самостоятельно строить нашу VPN сеть, без прямого участия оператора, он просто продаёт нам услуга доступа к сети Internet, всё.
Я понял, почему мы долго с вами так уже ведём беседу и ещё не пришли к одному знаменателю, я смотрю с позиции инженера транспортной службы по вашей классификации, а вы инженера внутренней службы отвечающей за сеть внутри.
Что касается 2 Data-Link Layer, то в случае L2 VPN он само-собой легко различим, как пример QinQ конфигурация. Но, что если у нас OpenVPN TUN или GRE over IPsec? Канальный уровень у нас закончится на точке демаркации, дальше мы уже не можем не влиять на его работу, не тем более отвечать за него.
С точки зрения оператора, конфигурация MPLS PE узла выглядит одинаково на мой взгляд, что же касается в принципе MPLS VPN, то L2 сложнее, чем L3 VPN с точки зрения теории.

Ответить | Правка | Наверх | Cообщить модератору

116. "Увидел свет OpenVPN 2.4.0" +/–

Сообщение от cmp (ok), 30-Дек-16, 09:38

> Что касается 2 Data-Link Layer, то в случае L2 VPN он само-собой
> легко различим, как пример QinQ конфигурация. Но, что если у нас
> OpenVPN TUN или GRE over IPsec? Канальный уровень у нас закончится
> на точке демаркации, дальше мы уже не можем не влиять на
> его работу, не тем более отвечать за него.
OpenVPN TUN этот который p2p , путаю их все время с TAP, если да, то почему не сделать TAP?
Собственно VPN, ИМХО, это и есть способ уйти от точек демаркации, но GRE, ИМХО, не лучшее решение.
> Я понял, почему мы долго с вами так уже ведём беседу и
> ещё не пришли к одному знаменателю, я смотрю с позиции инженера
> транспортной службы по вашей классификации, а вы инженера внутренней службы отвечающей
> за сеть внутри.
Внутри чего? А вообще, наверное, следовало бы определить смысл букв - VPN. У вас вся сеть как будто это цепочка шифрованных каналов через вражеские физические сети, я же полагаю, что у любой нормальной организации есть центральный офис или несколько, где подключение происходит проводами, которые связаны друг с другом либо своими волсами, либо л2 купленным у провайдера. И уже к той сети подключаются филиалы, по волсам, или через провайдеров, но это уже другой уровень сети, зачем там (в филиале) оспф и бгп, там должен быть мальчик эникейщик , чтобы мышку поменять, и какая-нибудь циска или микротик, чтобы раздавать интернетик и корп сеть, причем у мальчика эникейщика от циски той не должно быть ни пароля ни пачкорда с управлением, а выдаваться она дожна настроенная директору филиала под роспись.
> С точки зрения оператора, конфигурация MPLS PE узла выглядит одинаково на мой
> взгляд, что же касается в принципе MPLS VPN, то L2 сложнее,
> чем L3 VPN с точки зрения теории.
Вот не правда, с л3 в свое время голову сломали куда эти ip вешать, умники рекомендовали на ядро сети, но это во-первых, уникальные вланы на каждую точку, через все опорное кольцо волс, во-вторых, клиентские ip на ядре сети - полнейший бред. А с л2 проблем никаких, 5 строк на порт с указанием точки выхода - любой город.

Ответить | Правка | Наверх | Cообщить модератору

119. "Увидел свет OpenVPN 2.4.0" +/–

Сообщение от zanswer CCNA RS (?), 30-Дек-16, 10:30

Выбор типа VPN, L2/L3 лежит в плоскости требований вашей сети, обычно L2 VPN используют с целью передачи не IP трафика, в иных случаях использование L2 VPN лишь увеличивает накладные расходы и не даёт не каких преимуществ.
Я не знаю, где вы работаете, поэтому я отталкиваюсь от вашей терминологии. Вот смотрите, давайте лучше отталкиваться от какой-то архитектуры сети, например Cisco Enterprise Architecture. У нас есть функциональные блоки, у которых чётко определены роли в сети, Enterprise Campus, включает классическую трёх уровневую иерархическую сеть. Enterprise Edge включает в себя модули обеспечивающие связь между Enterprise Campus и другими блоками корпоративной сети. Далее, идёт Service Provider Edge, он может быть представлен чем угодно, FrameRelay, ATM, MetroEthernet, PSTN, MPLS. Через данный блок подключен блок Remote. Куда входят уже наши филиалы, удалённые сотрудники, мобильные сотрудники и так далее.
Внутри блока Enterprise Campus у нас могут быть свои волокна к примеру, почему бы и нет. Но филлилы подключаются к Enterprise Campus через Enterprise Edge, который в свою очередь связан с Service Provider Edge по не контролируемым каналам. И именно от Enterprise Edge до Remote мы и строим нашу Virtual Private Network, которая использует в качестве основы имеющиеся сети операторов.
Поскольку количество филиалов может быть не детерминированным, а обмен между информацией между ними по каким либо причинам требуется, при этом прохождение трафика через Enterprise Edge нам не выгодно, по причине высоких задержек, дорогой аренды PVC, 802.1Q Vlan и тд. Возникает резонная задача, обеспечить динамический обмен маршрутной информацией, чтобы филиалы могли выполнять обмен напрямую, минуя центральный офис.
Выбор протокола динамической маршрутизации для построения таких VPN сетей, зависит от выбранной технологии и налагаемых ею требований. Находится сетевому инженеру в каждом филиале нет не какой нужды, NOC находится в центральном офисе.
Мне сложно судить о том, какая у вас архитектура опорной сети, поэтому, ещё сложнее судить о предложения которые делали какие-то _умнники_. :)

Ответить | Правка | Наверх | Cообщить модератору

125. "Увидел свет OpenVPN 2.4.0" +/–

Сообщение от cmp (ok), 30-Дек-16, 13:06

Если у вас так, то я за вас рад. А у нас все сильно по-другому, и у остальных тоже. Мелкие и средние компании имеют большое преимущество перед крупными в этом плане.

Ответить | Правка | Наверх | Cообщить модератору

122. "Увидел свет OpenVPN 2.4.0" –1 +/–

Сообщение от zanswer (?), 30-Дек-16, 11:09

Что касается GRE, то у него компактный заголовок, он без каких либо проблем позволяет передавать мультикаст пакеты, исключая трудности с NAT, не каких проблем у него не вижу других. А уж multipoint GRE, так вообще счастье, для любого сетевого инженера.
Если вы имеете ввиду, что лучше, то это тема для долгих споров, интернет ими и так полон. :)

Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

123. "Увидел свет OpenVPN 2.4.0" –1 +/–

Сообщение от zanswer CCNA RS (?), 30-Дек-16, 11:23

Странно, при размещении сообщения куда-то OpenVPN потерялся. Я имел ввиду, что OpenVPN vs L2TP vs GRE vs SSTP и так далее, это длинный спор с множеством возможных ситуаций, где лучше один, а где другой ИМХО. :)

Ответить | Правка | Наверх | Cообщить модератору

108. "Увидел свет OpenVPN 2.4.0" –1 +/–

Сообщение от zanswer (?), 30-Дек-16, 06:19

Поясню насчёт кейсов, что я имел ввиду.
Первый кейс, классическая топология Hub-and-Spoke, 1 Hub, 10 Spoke, статические point-to-point линки между Hub и Spoke, весь трафик течёт через Hub между Spoke.
Второй кейс, классическая топология Hub-and-Spoke, 1 Hub, 100 Spoke, динамические point-to-multipoint линки между Hub и Spoke, весь трафик течёт через Hub между Spoke.
Третий кейс, классическая топология Hub-and-Spoke, 1 Hub, 100 Spoke, динамические point-to-multipoint линки между Hub и Spoke, Spoke и Spoke, трафик течёт согласно маршрутам в RIB, получаемых в объявлениях маршрутизации от Hub.
Четвёртый кейс, классическая топология Hub-and-Spoke, 4 Hub, 1000 Spoke, динамические point-to-multipoint линки между Hub и Hub, Hub и Spoke, Spoke и Spoke, трафик течёт согласно маршрутам в RIB, получаемых в объявлениях маршрутизации от Hubs.
И это я в рамках L3 VPN только четыре достаточно очевидных кейса описал, которые очень красиво решаются через DMVPN = IPsec + mGRE + NHRP + EIGRP/OSPF/BGP.
Поэтому я выше и написал, что учесть в абстрактном сообщение все возможные кейсы просто не возможно, у всех разные задачи, бюджеты, технические возможности, требования безопасности и тд.
P/S/ Не претендую на полноту изложения всех возможных сценариев построения VPN сетей в этом сообщении, открыт для любых обсуждений.

Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

112. "Увидел свет OpenVPN 2.4.0" +/–

Сообщение от cmp (ok), 30-Дек-16, 07:55

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

Ответить | Правка | Наверх | Cообщить модератору

113. "Увидел свет OpenVPN 2.4.0" –1 +/–

Сообщение от zanswer CCNA RS (?), 30-Дек-16, 08:04

Под требованиями безопасности я понимаю, не только обеспечение конфиденциальности, целостности и аутентичности передаваемых данных через VPN линк. А такие аспекты, как противодействие утечкам конфиденциальных данных, например путём анализа всего трафика филиалов на Intrusion Prevention System устройствах, для выявления заданных паттернов, свидетельствующих об утечках определённых данных к примеру.
К провайдеру ходить совершенно не зачем, IPsec, OpenVPN или любой другой не объявленный устаревшим протокол, обеспечивает все три базовых элемента, конфиденциальность, целостность, аутентичность передаваемой информации, при должном внимание при их настройке конечно.
Информационная безопасность же, распространяется не только на такие аспекты, есть ещё масса других организационно правовых норм, которые могут налагать определённые требования на построение сети.

Ответить | Правка | Наверх | Cообщить модератору

114. "Увидел свет OpenVPN 2.4.0" –1 +/–

Сообщение от zanswer CCNA RS (?), 30-Дек-16, 08:07

В общем и целом, проблема защиты от утечек конфиденциальной информации или атак совершаемых изнутри компании, является не менее актуальной, чем защита передаваемых данных через не подконтрольные каналы передачи данных, как например предоставляемый оператором нам 802.1Q Vlan или целый 802.1ad QinQ trunk.

Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

59. "Увидел свет OpenVPN 2.4.0" +/–

Сообщение от бугага (?), 28-Дек-16, 18:10

> Вот это мне кажется очень мощная фича. Такое только в OpenVPN есть, или где-то еще?
ipsec mobike https://tools.ietf.org/html/rfc4555

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

15. "Увидел свет OpenVPN 2.4.0"	+8 +/–
Сообщение от VPN это сила (?), 28-Дек-16, 12:33
> Добавлена возможность бесшовной смены IP-адреса и номера сетевого порта клиента без разрыва соединения VPN. Вот это мне кажется очень мощная фича. Такое только в OpenVPN есть, или где-то еще?
Ответить \| Правка \| Наверх \| Cообщить модератору


	25. "Увидел свет OpenVPN 2.4.0"	–1 +/–
	Сообщение от Меломан1 (?), 28-Дек-16, 13:32
	Не совсем понимаю в каких случаях это может пригодиться?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	35. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от Аноним (-), 28-Дек-16, 14:23
	GPRS
	Ответить \| Правка \| Наверх \| Cообщить модератору


	37. "Увидел свет OpenVPN 2.4.0"	–2 +/–
	Сообщение от Меломан1 (?), 28-Дек-16, 14:51
	Не актуально. Прокачиваться будет не более 33.6кбит/c. даже заголовки сообщений будут с трудом просачиваться на таком соединении.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	43. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от Клыкастый (ok), 28-Дек-16, 15:51
	> Прокачиваться будет не более 33.6кбит/c на IRC хватит
	Ответить \| Правка \| Наверх \| Cообщить модератору


	47. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от Аноним (-), 28-Дек-16, 16:29
	Например, чтобы не палиться перед ISP, постоянно переподключая VPN-соединение для смены IP.
	Ответить \| Правка \| К родителю #25 \| Наверх \| Cообщить модератору


	106. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от Аноним (-), 30-Дек-16, 02:58
	Multi-Wan вариации(всех типов) и Multipath-TCP использование. в Ad-Hoc/Mesh сетях тоже обычное дело(а там и оборонные и помышленные среди них есть а не только меш потато и вские гипербореи).
	Ответить \| Правка \| К родителю #25 \| Наверх \| Cообщить модератору


	115. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от zanswer CCNA RS (?), 30-Дек-16, 08:52
	Вот авторы RFC4555 Mobility and Multihoming Protocol (MOBIKE), дают исчерпывающий ответ, зачем это может понадобиться. There are scenarios where these IP addresses might change. One example is mobility: a host changes its point of network attachment and receives a new IP address. Another example is a multihoming host that would like to change to a different interface if, for instance, the currently used interface stops working for some reason. The main scenario for MOBIKE is enabling a remote access VPN user to move from one address to another without re-establishing all security associations with the VPN gateway. For instance, a user could start from fixed Ethernet in the office and then disconnect the laptop and move to the office's wireless LAN. When the user leaves the office, the laptop could start using General Packet Radio Service (GPRS); when the user arrives home, the laptop could switch to the home wireless LAN. MOBIKE updates only the outer (tunnel header) addresses of IPsec SAs, and the addresses and other traffic selectors used inside the tunnel stay unchanged. Thus, mobility can be (mostly) invisible to applications and their connections using the VPN. Протоколы разные, но принцип схожий, что IPsec, что OpenVPN, должны сначала выполнить согласование ряда параметров, как то алгоритмы шифрования, хеширования, выполнить аутентификацию, согласовать общий ключ для симметричных алгоритмов шифрования и HMAC функций и тд. Всё это требует времени, вычислительных ресурсов и может привести к потерям сегментов/датаграм, что в зависимости от типа приложений может быть, как критично для QoE, так и нет. То есть посторонние шумы или обрыв VoIP звонка, это плохо, снижение скорости закачки файла на короткий промежуток времени нет.
	Ответить \| Правка \| К родителю #25 \| Наверх \| Cообщить модератору


	135. "Увидел свет OpenVPN 2.4.0"	–1 +/–
	Сообщение от Аноним (-), 03-Янв-17, 00:30
	> Не совсем понимаю в каких случаях это может пригодиться? В любых когда соединение нестабильное. Например беспроводка. Не круто, понимаешь, если все дружно отлипает только на том основании что реконект случился.
	Ответить \| Правка \| К родителю #25 \| Наверх \| Cообщить модератору


	29. "Увидел свет OpenVPN 2.4.0"	–3 +/–
	Сообщение от cmp (ok), 28-Дек-16, 13:38
	> Вот это мне кажется очень мощная фича. Такое только в OpenVPN есть, > или где-то еще? Чет не очень понимаю зачем, давеча поставил фалег лится на ноут с хранилища, смотрю скорость бе, воткнул провод, 1 строкой в shell перевесил ip на ethernet и ни ssh не порвалось, ни закачка. Хотя чисто из академического интереса можно запихивать vpn-интерфейсы в мост с stp, но при сходимость кольца все равно потеряет данные, IP всегда теряет данные, он байдизайн ширину канала по потерям расчитывает, так-то.
	Ответить \| Правка \| К родителю #15 \| Наверх \| Cообщить модератору


	31. "Увидел свет OpenVPN 2.4.0"	–1 +/–
	Сообщение от Меломан1 (?), 28-Дек-16, 14:03
	Ни хера не понял в твоих манипуляциях. Подробности, пожалуйста.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	36. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от Аноним (-), 28-Дек-16, 14:48
	Это явно юный админ локалхоста говорит фразы продолжения которых не знает.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	77. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok), 29-Дек-16, 03:30
	brctl addif br0 tun0 че непонятного
	Ответить \| Правка \| К родителю #31 \| Наверх \| Cообщить модератору


	42. "Увидел свет OpenVPN 2.4.0"	–1 +/–
	Сообщение от Аноним (-), 28-Дек-16, 15:18
	>> Добавлена возможность бесшовной смены IP-адреса и номера сетевого порта клиента без разрыва соединения VPN. > перевесил ip на ethernet и ни ssh не порвалось, ни закачка. В новости говорится что можно сменить IP или/и порт и соединение не прервётся. Я правильно понял что ты не менял ни IP ни порт и говоришь "У меня и так работает"?
	Ответить \| Правка \| К родителю #29 \| Наверх \| Cообщить модератору


	44. "Увидел свет OpenVPN 2.4.0"	+1 +/–
	Сообщение от Клыкастый (ok), 28-Дек-16, 15:53
	> Я правильно понял что ты не менял ни IP ни порт и говоришь "У меня и так работает"? ты всё правильно понял, а гражданин суммирует часы и устриц.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	78. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok), 29-Дек-16, 04:18
	> ты всё правильно понял, а гражданин суммирует часы и устриц. Устрицы в голове у тебя. ядро шлет пакеты на хост до которого нет маршрута, между удалением ip с одного интерфейса и навешиванием на другой, и должно бы возвращать - но_роут_ту_хост, но не возвращает же, покрайней мере сразу, значит переустановить соединение-туннель есть время, а уж ip и порт нового значения не имеют, при правильно отстроенных буфферах и таймаутах соединения в туннеле даже не поймут, что что-то произошло.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	88. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от zanswer (?), 29-Дек-16, 13:05
	IP рассчитывает ширину канала по потерям? Можете подробнее изложить свою мысль, что вы имеете ввиду? Для каких целей IP протоколу, который является stetaless протоколом, потребовалось рассчитывать ширину канала, да ещё и по потерям. Может быть вы имели ввиду TCP?
	Ответить \| Правка \| К родителю #29 \| Наверх \| Cообщить модератору


	97. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok), 29-Дек-16, 16:10
	> Может быть вы имели ввиду TCP? Определенно, но хотел включить UDP в множество, хотя зря, так как особенности реализации отдельного кое-чего на udp к делу отношения не имеют.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	89. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от zanswer (?), 29-Дек-16, 13:10
	Речь я так понимаю идёт о том, что OpenVPN теперь может динамически в рамках одной сессии, менять tunnel source, что в прошлом приводило к разрыву сессии. Вы же я так понимаю tunnel source не меняли, а изменили только его положение (перенесли на другой интерфейс). Поэтому да, tunnel destiantion не заметил подмены, как вы сами правильно заметили при правильных размерах буфера и dead interval, сессия не будет потеряна.
	Ответить \| Правка \| К родителю #29 \| Наверх \| Cообщить модератору


	99. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok), 29-Дек-16, 16:17
	> сессия не будет потеряна. А какая ценность у этой сессии? я хотел обратить внимание на то, что при ее разрыве и скорой установки новой, соединения внутри туннеля при надлежащих параметрах не разорвуться.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	100. "Увидел свет OpenVPN 2.4.0"	–1 +/–
	Сообщение от J.L. (?), 29-Дек-16, 16:50
	>> сессия не будет потеряна. > А какая ценность у этой сессии? я хотел обратить внимание на то, > что при ее разрыве и скорой установки новой, соединения внутри туннеля > при надлежащих параметрах не разорвуться. а какие надлежащие параметры и требуют ли они установки с обоих сторон соединения внутри туннеля - и на клиенте (подконтрольном) и на сервере (неподконтрольном) (частенько рвётся впн и приходится клиентскую подтуннельную программу переподключать) и стоит ли мне задуматься над схемой "виртуальноеEth -> впнEth1+впнEth2(на разные сервера целевой подсети) -> целевой_сервер" ? (и как такое вообще делать?)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	104. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok), 30-Дек-16, 00:38
	Как любил говорить один не_товарищь - открытия требую экспериментов. > виртуальноеEth -> впнEth1+впнEth2(на разные сервера целевой подсети) -> целевой_сервер Вообще не понял ничего, не благодарное дело гадать, но в большенстве случаев на сервера ходят или за сервисами или для управления, сервисы лучше предоставлять через единую точку входа, где их можно будет прикрыть фаерволом ежели чего, управления на серверах, вроде и так не плохо защищено, смысла его туннелировать нет, это я о ssh говорю, как там оно в виндах и макосях беспонятия.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	109. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от zanswer CCNA RS (?), 30-Дек-16, 06:27
	macOS не чем принципиально от любого другого Unix в этом отличаться не будет, такой же SSH и TLS. Windows, по крайней мере в свежих реинкарнациях охотно использует TLS (WS-Management Protocol), возможно и SSH можно использовать, поинтересуюсь у коллег.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	101. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от zanswer (?), 29-Дек-16, 17:29
	У меня конечно же нет ответа, который устроит всех, но давайте представим следующий кейс, у нас есть стандартная, я бы сказал обыденная топология Hub-and-Spoke. В центральном офисе у нас CallManager, в филиалах IP телефон. Руководство ставит задачу, чтобы не пре каких обстоятельствах аудио конференции не прерывались. Не знаю, как дела обстоят с процедурой установления туннеля у OpenVPN, не изучал данный протокол, но в случае GRE over IPSec, в классическом DMVPN к примеру, важно помнить, что при разрыве сессии, нужно будет пройти IPSec Phase 1, IPSec Phase 2, затем создание GRE туннеля, регистрацию на NHRP NHS сервере, иначе наш Hub не будет знать о том, какое соотношение у нас между VPN IP и tunnel IP. Затем нужно установить отношения соседства в OSPF/EIGRP и только после этого можно будет обмениваться пакетами! То есть иными словами, для чувствительного к задержкам и потерям трафика это может быть определённой проблемой. Само-собой, что вы можете резонно заметить, что при таких вводных, можно построить два туннеля, через разные аплинки с Hub, поднять внутри EIGRP и указать, что один из туннелей у нас имеет большую метрику чем другой, при этом же ничто не мешает ему быть feasible successor. В таком случае время переключения будет равно в худшем случае hold time, которое можно всегда изменить на нужное нам. Но топологии и конфигурации бывают разные, да и учесть все детали каждого кейса сложно в абстрактном сообщении. P/S/ Я не претендую этим сообщением на всеобъемлющее исследование или истину в последней инстанции, просто изложил свои мысли.
	Ответить \| Правка \| К родителю #99 \| Наверх \| Cообщить модератору


	105. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok), 30-Дек-16, 01:19
	> Руководство ставит задачу Это какбы его работа, которая выполняется ровно на столько, на сколько выделятся ресурсов. Всегда конечно можно чего-то сколхозить и часто это даже работает, но самопал есть самопал. > GRE over IPSec, в классическом Ну для кого как. Последнее время "модно" филиалы подключать через микротики, там опенвпн и гре, и много всякого, и по сути обеспечивается л2 с резервом или без, в зависимости от готовности платить. У цисок есть решения для такой задачи. У операторов есть решение, л2 из москвы на чутотку легко, но стоить будет много. > учесть все детали каждого кейса сложно в абстрактном сообщении Подключение филиалов вполне типовая задача. > установить отношения соседства в OSPF/EIGRP А вот это уже задача транспортного подразделения, которое либо организовывает и поддерживает л2 для вашего ip, либо выгоняется на мороз, а на эти деньги покупается л2 у провайдера с резервированием, допустимыми потерями и прочим, что оговоренно в договоре, на клинтских концах ставятся деморкаторы и наступает счастье.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	107. "Увидел свет OpenVPN 2.4.0"	–1 +/–
	Сообщение от zanswer CCNA RS (?), 30-Дек-16, 05:42
	MPLS L2 VPN через всю страну, это очень дорогое удовольствие в каждый филиал, его ещё нужно чем-то обосновать. Нечего против Mikrotik не имею, они дёшевы, умеют достаточно много, пусть и с оговорками во многих аспектах. Что касается поддержания L2, то я снова не совсем вас понимаю, что вы имеете ввиду? 2 Data-Link Layer, исключая решения MPLS L2 VPN, поддерживать в рамках всего канала между Hub и Spoke, совершенно не возможно, поскольку он закончится на точке демаркации оператора. Объясните, как вы видите работу транспортного отдела? Что он должен обеспечить мне, как сетевому инженеру, чтобы отношения соседства EIGRP/OSPF между Hub и Spoke не нарушались? P/S/ Вообще не вижу причин, для того, чтобы строить именно L2 VPN между филиалами всегда, кроме нескольких специальных кейсов.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	110. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok), 30-Дек-16, 07:11
	> кроме нескольких специальных кейсов. Согласен, но в большенстве случаев перед ИТ клиентов л2впн стоят другие задачи, и связность филиалов отдается на "аутсорсинг оператору", если клиентскому специалисту интересно, то он занимается и хотябы между соседними точками, которые в прямой видимости находятся вайфайки вешает, если нет, то нет. > Объясните, как вы видите работу транспортного отдела? Транспортники обеспечивают транспорт, резервирование каналов и надлежащую ширину, все остальные подстраиваются под них, если у транспортников канал спутниковый, и узкий и дорогой, то настрайка приоритезации трафика в нем уже не их головная боль. А ОСПФ их, и дать вам подсеть и шлюз в федеральную корп сеть их задача. > Что он должен обеспечить мне, как сетевому инженеру, чтобы отношения соседства EIGRP/OSPF между Hub и Spoke не нарушались Обеспечить транспорт, л3 как минимум который не рвется при разрыве магистральных каналов отдельных операторов или последней мили, то есть его зона ответственности от его железки в филиале до его железки в другом филиале, ваша от кресла директора до железки транспортника, и вашего коллеги от кресла его директора до железки траспортника в другом филиале, если разные города, если один, то вы и ваш коллега можете быть одним лицом, если филиалов много и во многих городах, то транспортники соответственно тоже делять на местных и федеральных. > что вы имеете ввиду? 2 Data-Link Layer Хотелось бы ответить ethernet, но далеко не всегда он чист, периодиски приходится сталкиваться с проблемами, когда ethernet оказывается не ethernet и вланы через него ходят и даже q-in-q ходит, а какой-нибудь bpdu уже нет. И если на каких-нибудь хуавеях уровня backhaul это решается легко, то всякие релейки сляпаны кто как, там с вланами траблы, а о плюшках и речи нет. Поэтому л2 это траспорт для л3, чтобы там можно было использовать любую адресацию ip4, или ip6 или, прости господи ipx. Так, что в большенстве случаев это просто влан, а вот если клиент хочет, то отдельно в договоре пишет свои хотелки. Кстате, отрганизовать л2 оператору проще, чем л3, так как не надо вбивать ip шлюзов и городить л3 инстанции, чтобы изолироваться, влан прописал и забыл.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	111. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от zanswer CCNA RS (?), 30-Дек-16, 07:31
	Вы всё время замыкаетесь на L2 VPN, к тому же операторский, что не всегда возможно по разным причинам. Представьте, что у вас нет возможности получить MPLS L2 VPN через вашего оператора. Но, у вас есть два оператора, в каждом филиале и центральном офисе, филиалы представлены не только офисами в вашей стране, но и за её пределами или же, внутри страны но с трудно доступных точках. Поэтому мы вынуждены самостоятельно строить нашу VPN сеть, без прямого участия оператора, он просто продаёт нам услуга доступа к сети Internet, всё. Я понял, почему мы долго с вами так уже ведём беседу и ещё не пришли к одному знаменателю, я смотрю с позиции инженера транспортной службы по вашей классификации, а вы инженера внутренней службы отвечающей за сеть внутри. Что касается 2 Data-Link Layer, то в случае L2 VPN он само-собой легко различим, как пример QinQ конфигурация. Но, что если у нас OpenVPN TUN или GRE over IPsec? Канальный уровень у нас закончится на точке демаркации, дальше мы уже не можем не влиять на его работу, не тем более отвечать за него. С точки зрения оператора, конфигурация MPLS PE узла выглядит одинаково на мой взгляд, что же касается в принципе MPLS VPN, то L2 сложнее, чем L3 VPN с точки зрения теории.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	116. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от cmp (ok), 30-Дек-16, 09:38
	> Что касается 2 Data-Link Layer, то в случае L2 VPN он само-собой > легко различим, как пример QinQ конфигурация. Но, что если у нас > OpenVPN TUN или GRE over IPsec? Канальный уровень у нас закончится > на точке демаркации, дальше мы уже не можем не влиять на > его работу, не тем более отвечать за него. OpenVPN TUN этот который p2p , путаю их все время с TAP, если да, то почему не сделать TAP? Собственно VPN, ИМХО, это и есть способ уйти от точек демаркации, но GRE, ИМХО, не лучшее решение. > Я понял, почему мы долго с вами так уже ведём беседу и > ещё не пришли к одному знаменателю, я смотрю с позиции инженера > транспортной службы по вашей классификации, а вы инженера внутренней службы отвечающей > за сеть внутри. Внутри чего? А вообще, наверное, следовало бы определить смысл букв - VPN. У вас вся сеть как будто это цепочка шифрованных каналов через вражеские физические сети, я же полагаю, что у любой нормальной организации есть центральный офис или несколько, где подключение происходит проводами, которые связаны друг с другом либо своими волсами, либо л2 купленным у провайдера. И уже к той сети подключаются филиалы, по волсам, или через провайдеров, но это уже другой уровень сети, зачем там (в филиале) оспф и бгп, там должен быть мальчик эникейщик , чтобы мышку поменять, и какая-нибудь циска или микротик, чтобы раздавать интернетик и корп сеть, причем у мальчика эникейщика от циски той не должно быть ни пароля ни пачкорда с управлением, а выдаваться она дожна настроенная директору филиала под роспись. > С точки зрения оператора, конфигурация MPLS PE узла выглядит одинаково на мой > взгляд, что же касается в принципе MPLS VPN, то L2 сложнее, > чем L3 VPN с точки зрения теории. Вот не правда, с л3 в свое время голову сломали куда эти ip вешать, умники рекомендовали на ядро сети, но это во-первых, уникальные вланы на каждую точку, через все опорное кольцо волс, во-вторых, клиентские ip на ядре сети - полнейший бред. А с л2 проблем никаких, 5 строк на порт с указанием точки выхода - любой город.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	119. "Увидел свет OpenVPN 2.4.0"	+/–
	Сообщение от zanswer CCNA RS (?), 30-Дек-16, 10:30
	Выбор типа VPN, L2/L3 лежит в плоскости требований вашей сети, обычно L2 VPN используют с целью передачи не IP трафика, в иных случаях использование L2 VPN лишь увеличивает накладные расходы и не даёт не каких преимуществ. Я не знаю, где вы работаете, поэтому я отталкиваюсь от вашей терминологии. Вот смотрите, давайте лучше отталкиваться от какой-то архитектуры сети, например Cisco Enterprise Architecture. У нас есть функциональные блоки, у которых чётко определены роли в сети, Enterprise Campus, включает классическую трёх уровневую иерархическую сеть. Enterprise Edge включает в себя модули обеспечивающие связь между Enterprise Campus и другими блоками корпоративной сети. Далее, идёт Service Provider Edge, он может быть представлен чем угодно, FrameRelay, ATM, MetroEthernet, PSTN, MPLS. Через данный блок подключен блок Remote. Куда входят уже наши филиалы, удалённые сотрудники, мобильные сотрудники и так далее. Внутри блока Enterprise Campus у нас могут быть свои волокна к примеру, почему бы и нет. Но филлилы подключаются к Enterprise Campus через Enterprise Edge, который в свою очередь связан с Service Provider Edge по не контролируемым каналам. И именно от Enterprise Edge до Remote мы и строим нашу Virtual Private Network, которая использует в качестве основы имеющиеся сети операторов. Поскольку количество филиалов может быть не детерминированным, а обмен между информацией между ними по каким либо причинам требуется, при этом прохождение трафика через Enterprise Edge нам не выгодно, по причине высоких задержек, дорогой аренды PVC, 802.1Q Vlan и тд. Возникает резонная задача, обеспечить динамический обмен маршрутной информацией, чтобы филиалы могли выполнять обмен напрямую, минуя центральный офис. Выбор протокола динамической маршрутизации для построения таких VPN сетей, зависит от выбранной технологии и налагаемых ею требований. Находится сетевому инженеру в каждом филиале нет не какой нужды, NOC находится в центральном офисе. Мне сложно судить о том, какая у вас архитектура опорной сети, поэтому, ещё сложнее судить о предложения которые делали какие-то _умнники_. :)
	Ответить \| Правка \| Наверх \| Cообщить модератору