Jump to content

Le ecureuil

Forum Members
  • Posts

    9,559
  • Joined

  • Last visited

  • Days Won

    552

Everything posted by Le ecureuil

  1. Их и так уже можно привязать (если они имеют security-level private, то есть это "сервер") через > ip policy interface Wireguard0 <POLICY>
  2. WG - это другое. Как и OpenVPN. Когда мы говорим про VPN-серверы, всегда речь идет о шести единообразных с жестким разделением: PPTP, SSTP, L2TP/IPsec, VIP Xauth, IKEv2, OpenConnect.
  3. Начиная с 4.2.11 уже есть (правда не выведено в веб, и автоматически привязывается к Home). Команда в cli выглядит как > crypto map <NAME> virtual-ip interface <segment>
  4. Так команды и нет. Вы когда настраиваете VPN-сервер, то выбираете же сегмент для него? Вот политика этого сегмента и будет использована. Если никакой нет, то как раньше все. Настроек новых не добавилось, скорее "подровняли" под то, как изначально должно было быть.
  5. 2.16 уже никто переделывать не будет, пользуйтесь как есть.
  6. А почему сразу не поднять OpenConnect-сервеп на кинетике, и не ходить сразу в него? Если адреса серые, то через облачный режим KeenDNS.
  7. Частично уже есть - начиная с 4.2.A.11 клиенты VPN-серверов ходят в Интернет через политику, привязанную к сегменту, к которому привязан сам VPN-сервер.
  8. Скорее всего это не баг, а так задумано, что сперва нужно устройство зарегистрировать, и только потом внести в список.
  9. Делаются бекпорты из CIP 4.4 и 4.19.
  10. Оборудование с истекшей гарантией никто из нас не проверяет. То есть там затраты уровня "нажал кнопку - вроде собралось - выложилось".
  11. А потом мы завтра меняем api, и у вас все слетает. В итоге шквал дерьма. Ну или эти "нестабильные функции" все равно стабильно вести до упора, сохраняя совместимость. Ну уж нет, такое себе, спасибо.
  12. С WG все нормально. У вас он везде в режиме сервера, без пиров. В таком случае он принимает входящие подключения на всех WAN, которые подняты. И если клиент продолжает приходить к нему на резервное подключение, то так и будет работать. В данном случае нужно научить клиента понимать что сервер поменял адрес.
  13. Технических особенностей нет никаких, и можно сделать хоть сегодня. Но по соображениям странного юзерского экспириенса мы это не делаем.
  14. При чем тут maradns и ipset? Добавлять адреса это 1% от сложности дела, основное я описал выше - покажите-ка мне как вы юзеру объясните, почему его ютуб не показывает, хотя он ввел youtube.com в политику.
  15. Нужен self-test сперва, пока ничего непонятно. А также неплохо бы описание, было ли когда-то "хорошо", если да, то на какой версии.
  16. Это все костыли с непредсказуемым результатам, продать такое за деньги не выйдет (или потом на поддержке разоришься).
  17. Плюс он еще на C++ переписан, что автоматически означает больше места на флешке (в разы) + больше ОЗУ. На 25 тысячах может и меньше будет, но на типичной задаче в 5-10 торрентов будет точно больше.
  18. Не очень верю, что это технически реализуемо для сервисов с шардированием. Ну вот сделали вы политику чтобы пихать в нее youtube.com. А вы точно уверены, что именно с этого адреса у вас идет видеопоток? У гугла там сотни серверов, причем на рандомных технических доменах. И как потом поддержка будет объяснять такие тонкости неподготовленным юзерам?
  19. Нет, синий порт комбинирован с SFP, несмотря на два физических разьема, одновременно может работать только один из них.
  20. Уже много лет у нас версия 3.00.
  21. Покажите-ка self-test ваш.
×
×
  • Create New...