Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 73
Чтобы IPv6 заработал, нужно просто сделать пинг и для AntiDDoS оборудования значит что сервер живой и можно отправлять на него трафик?
Видимо да. Я не могу точно сказать, что там происзодит, но на мой взгляд, такого точно быть не должно.
Есть недоработки в магистральном оборудовании (Не только Huawei, такая же проблема есть и у Juniper при работе с IPv6), которые приводят к такому глюку. Как я написал в моем комменте, реализация IPv6 еще весьма сыра в некоторых местах.
Насколько я знаю это проблема блокирования icmp6. Такое встречалось на FreeBSD 8, блокируем icmp6 все кроме дозволенного v6 и в итоге почему-то приходилось пинговать гетевей. Убрали фильтр в6 и проблема решилась.
Легко увидеть tcpdump на бсд и monitor traffic на жуне.
Глюков в6 в бсд 8 много (например невозможность параллельной работы статической и SLAAC на одной системе, обходили мануально, отсутствие SLAAC to SLAAC)
Просто пинг ничего не решил ни извне, ни с сервера.
Мне помогла только указанная автором комбинация с -I и 2a02:6b8::feed:0ff
Мне помогла только указанная автором комбинация с -I и 2a02:6b8::feed:0ff
Отличная история для IThappens.
Хотелось бы услышать комментарии от Van_Loon и самого хостера, т.к. мы собирались на него перевести часть сервисов.
Вы коллега исказили классику:
«Может быть, тебе дать еще ключ от квартиры, где деньги лежат?»
«Может быть, тебе дать еще ключ от квартиры, где деньги лежат?»
Данный пост скорее характеризует его автора, нежели говорит что-то о хостере.
Т.е. вы считаете нормальным, когда ТП просит рутовый доступ к вашему серверу?
Я крайне предвзято отношусь к мнению людей, которые сначала покупают самые дешевые услуги, а при первых проблемах с подобным поставщиком истерят и требуют компенсации простоя. Но более того, я с отвращением отношусь к «зазвездившимся» «техническим специалистам», склонным грубить сотрудникам техподдержки. У меня все.
Вообще-то да, запрос пароля техподдежкой это нормально, но как правило просят не сам пароль а доступ, например инсталлировав их SSH ключ и разрешив доступ с определенного IP, но иногда и без пароля им никак, тот же пример поддержка Cpanel, там если проблема на сервере, то ТП попросит доступа в систему без вариантов. Ну и по теме того что это VPS и якобы к ней легко сделать доступа хостеру — все зависит от технологии и её конкретной реализации, если у них какой-нибудь OpenVZ, то конечно доступ там совсем не проблема, а если это контейнеры KVM, то совсем не факт, что у ТП есть такая возможность, поэтому собственно я не вижу проблемы именно в запросе административного доступа.
Прочитайте мой комент https://habrahabr.ru/post/306570/#comment_9719282 и Вы поймете, почему мы так делаем.
Вот этот ответ — точно от технического работника, как по-вашему?
По сравнению с нетрадиционно клиентоориентированой другой компанией, которая с единичкой, у этих еще неплохо. С ддосами вот только пока справляться не научились, что все портит.
Борьба с DDoS-ами задача не простая, Особенно при наших текущий объемах трафика и количестве клиентов (одного известного анти-ддосера даже дико пошатало, когда мы просто попробовали взять у них защиту, а это люди, которые не первый год занимаются данным вопросом).
Но мы движемся в направлении решения данной задачи.
Но мы движемся в направлении решения данной задачи.
Буквально на днях брал тест. Поддержка повеселила.
Пинг скакал от 40 мс. до 500+ мс. При том картина одинаковая с Юга и Сибири. Ответ поддержки: сделайте обратный пинг и поставьте какую-то программу для анализа сети.
Можете сообщить номер тикета в ТП, посмотрю, что за проблема была? Для анализа работы сети мы советуем использовать mtr, и эта информация с Вашей стороны действительно помогает выявить проблемные места в передачи трафика через Интернет. Довольно часто возникают проблемы у транзитных провайдеров и информация собранная с помощью mtr, позволяет нашим сетевикам понять, с кем из операторов связи надо связаться для устранения проблемы.
Я допускаю, что проблема может быть на моей стороне. Поэтому тестировал из разных регионов. Сейчас время теста уже закончилось. Учитывая, что тикет за 2 дня не смог добраться до второй линии, уже нет желания продолжать разбираться.
И все таки, я бы попросил, сообщить Вас мне номер тикета или хотя бы логин в приват, чтобы я мог разобраться почему тикет гулял двое суток и Вам не смогли предоставить вменяемый ответ, моя задача реагировать на любые жалобы в работе ТП, проверять их и оптимизировать их работу, чтобы подобных проблем не возникало в будущем.
Вообще имхо, но не вижу в этом не чего ужасного, арестовывал сервера у hetzner.com и VPS у digitalocean.com и были случаи когда предоставлял root, хотя обычно через специальную форму, а не просто в текит пароль сбрасывал.
Хотя хотелось бы увидеть всю переписку, а то складывается впечатления что они силой пытались доступ получить.
Хотя хотелось бы увидеть всю переписку, а то складывается впечатления что они силой пытались доступ получить.
Я не знаю с какими хостерами ты работал.
Но я работал со многими и вполне нормально когда ТП просит у тебя рут доступ, дабы избавить тебя от лишнего гемора. Всегда даю без проблем, потом меняю его
Но я работал со многими и вполне нормально когда ТП просит у тебя рут доступ, дабы избавить тебя от лишнего гемора. Всегда даю без проблем, потом меняю его
Ну это ещё не дно, у одного моего VPS-хостера переписка с техподдержкой защищена соглашением о неразглашении, так что скринышоты просто так не поснимаешь…
Приветствую всех, отвечу по порядку:
1. Поскольку достаточно большое количество наших пользователей не являются продвинутыми админами (а именно они чаще всего пишут тикеты), то практика предоставления рутового доступа к VDS вполне оправдана. Во-первых, тем самым пользователь санкционирует доступ к своим данным наших сотрудников (в отличие от того, если мы сами полезем доступными нам методами). Во-вторых, никто не требует его предоставлять силой. Это право клиента давать доступ нашим сотрудникам или не давать. Опять же, если клиент не хочет разглашать свой любимый пароль, можно: а) поменять на временный пароль; б) создать альяс рута (произвольный пользователь с uid:gid=0:0) и предоставить его; в) создать обычного юзера и дать ему права через sudo. Любой профессиональный админ должен знать о таких способах. Данная практика была выработана на основе общей статистики работы тех. поддержки и позволяет сократить количество итераций и время обработки тикетов. Исправили проблему — меняйте пароль и работайте дальше.
Поверьте, нашей поддержке вот ни разу не интересно, что находится внутри Вашей VDS, у нас их уже 8000 шт. и никто не будет копаться в Ваших данных. При ежемесячном количестве обращений в ТП, которое уже составляет порядка 10к тикетов, у ребят на это нет ни времени, ни сил, не желания. К тому же, они также несут ответственность за разглашение информации, это прописано в трудовых договорах.
2. IPv6 — еще достаточно сырой протокол и даже в топовых провайдерских железках еще очень много багов в его реализации или отсутствия реализации некоторых функций, которые приводят к подобным багам. Как это ни странно, проблема залипания IPv6 — адреса, действительно лечится указанным Вами способом. Первая линия ТП просто не знала о такой особенности, по этому пошла по стандартному регламенту с предоставлением доступа к VDS (поверьте, в 95% случаев предоставление доступа действительно помогает решить проблему клиента или как минимум ускорить ее решение). Вам достаточно было просто написать «Я знаю, что проблема не внутри моей VDS, доступ дать не могу, передайте тикет сетевому инженеру».
3. В виду возникновения такой проблемы, мы обязательно проинструктируем первую линию ТП о способе ее решения. Если первая линия знает решения какого либо вопроса, то она просто дает инструкцию и не просит ни каких доступов.
4. Huawei находится на стадии тестирования и официально мы его пока не анонсировали. Новости в Твиттере и других соц. сетях по поводу его установки лишь отражают то, чем мы занимаемся в настоящий момент, над какими проектами работаем. В том же Твиттере, например, проскакивала и фотография Radware, которая также была на нашем тестовом стенде и сейчас мы ждем, более мощную железку, чтобы можно было ее испытать в нашей сети. Когда мы полностью внедрим свое анти-DDoS решение, будет официальный анонс и статья о наших приключения здесь на Хабре.
Если данная стандартная просьба задела какие либо Ваши чувства, то приношу за это свои извинения от лица компании и от себя лично.
1. Поскольку достаточно большое количество наших пользователей не являются продвинутыми админами (а именно они чаще всего пишут тикеты), то практика предоставления рутового доступа к VDS вполне оправдана. Во-первых, тем самым пользователь санкционирует доступ к своим данным наших сотрудников (в отличие от того, если мы сами полезем доступными нам методами). Во-вторых, никто не требует его предоставлять силой. Это право клиента давать доступ нашим сотрудникам или не давать. Опять же, если клиент не хочет разглашать свой любимый пароль, можно: а) поменять на временный пароль; б) создать альяс рута (произвольный пользователь с uid:gid=0:0) и предоставить его; в) создать обычного юзера и дать ему права через sudo. Любой профессиональный админ должен знать о таких способах. Данная практика была выработана на основе общей статистики работы тех. поддержки и позволяет сократить количество итераций и время обработки тикетов. Исправили проблему — меняйте пароль и работайте дальше.
Поверьте, нашей поддержке вот ни разу не интересно, что находится внутри Вашей VDS, у нас их уже 8000 шт. и никто не будет копаться в Ваших данных. При ежемесячном количестве обращений в ТП, которое уже составляет порядка 10к тикетов, у ребят на это нет ни времени, ни сил, не желания. К тому же, они также несут ответственность за разглашение информации, это прописано в трудовых договорах.
2. IPv6 — еще достаточно сырой протокол и даже в топовых провайдерских железках еще очень много багов в его реализации или отсутствия реализации некоторых функций, которые приводят к подобным багам. Как это ни странно, проблема залипания IPv6 — адреса, действительно лечится указанным Вами способом. Первая линия ТП просто не знала о такой особенности, по этому пошла по стандартному регламенту с предоставлением доступа к VDS (поверьте, в 95% случаев предоставление доступа действительно помогает решить проблему клиента или как минимум ускорить ее решение). Вам достаточно было просто написать «Я знаю, что проблема не внутри моей VDS, доступ дать не могу, передайте тикет сетевому инженеру».
3. В виду возникновения такой проблемы, мы обязательно проинструктируем первую линию ТП о способе ее решения. Если первая линия знает решения какого либо вопроса, то она просто дает инструкцию и не просит ни каких доступов.
4. Huawei находится на стадии тестирования и официально мы его пока не анонсировали. Новости в Твиттере и других соц. сетях по поводу его установки лишь отражают то, чем мы занимаемся в настоящий момент, над какими проектами работаем. В том же Твиттере, например, проскакивала и фотография Radware, которая также была на нашем тестовом стенде и сейчас мы ждем, более мощную железку, чтобы можно было ее испытать в нашей сети. Когда мы полностью внедрим свое анти-DDoS решение, будет официальный анонс и статья о наших приключения здесь на Хабре.
Если данная стандартная просьба задела какие либо Ваши чувства, то приношу за это свои извинения от лица компании и от себя лично.
Да не переживайте, всё вы правильно сказали. Это вполне логично — делать для ТП хостера юзера с sudo и т. п. для экстренного доступа, даже если у вас не VPS, а дедик — случаи бывают разные.
Да я не переживаю ), просто хочется, что было понимание, как у автора поста, так и у других хабровчан, что это не просто блажь сотрудника ТП, а нормальная устоявшаяся практика призванная оптимизировать работу, в которой нет ничего криминального. В конце концов, все мы приезжая в автосервис отдаем ключи от машины сотруднику этого самого автосервиса и не переживаем, на счет того — «а вдруг он будет кататься на моей машине?!!!».
Спасибо за прояснение ситуации с ipv6. Что делать с сервисами ipv6-only, правда, неясно. Скорее всего писать скрипт с проверкой доступности и пингованием.
Главное, чтобы полиция ключи от квартиры не просила, когда у меня явная карманная кража…
Это не блаж и не устоявшаяся практика — это что-то из ряда вон выходящее. Вы либо системно решаете задачу, либо пляшите с root-доступами которые как бы ни о чём вообще. Исключительно своё собственное мнение.
К примеру есть сервис с админами itsumma — им тоже нужны пароли, но что бы попасть на сервер используют:
а) флешку с токеном
б) файл ключа (или пароль, точно уже не помню)
в) доступ только через сервис самой компании, никаких коннектов напрямую
Но суть в том что никто, никому, никогда, не должен передавать никакие пароли совсем. Ни от банка, ни от хостинга, ни от домена. А то что у вас — это детский сад.
К примеру есть сервис с админами itsumma — им тоже нужны пароли, но что бы попасть на сервер используют:
а) флешку с токеном
б) файл ключа (или пароль, точно уже не помню)
в) доступ только через сервис самой компании, никаких коннектов напрямую
Но суть в том что никто, никому, никогда, не должен передавать никакие пароли совсем. Ни от банка, ни от хостинга, ни от домена. А то что у вас — это детский сад.
Вероятность того, что сотрудники автосервиса установят на вашу машину троян, равна нулю. А вот с vds — такой уверенности уже быть не может.
Я не ваш клиент, хотя и присматриваюсь.
И да, за почти 20 лет моего общения с серверами (начало еще на aha.ru в прошлом веке) рут-пароль у меня не спрашивал никто и ни разу. Вряд ли я бы стал так нервничать, как топикстартер, но что это меня бы шокировало — безусловно.
Я не ваш клиент, хотя и присматриваюсь.
И да, за почти 20 лет моего общения с серверами (начало еще на aha.ru в прошлом веке) рут-пароль у меня не спрашивал никто и ни разу. Вряд ли я бы стал так нервничать, как топикстартер, но что это меня бы шокировало — безусловно.
Вероятно, вы хороший специалист и не обращаетесь в ТП по каждому чиху VDS-ки. В прошлом веке, подобные вещи были уделом избранных, а сейчас, каждый первый хочет себе вдс и что-нибудь там настроить, при этом сами толком не знают, что и как.
Яркий пример, именно такого отношения к серверам, можно почитать в нашей ветке на серчах, как раз сегодня там состоялся диалог с одним пользователем.
Как раз именно такие, неопытные пользователи, чаще всего пишут в ТП. Вот, чтобы помочь им, нам и нужен рутовый доступ.
А ставить троян на VDS, ну это как если сотрудник сервиса увидит в Вашей машине хорошую деталь и под видом ремонта поставит вместо-нее б/у-шную. Опять же — вопрос доверия как автосервису, так и хостеру.
Я писал выше. технически — хостеру не нужны доступы и если кому-то сильно припрет поставить Вам троян, то поставят. А В нашем случае, вы хотя бы знаете, что у нас будет временный доступ в Ваш VDS для диагностики проблемы. Никто Вам не мешает в момент работы наших специалистов залогировать вводимые команды или даже смотреть их в онлайне (например, с помощью tail).
Опять же, никто не мешает отказать в доступе.
Ну и вопрос, это насколько же хостер не должен уважать себя, чтобы пихать клиентам троянов?
Любой серьезный бизнес — это прежде всего репутация. Особенно в такой высококонкурентной отрасли, как хостинг.
Яркий пример, именно такого отношения к серверам, можно почитать в нашей ветке на серчах, как раз сегодня там состоялся диалог с одним пользователем.
Как раз именно такие, неопытные пользователи, чаще всего пишут в ТП. Вот, чтобы помочь им, нам и нужен рутовый доступ.
А ставить троян на VDS, ну это как если сотрудник сервиса увидит в Вашей машине хорошую деталь и под видом ремонта поставит вместо-нее б/у-шную. Опять же — вопрос доверия как автосервису, так и хостеру.
Я писал выше. технически — хостеру не нужны доступы и если кому-то сильно припрет поставить Вам троян, то поставят. А В нашем случае, вы хотя бы знаете, что у нас будет временный доступ в Ваш VDS для диагностики проблемы. Никто Вам не мешает в момент работы наших специалистов залогировать вводимые команды или даже смотреть их в онлайне (например, с помощью tail).
Опять же, никто не мешает отказать в доступе.
Ну и вопрос, это насколько же хостер не должен уважать себя, чтобы пихать клиентам троянов?
Любой серьезный бизнес — это прежде всего репутация. Особенно в такой высококонкурентной отрасли, как хостинг.
Спасибо за развернутый ответ. Тезисно отвечу на ваши пункты, если позволите.
1. Предоставление рутового доступа к любому серверу — это риск. Я не склонен доверять первой линии ТП и считаю это оправданным. На сколько я понимаю, то вы не предоставляете услугу Managed VDS. А если так, то и доступ к серверу лишен смысла. Более того. Зачем предоставлять доуступ, если проблема не в сервере. Все работало и вдруг перестало. Если я там ничего не крутил, то это явно проблема с вашей стороны. Опять же, если я отказал в предоставлении доступа — не надо его настойчиво требовать. Можно написать команды и результат я с удовольствием предоставлю, ибо это в моих же интересах. Т.е. первая линия повела себя абсолютно неадекватно.
2. Если первая линия не знала о таком варианте лечения проблемы, то как же тогда построена коммуникация внутри ТП, если такая проблема решалась у моего товарища три дня назад? Почему я, как клиент, должен знать куда надо передавать проблему? Мне кажется логичным, что первая линия ТП это должна знать, а не я.
3. Логичное действие, но, как мне кажется, это не решение проблемы, а костыль. Фактически вы предлагаете мне написать скрипт, который будет пингать внешние хосты и если все упало, то пингать вашу AntiDDoS'ку? Странное решение.
4. Извинения приняты. Но хотелось бы не извинений, а решения проблемы с IPv6.
Еще раз спасибо за столь развернутый комментарий.
1. Предоставление рутового доступа к любому серверу — это риск. Я не склонен доверять первой линии ТП и считаю это оправданным. На сколько я понимаю, то вы не предоставляете услугу Managed VDS. А если так, то и доступ к серверу лишен смысла. Более того. Зачем предоставлять доуступ, если проблема не в сервере. Все работало и вдруг перестало. Если я там ничего не крутил, то это явно проблема с вашей стороны. Опять же, если я отказал в предоставлении доступа — не надо его настойчиво требовать. Можно написать команды и результат я с удовольствием предоставлю, ибо это в моих же интересах. Т.е. первая линия повела себя абсолютно неадекватно.
2. Если первая линия не знала о таком варианте лечения проблемы, то как же тогда построена коммуникация внутри ТП, если такая проблема решалась у моего товарища три дня назад? Почему я, как клиент, должен знать куда надо передавать проблему? Мне кажется логичным, что первая линия ТП это должна знать, а не я.
3. Логичное действие, но, как мне кажется, это не решение проблемы, а костыль. Фактически вы предлагаете мне написать скрипт, который будет пингать внешние хосты и если все упало, то пингать вашу AntiDDoS'ку? Странное решение.
4. Извинения приняты. Но хотелось бы не извинений, а решения проблемы с IPv6.
Еще раз спасибо за столь развернутый комментарий.
1. Не спорю, что это риск, но Вы должны понимать, что технически, у каждого хостера и так есть доступ ко всем Вашим файлам, даже без пароля. По этому, размещая какие либо данные у хостера, вы проявляете к нему доверие. И просьба в получении доступа к серверу лишь жест хорошего тона со стороны хостера. Это все равно как если Вы сняли номер в гостинице и Вам дали ключ от номера. Ежу понятно, что у персонала гостиницы всегда есть доступ в Ваш номер, но без Вашего разрешения туда никто не войдет, достаточно повесить табличку «Don't distrub». В противном случае репутация гостиницы будет стремиться к нулю.
Что касается Managed VDS, полное администрирование в цену не входит, однако, мы стараемся оказывать клиентам помощь в решение вопросов внутри самих VDS, даже если это и не связано на прямую с работоспособностью самого контейнера. По этому просьба предоставить доступ является обычной практикой в работе ТП, не только нашей, но и у других хостеров.
2. Проблема была неявной первая линия еще не была проинформирована о ее наличии. Сейчас всех уведомили способах ее решения.
3. и 4. Это вопрос, скорее к вендорам оборудования, а не к нам, мы им уже переслали свои замечания. Как Вы понимаете, у нас нет исходных кодов операционок маршрутизаторов и сами, мы исправить данную проблему не сможем. Я писал выше, та же проблема с IPv6 есть и в реализации данного стека у Juniper и даже без Huawei, проблема периодически возникала.
Естественно, мы продолжаем самостоятельно искать варианты ее решения. Возможно, для решения этой проблемы будет добавлен еще один маршрутизатор, в котором отсутствует данный баг.
Что касается Managed VDS, полное администрирование в цену не входит, однако, мы стараемся оказывать клиентам помощь в решение вопросов внутри самих VDS, даже если это и не связано на прямую с работоспособностью самого контейнера. По этому просьба предоставить доступ является обычной практикой в работе ТП, не только нашей, но и у других хостеров.
2. Проблема была неявной первая линия еще не была проинформирована о ее наличии. Сейчас всех уведомили способах ее решения.
3. и 4. Это вопрос, скорее к вендорам оборудования, а не к нам, мы им уже переслали свои замечания. Как Вы понимаете, у нас нет исходных кодов операционок маршрутизаторов и сами, мы исправить данную проблему не сможем. Я писал выше, та же проблема с IPv6 есть и в реализации данного стека у Juniper и даже без Huawei, проблема периодически возникала.
Естественно, мы продолжаем самостоятельно искать варианты ее решения. Возможно, для решения этой проблемы будет добавлен еще один маршрутизатор, в котором отсутствует данный баг.
Могу лишь пожелать Вам удачи и поблагодарить за сотрудничество.
А к вопросу о скорости реакции на тиккеты — номер 1000430, время ожидания на жанный момент 3 часа 30 минут.
И это на просьбу об удалении активного сервера и возврате остатка средств.
Кстати, невозможность удалить активный сервер немного напрягает.
А к вопросу о скорости реакции на тиккеты — номер 1000430, время ожидания на жанный момент 3 часа 30 минут.
И это на просьбу об удалении активного сервера и возврате остатка средств.
Кстати, невозможность удалить активный сервер немного напрягает.
Финансовый отдел заканчивает работу в 6 вечера по Москве. Завтра сделают перерасчет.
Спасибо, но было бы не плохо, если бы ТП в тиккете отвечала так же, как Вы на Хабре. :)
За последние полгода мы существенно улучшили качество и скорость работы ТП. Но есть еще над чем работать. Выстраивание такой организации на фоне всеобщего кризиса — задача не простая. Но мы движемся вперед ). В ближайших планах уже стоит организация регулярных экзаменов для сотрудников ТП на знание материала.
> достаточно большое количество наших пользователей не являются продвинутыми админами
…
>… любой профессиональный админ должен знать о таких способах.
Хм. Нестыковочка.
…
>… любой профессиональный админ должен знать о таких способах.
Хм. Нестыковочка.
Хотел бы уточнить одну вещь, пароль от root предоставляется через специальную форму и вообще логируется что данному сотруднику был предоставлен root доступ от сервера?
Пароль предоставляется в тикете, специальной формы у нас пока нет. Все действия сотрудников работающих с тикетом логируются.
имхо, но мне кажется что это огромная недоработка, пароль который был отправлен в тикете это как ключ под половиком, допустим поменялся сотрудник в ТП и ему присылают историю переписки с паролем или при получении доступа к тикету злоумышленник может получить доступ к серверу, а при этом уязвимость может быть в вашей системе, а не просто взлом аккаунта.
Под логированием я имел в виду то что система понимает что пользователь предоставил сотруднику пароль.
Я не претендую хотя бы на любительское мнение в области информационной безопасности, но мне кажется что пароль(желательно ключ) от сервера должен предоставляется только сотруднику который с этим сервером будет работать и не кому больше.
Под логированием я имел в виду то что система понимает что пользователь предоставил сотруднику пароль.
Я не претендую хотя бы на любительское мнение в области информационной безопасности, но мне кажется что пароль(желательно ключ) от сервера должен предоставляется только сотруднику который с этим сервером будет работать и не кому больше.
>>>и ему присылают историю переписки с паролем или при получении доступа к тикету
Т.е. Вы пароли годами не меняете?
Тут в комментариях уже сказано было — после отработки тикета меняете пароль.
Т.е. Вы пароли годами не меняете?
Тут в комментариях уже сказано было — после отработки тикета меняете пароль.
Всегда предоставляю отдельного пользователя специально для ТП, да и зачем сразу годами не меняю?
Самое важное то что пароль во время обработки тикета актуальный(иногда тикет активен около 3 дней), и как отследит кто получил доступ к серверу если с тикетом работало 5 человек и опять же повторюсь, взлом базы с тикетами и актуальные пароли уже у злоумышленника из активных на данный момент тикетов, когда если бы пароль предоставлялся только человеку который с этим сервером работает ответственность была только на этом человеке (и компании) и в случаи взлома злоумышленник не смог бы получить доступ к серверам.
Самое важное то что пароль во время обработки тикета актуальный(иногда тикет активен около 3 дней), и как отследит кто получил доступ к серверу если с тикетом работало 5 человек и опять же повторюсь, взлом базы с тикетами и актуальные пароли уже у злоумышленника из активных на данный момент тикетов, когда если бы пароль предоставлялся только человеку который с этим сервером работает ответственность была только на этом человеке (и компании) и в случаи взлома злоумышленник не смог бы получить доступ к серверам.
Van_Loon у вас как-то странно работают приоритеты у ТП. Когда выбирал обычный — отвечали в течении 5 минут, последний раз выбрал срочно — так ответили спустя много часов.
Видимо из-за того, что все выбирают «срочно». И этих «срочно» гораздо больше, чем «обычно» и ТП реагирует соотвественно.
Если вы сообщите мне номер проблемного тикета, то я смогу понять причину зависания его у ТП и постараться устранить подобное зависание в будущем.
Прочитав статью и каменты, понял, что это неплохой хостинг :)
Насколько я понимаю что там происходит — они агрессивно фильтруют мультикаст (на котором весь ipv6 держится), так что маршрутизатор не может определить что узел в онайлне. Отправка пинга через link-local приводит к обновлению таблицы «соседей» на маршрутизаторе и он начинает «знать» на какой mac отправлять трафик.
А зачем маршрутизатору «знать» mac?
Вы правы, мультикаст действительно фильтруем, если этого не делать, то все VDS получали бы огромную массу флуда из-за того, что в одном сегменте сети находится большое количество хостов. По началу у нас так и было, и были жалобы от клиентов что много лишнего прилетает по сети на VDS. Сейчас, VDS по L2 видит только гейт, по этому в эфире тишина, однако в реализации IPv6 на текущем сетевом железе имеются недоработки которые приводят к залипанию IPv6-адресов. Сегодня, сетевые инженеры сделали ряд настроек, которые должны снизить вероятность возникновения данного эффекта.
Как миниму еще несколько крупных хостеров при обращении в ТП запрашивают рут-доступ через отдельное поле в тикете. Не вижу в этом ничего криминального т.к. после решения пробелмы можно сменить пароль. В случаях же когда пароль не нужен, а тикет с пустым полем не отправляется пишу туда «не нужно».
Лично меня больше возмущает ситуация когда на свежесозданном виртуальном сервере в authorized_keys лежат публичные ключи саппорта. Захожу и вручную удаляю их прописывая взамен свои.
Лично меня больше возмущает ситуация когда на свежесозданном виртуальном сервере в authorized_keys лежат публичные ключи саппорта. Захожу и вручную удаляю их прописывая взамен свои.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Лоукост VDS хостинг в России и его техподдержка