- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
А почему этот способ не работает с интерфейсами?
Потому что поддержка такого функционала должна быть заложена на уровне ПО. Любое ПО, если это не заложено в его функционал, перезапишет конфиг VPS при рестарте или при изменении любого параметра, как следствие, у вас пропадёт этот самый второй интерфейс.
В этом и сложность, что поддержка должна быть реализована на уровне ПО, а её нет. Вручную-то конечно сделать несложно, но это несовместимо с большинством ПО, а следовательно предлагать то, что не совместимо никто в здравом уме не будет.
У всех (ладно, у большинства) все автоматизировано, и выдача услуги, и ее биллинг, и возможные допы. И чаще всего вся эта автоматизация завязана на то или иное ПО с теми или иными возможностями. И городить огород для стандартной услуги с "несколькими дополнительными строчками в конфиге" ни кто не будет. В этом все отличие стандартной услуги от нестандартной.
Я так и не понял как это связано с тем, что нет возможности кастомизировать в конфиге те параметры, которые не изменятся автоматически при изменении того же тарифа, например. У нас тоже все автоматизировано. При этом можно как угодно изменить конфиг виртуалки. При этом изменения затрутся только если они были связано с изменяемыми в панели параметрами. Что сети вообще не касается.
Не знаю, может у Вас BillManager и там так нельзя и конфиг всегда затирается. Ну, мои соболезнования.
В этом и сложность, что поддержка должна быть реализована на уровне ПО, а её нет. Вручную-то конечно сделать несложно, но это несовместимо с большинством ПО, а следовательно предлагать то, что не совместимо никто в здравом уме не будет.
Значит у вас плохое ПО...
Нужная мне конфигурация сервера была предоставлена хостером HexCore. Видимо, они умеют чуть больше.
Потому что поддержка такого функционала должна быть заложена на уровне ПО. Любое ПО, если это не заложено в его функционал, перезапишет конфиг VPS при рестарте или при изменении любого параметра, как следствие, у вас пропадёт этот самый второй интерфейс.
В этом и сложность, что поддержка должна быть реализована на уровне ПО, а её нет. Вручную-то конечно сделать несложно, но это несовместимо с большинством ПО, а следовательно предлагать то, что не совместимо никто в здравом уме не будет.
Да тот же ProxMox это поддерживает, хоть 100+ интерфейсов добавлять но как было указано выше - это уже НЕ стандарт. Я понимаю когда такое просят для выделенного сервера для создания локальной сети, но для виртуалки это реально не имеет смысл, eth0:0 вообще ничем не отличается от eht1 в целом в случае виртуалки, но раз человек так хочет то пусть пользуется.
Да тот же ProxMox это поддерживает, хоть 100+ интерфейсов добавлять но как было указано выше - это уже НЕ стандарт. Я понимаю когда такое просят для выделенного сервера для создания локальной сети, но для виртуалки это реально не имеет смысл, eth0:0 вообще ничем не отличается от eht1 в целом в случае виртуалки, но раз человек так хочет то пусть пользуется.
Тут больше проблема со стороны биллинга, если клиент захочет перейти на другой тариф, где нет таких опций, то новый гемарой с добавлением дополнений, либо пропадут дополнения.
Да и панели от ISP, не умеют корректно работать с сетями IPv6, а только выделяют ip адреса поштучно, соответственно требуется много ручных действий, которые хостерам не нужны, а клиенты не готовы постоянно их оплачивать.
P.S. Да и как правило IPv6 используются под СПАМ и тому подобное и обычным пользователям вообще не нужны, а соответственно куча других проблем от таких клиентов.
eth0:0 вообще ничем не отличается от eht1
Debian, видимо, не в курсе: "the networked computer needs to have two ethernet ports". Сможете на eth0:1 настроить бридж так, чтобы при этом не отвалился eth0? Если сможете - будет смысл продолжить разговор. Костыли в виде VNC для работы с сервером просьба не предлагать.
Тут больше проблема со стороны биллинга, если клиент захочет перейти на другой тариф, где нет таких опций, то новый гемарой с добавлением дополнений, либо пропадут дополнения.
Да и панели от ISP, не умеют корректно работать с сетями IPv6, а только выделяют ip адреса поштучно, соответственно требуется много ручных действий, которые хостерам не нужны, а клиенты не готовы постоянно их оплачивать.
P.S. Да и как правило IPv6 используются под СПАМ и тому подобное и обычным пользователям вообще не нужны, а соответственно куча других проблем от таких клиентов.
Debian, видимо, не в курсе: "the networked computer needs to have two ethernet ports"
Там вообще о другом говорится, кстати говоря. А именно о том, что для подключения одного компьютера через другой компьютер у одного из них должно быть два физических интерфейса, что логично (в один же порт два кабеля не воткнёшь).
В вашем случае, так как у вас в первом посте 1 IPv4 и 1 сеть /64, все эти адреса просто прописываются в конфиге бриджа так, как вы их прописали бы для обычного eth0.
Там вообще о другом говорится, кстати говоря. А именно о том, что для подключения одного компьютера через другой компьютер у одного из них должно быть два физических интерфейса, что логично (в один же порт два кабеля не воткнёшь).
Я немного другое имел ввиду: debian не в курсе что к бриджу можно субинтерфейсы привязать. Информации об этом нет в документации. А если привязывать eth0:1 к бриджу, то eth0 отвалится. Что как бы намекает на то, что eth1 и eth0:1 - таки отличаются.
В вашем случае, так как у вас в первом посте 1 IPv4 и 1 сеть /64, все эти адреса просто прописываются в конфиге бриджа так, как вы их прописали бы для обычного eth0.
👍😅 Такое чувство, что я к вам с вопросом пришёл. И вторую /64 сеть предлагаете сюда же прописать?
Я немного другое имел ввиду: debian не в курсе что к бриджу можно субинтерфейсы привязать.
Я упустил из виду, что Вам нужен только Debian и ничего иного. Просто CentOS в курсе. И более того, позволяет прописать несколько IPv6 сетей в один конфиг через параметр IPV6ADDR_SECONDARIES.
Я упустил из виду, что Вам нужен только Debian и ничего иного. Просто CentOS в курсе. И более того, позволяет прописать несколько IPv6 сетей в один конфиг через параметр IPV6ADDR_SECONDARIES.
Насколько я понимаю, речь идёт о network scripts /etc/sysconfig/network-scripts/ ?