Гибкость veth на порядки выше, venet — скомммутировать в пределах нескольких ДЦ — задача почти нереализуемая.
Неудачная попытка апеллировать к отказоустойчивости на уровне ДЦ, вылившаяся полным бредом. С коммутацией venet в разных ДЦ нет никаких проблем, уважаемый.
По поводу openvz.org/Differences_between_venet_and_veth я не уверен, что указанные там fast и fastest имеют отношение к реальному положению вещей.
То есть документации верить не стоит, а вот Вашему авторитетному мнению поверить стоит.
Отключение трекинга — решение очень спорное. Оно растет из крайне высокой сложности «честной» изоляции коннтрекинга.
Это не отключает conntrack в самих контейнерах.
Мало того, трекинг соединений нужен довольно приличному количеству людей и нередко народ откатывают эту конфигурацию и возвращает трекинг со всеми его деградациями.
В свете вышесказанного видно, что вы сочиняете на ходу.
А veth тупо Ethernet устройство, которое почти в чистом виде выбрасывается во внешнюю сеть.
А это уже Ваша фантазия. Я могу Вам сказать, что вместо эмуляции L2 устройств, venet просто решает сетевой вопрос на уровне фильтров адресов и роутов.
Вместо кривых линуксовых бриджей, которые ведут себя хрен-отладишь, рекомендую попробовать OpenVSwitch, а также могу подкинуть скрипт, чтобы OpenVZ сам добавлял устройства в требуемый виртульный свич.
Оно всё равно неэквивалентно в плане безопасности и производительности venet. Спасибо, не нужно.
Почему бы ещё не писать каждые полгода таториал по установке очередной версии убунту — тоже наверняка кто-то в поиске найдёт и прочитает, и оно будет востребовано. Однако, если постоянно идти на поводу востребованности большинством, то на выходе будет ширпотреб. Я не говорю, что это плохая стратегия, но применительно к этому ресурсу она убьёт его в текущем качестве.
Нет худа без добра. Мне захотелось написать статью про роутинг на OpenVZ-хостах с сетью venet, которые имеют внутреннюю и внешнюю сеть и дают виртуалкам внутренние и внешние адреса. Официальное руководство на этот счёт только даёт рекомендацию использовать veth.
Вы, похоже, мыслите категориями домашних локалок, роутера с портом во «внутреннюю сеть» и в «интернет», потому и говорите нелепости про какой-то «проброс», называя им естественный механизм продвижения пакетов на роутерах. Статья про заурядный роутинг /32 префикса подаётся под соусом нового технологического решения.
Зашёл в комменты, рассчитывая увидеть про реализацию openvpn на mikrotik и IPSEC, и нашёл их. Не хватает только картинки про буханку и троллейбус. Статья описывает посредственное решение, продиктованное узким техническим кругозором автора.
рекомендуется использовать Unix-сокет из-за преимущества в производительности.
мифического преимущества. датаграммы проигрывают tcp из-за дропов в очереди и отсутствии бэклога принятия соединений, а тут ещё и даже вопрос не ставится об увеличении длины очереди датаграмм
Дело в том, что если не запретить маршрутизировать трафик из WAN-порта в WAN-порт, кто-нибудь из вашей WAN-сети (предположим, что провайдер садит весь подъезд в одну /24) может маршрутизировать трафик через вас, просто прописав ваш IP в качестве шлюза.
«Мы не настолько богаты, чтобы покупать дешевые вещи»
Да понятно, конечно, что во всём баланс должен быть и дешёвка может в эксплуатации обойтись дороже. Но и с другой стороны брэндовое оборудование по любому случаю закупать тоже смысла нет. Хецнер вот покупает домашнее железо под серверы и им нравится. Клиентам тоже до поры.
Для небольшой организации далеко от Москвы вполне себе решение. Идеальной техники же не бывает. Да и не факт, что дорогие системы видеонаблюдения удобно интегрируются в имеющуюся инфраструктуру.
Если контейнер L2, то деинкапсулировать на хостноде, в чём проблема
Неудачная попытка апеллировать к отказоустойчивости на уровне ДЦ, вылившаяся полным бредом. С коммутацией venet в разных ДЦ нет никаких проблем, уважаемый.
То есть документации верить не стоит, а вот Вашему авторитетному мнению поверить стоит.
Это не отключает conntrack в самих контейнерах.
В свете вышесказанного видно, что вы сочиняете на ходу.
openvz.org/Differences_between_venet_and_veth
git.openvz.org/?p=vzctl;a=commitdiff;h=a191a462579ee54b6adec9f32f44a3982379e78a
А это уже Ваша фантазия. Я могу Вам сказать, что вместо эмуляции L2 устройств, venet просто решает сетевой вопрос на уровне фильтров адресов и роутов.
Оно всё равно неэквивалентно в плане безопасности и производительности venet. Спасибо, не нужно.
Почему бы ещё не писать каждые полгода таториал по установке очередной версии убунту — тоже наверняка кто-то в поиске найдёт и прочитает, и оно будет востребовано. Однако, если постоянно идти на поводу востребованности большинством, то на выходе будет ширпотреб. Я не говорю, что это плохая стратегия, но применительно к этому ресурсу она убьёт его в текущем качестве.
Остальное — советы уровня тематических викисайтов и даже ниже
схожим образом достижимо на openvz и lxc штатными средствами
Очереди приёма соединений всё равно так и нет.
мифического преимущества. датаграммы проигрывают tcp из-за дропов в очереди и отсутствии бэклога принятия соединений, а тут ещё и даже вопрос не ставится об увеличении длины очереди датаграмм
Если не возымеет действия en.wikipedia.org/wiki/Internet_Control_Message_Protocol#Redirect
Да понятно, конечно, что во всём баланс должен быть и дешёвка может в эксплуатации обойтись дороже. Но и с другой стороны брэндовое оборудование по любому случаю закупать тоже смысла нет. Хецнер вот покупает домашнее железо под серверы и им нравится. Клиентам тоже до поры.