Отказоустойчивый ipsec vpn через multiwan
-
Вероятно тестировалось через LAN
Да, верно
Нихаха себе канал… 400 мегабит. Для чего используете такую мощь, если не секрет?
Интересно будет посмотреть что его потянет. Ждемс.Ну, на i3 начального уровня (без HV), эти скорости и были получены. Так что, не такая и мощная железка нужна)
Лично моё мнение, что такая скорость в целом не нужна, но у некоторые любят побыстрее.
Файл огромный передать моментом из одного офиса в другой или отчеты какие-то построить, где миллионы позиций у нас любят. Там очень много данных по сети гоняется.
В общем, хочешь не хочешь, а придётся исполнять. -
Igor Filth
А какова скорость передачи файла в вашей гигабитной LAN, напрямую, без OVPN на эти же тестовых компьютерах??
На скоростях 50 Мбайт/сек и выше уже могут быть немаловажны бренд\тип сетевых карт, жестких дисков и т.д.
Неплохая статья о скоростях в сети:
https://calomel.org/network_performance.html -
А какова скорость передачи файла в вашей гигабитной LAN, напрямую, без OVPN на эти же тестовых компьютерах??
90-95 Мбайт/c. Каждую сетевую "прогнал" несколько раз.
Больше 50 от меня и не просят. Получить бы 40-50 по туннелю и все были бы счастливы)
-
2 Igor Filth
Доброе.
Попробуйте ipsec. -
А если попробовать
Encryption Algorithm - None?Или вообще перейти на GRE\IPsec\L2TP?
-
Попробуйте ipsec.
:o
C этого же всё и начиналось.
Только резервирование vpn-канала неизвестно как делать, т.к. туннельный режим не поддерживает multicast, который необходим для функционирования OSPF.Через GRE точно делать не буду.
Encryption Algorithm - None?
Пробовал. Почти никак не влияет на скорость.
-
Еще раз - ссылка про высокоскоростной OVPN.
Обратите внимание, на что на скорость влияет комбинация алгоритмов шифрования и mtu.
https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux#no1
-
Развернул виртуалки на proxmox
Скорость без шифрования - 36-38 МБайт/c, с шифрованием AES-128-CBC - 31-32 МБайт/c
Нагрузка i3 ~ 80 процентов.Т.е. медленнее, чем вообще без виртуалки, но значительно быстрее, чем на Hyper-V
-
Странно, проц не на 100% что мешает раскрутиться до 98-100МБайт/сек (1gb), неужели какое железное ограничение?
-
Только резервирование vpn-канала неизвестно как делать, т.к. туннельный режим не поддерживает multicast, который необходим для
В настройках ipsec-туннеля можно выбрать tap.
-
Может быть Вы имеете в виду transport, а не tap? По-крайней мере, я tap нигде не могу найти.
Но если выбрать режим transport, то придётся ещё использовать gre или l2tp, чего мне пока не хочется.
Но, хорошо, сейчас попробую… -
Может быть Вы имеете в виду transport, а не tap? По-крайней мере, я tap нигде не могу найти.
Но если выбрать режим transport, то придётся ещё использовать gre или l2tp, чего мне пока не хочется.
Но, хорошо, сейчас попробую…Нет, есть два режима тунелирования TUN и TAP, TUN это когда два разных диапазона соединяют тунелем, а TAP это когда диапазон один сквозь тунель (LAN находится в Bridge режиме с тунелем).
-
Нет, есть два режима тунелирования TUN и TAP, TUN это когда два разных диапазона соединяют тунелем, а TAP это когда диапазон один сквозь тунель (LAN находится в Bridge режиме с тунелем).
в ovpn они так называются - tun/tap, а в ipsec уже tunnel/transport.
-
2 Igor Filth
Важно.
Если пф работает в вирт. среде, то в настр. System: Advanced: Networking поставить галки на Disable hardware checksum offload, Disable hardware TCP segmentation offload, Disable hardware large receive offload. После обязательно перезагр. пф. И протестировать скорость передачи.P.s. В настр. вирт. маш. на proxmox исп. virtio-сетевые и virtio-hdd для достижения макс. произ-ти.
-
@Bansardo:
Странно, проц не на 100% что мешает раскрутиться до 98-100МБайт/сек (1gb), неужели какое железное ограничение?
Почитайте ссылку, которую я приводил выше.
По ней тесты скоростей в сетях 1G/10G от разработчиков OVPN.
ТС, похоже, ее тоже читать не стал. -
ТС, похоже, ее тоже читать не стал.
Я её прочитал ещё до того, как спрашивать начал)))
Толку от этой статьи я получил немного, кроме понимания, что такие скорости достижимы и что они зависит как от типа шифрования, так и от mtu… + эти тесты явно были без использования KVM)
Поэтому написал сюда, чтобы получить конкретные советы и рекомендации)2 werter
Завтра выставлю эти настройки, потестирую. Спс!
-
2 werter
При выставленной галочке Disable hardware checksum offload постоянно рвётся связь c WAN даже при небольшой активности - при попытке скачать что-то с инета, или передать какой-то файл между компьютерами по туннелю.
Остальные галочки уже были выставлены по умолчанию.Уточню, что я пока опять тестирую на Hyper-V, т.к. proxmox мне "забраковали".
P.s. В настр. вирт. маш. на proxmox исп. virtio-сетевые и virtio-hdd для достижения макс. произ-ти.
На proxmox так и сделал сразу :)
-
Уточню, что я пока опять тестирую на Hyper-V, т.к. proxmox мне "забраковали".
Я обычно таким "браковщикам" предлагаю самим тогда настраивать, а то хотим много, да еще и тыкаем инженеру какими инструментами работать.
Напоминает ситуацию, "на забей гвоздь сотку, а молоток тебе на для ювелирки -
Галочка Disable hardware checksum offload оказалась невиновной в обрывах связи. Когда Hyper-V заново поставил, забыл дрова на сетевушку обновить - в этом и была причина обрывов. ::)
Но и никакого увеличения производительности от этой галочки я не получил.Сейчас, исключительно ради эксперимента, попробую поставить последний снапшот pf 2.4.
-
Поставил 2.4. Скорость без шифрования - 35-37 МБайт/c (такая же, как и на proxmox с pf 2.3.2-1), с AES-128-CBC 33-35 МБайт/c
