virrasha

virrasha

пикабушница
поставилa 2754 плюса и 31 минус
отредактировалa 0 постов
проголосовалa за 0 редактирований
16К рейтинг 1378 подписчиков 474 комментария 30 постов 26 в горячем
1 награда
более 1000 подписчиков
170

Сага о переезде

Итак, несколько человек под прошлым постом сказали, что им будет интересно почитать про переезд компании.


Сразу скажу - история не про то, как классно все данные и сервисы размещены в облаке или ЦОДе, как у всех макбуки и мы провели сертифицированный тренинг по их правильному отсоединению от зарядки и складыванию в сумочку. Нет. История о большой компании, которая давно отделилась от другой большой компании, с кучей костылей, множеством «так исторически сложилось» и ограниченным бюджетом. Обычная, короче, компания, не модный стартап со смузи.


Вводные – переезжал головной офис. Сотрудников около 170 человек. Две с половиной стойки оборудования (сеть и сервера). На этих серверах крутятся те сервисы, которые централизованы для филиалов (филиалов на тот момент было чуть больше 30, от Камчатки до Калининграда часовые пояса). На тот момент уже появился круглосуточный call-центр, который тоже крутился у нас. То есть, для call-центра перерыва связи быть не должно. Некоторые сервисы, которые используются в филиалах – перерыв может быть с 20:00 до 00:00, всё остальное должно заработать к понедельнику. Ну и конечно, у бухгалтерии был квартальный отчет и им лучше бы к воскресенью всё сделать. Нас команда: четверо айтишников, включая меня и всех начальников, плюс один безопасник, плюс еще двое ребят от принимающей стороны скорее в качестве физической силы. Это был уже второй такой переезд и что-то мы учли, что-то нет.


В филиалах локально есть контроллеры домена, сервер со специфическим ПО, которое нужно для работы. То есть филиал со скрипом, но может работать автономно. Но без почты, документооборота, лицензий на 1с и прочего ему немного грустно.


Про то, что «скоро переезд, морально готовьтесь» мы узнали за месяц. Про точную дату – дней за 10. Переезд был в ночь с пятницы на понедельник.


Подготовка, первый этап:

Как только известно помещение и туда начинают пускать – выдвигается бригада туда на осмотр. Смотрят помещение под серверную – оно есть или его надо выделять и оборудовать. Смотрят на помещение серверной – должна быть железная дверь, кондиционирование, отсутствие окон, либо решетки на них, должно быть место, чтоб влезли стойки, желательно газовое или порошковое пожаротушение, но ни в коем случае не водяное. Смотрят на расположение серверной относительно офиса – от каждого рабочего места не более 100 метров по изгибам потолка, а если больше, то планируется дополнительно кроссовая (под патч панели и свичи). Смотрят на рабочие места – расшиты ли сетевые розетки, сколько на рабочее место, есть ли запас под всякие принтеры и прочее. Завхоз рисует план рассадки.


Мы переезжали с одного на два этажа, соответственно проверяли ещё, что есть пучок проводов с одного этажа на другой.


При необходимости ищутся подрядчики и заключаются договора по прокладке СКС, монтажу кондиционеров и прочей лабуды.


Подготовка, второй этап:

Решение вопроса с интернетом и телефонией. У нас это выглядело следующим образом:


- запрашиваем КП у текущих провайдеров на перенос канала на новое место + еще парочку провайдеров на подключение на новом месте.

- Выбирается одно лучшее из новых и одно лучшее из старых провайдеров.

- готовимся все сервисы ужать в одного провайдера, который остается на старом месте

- Договариваемся примерно по срокам, они начинают протяжку и подключение, но час Х обговаривается позже. Обычно это за 3-5 дней до переезда у старого провайдера и за 7-10 дней до переезда у нового провайдера, чтоб успеть туда съездить и протестировать.

- Договариваемся с провайдером телефонии о переноси, они тоже тянут кабели. Тут час Х обычно в день переезда часов в 14-16.

- У нас 8800 приходит по IP, потому уведомляем Ростелеком, что в цепочку IP добавится еще один адрес (нового провайдера).


Как только известны IP нового провайдера, на них прописываются MX с низким приоритетом, договариваемся, что они на почтовик нам обратную зону пропишут и прочее такое, чтоб при переезде подрубиться частично к новому провайдеру. Также всем филиалам рассылается новый будущий IP для подключения по IPSec, у кого есть возможность (D-Link), он прописывается в адресную книгу. Всем составляется инструкция – как менять самим по отмашке.


Подготовка, третий этап

Выясняем план рассадки у завхоза, едем сверять его с помещением. Обязательно найдутся места, где нет не то что сетевых, а даже электрических розеток. По срокам смотрим: успеют сделать монтаж или нет, и если нет, срочно закупаем пару бухт витухи и удлинители.


Пытаемся понять, есть ли на новом месте стойки в серверной для монтажа. В этот раз 2 стойки ехали с нами и полторы в сумме были свободны у принимающей стороны для точечного втыкания чего-нибудь. Это важно, от этого зависит план переезда.


За неделю начинаем накидывать поэтапный план на день переезда, но об этом дальше.

Уговариваем начальство, что сотрудников перевозят специальные грузчики (Они отсоединяют компы, пакуют, подсоединяют на новом месте по плану рассадки). Поясню – один админ в средне физической форме может распаковать, расставить и подключить в среднем 20-25 рабочих мест за рабочий день без перекуров. То есть, если не тянуть кабели, быстро кроссировать куда попало, то нам на четверых как раз 2 дня не разгибаясь, а, как вы понимаете, сервера сами себя не поставят в стойку и не настроят. Да, у этих перевозчиков куча косяков, но это не ваши косяки, а их. Примерно 20% они подключат не так или не воткнут моник или еще что, но это можно будет решить в понедельник, главное, они всё расставят, снимая с вас физическую работу.


Думаем, что-как распределить в кроссовой и серверной и не надо ли чего купить (нам нужны были гребёнки для проводов и дополнительные розетки в стойку).


Смотрим, что там с электричеством и сколько киловатт надо на наши UPSы. Мы этот этап продолбали и срочно искали электриков за день до переезда, так что советую озаботиться заранее – там ещё и предохранители иногда надо менять. Также для подключения большого UPS может понадобиться электрик на месте – надо озаботиться, чтоб он там в ночь дежурил.


За три дня до переезда

Всем сотрудникам напоминаем, что надо подписать всё своё оборудование – наклейки на комп, монитор, ИБП, телефон, наушники и т.д. Для фирмы-перевозчика еще и номер рабочего места пишут, а у них есть план рассадки с этими номерами – по нему расставляются рабочие места в новом офисе.


Собираем по максимуму личные вещи и всякое со стеллажей. Выкидываем весь хлам (мертвые списанные принтеры «авось пригодится», старые доки на гарантию, разбитые моники и прочее барахло). Иногда можно договориться с фирмой на утилизацию, которая всё бесплатно заберет – мы так делали. Всё, что не хлам – пакуем под переезд (не новое, но рабочее оборудование, которое лежит про запас, для тестов).


Откладываем: консольные кабели ко всем железкам, один удлинитель, пару полутораметровых патчиков, 2 мышки, 2 клавиатуры, 2 монитора, обжимка. Один комплект монитор-мышка-клава можно увезти в новую серверную, провода пойдут вам в рюкзак в день переезда.


Сверяем схему сети с текущим положением вещей – освежаем, если что не так. На схеме должны быть подписаны все транковые порты с указание VLAN в них, порты на всяких криптошлюзах и все неочевидные соединения, а также все порты, куда приходят белые IP напрямую, порты в LACP, зазеркалированные порты. Мы разъезжались на два этажа, а потому я рисовала еще прикидочную схему для нового расположения.


Проверяем, что все сервера подписаны.


Еще раз дублируем филиалам, что скоро мы переезжаем, да, сервисы будут недоступны, можно не звонить, сервер будет в машине ехать. Дублируем им инструкции, говорим, что переключаться после 23:00 в пятницу. Или можно раньше для дальневосточных регионов.

Если что-то требует ребута после установки обновлений – вечерком всё ребутаем. В день переезда сервера должны выключаться быстро.


Проверяем работу провайдеров в новом офисе.

Проверяем наличие всех бэкапов.

Оформляем круглосуточные пропуска в новый и в старый офис на всю команду.

Окончательно формируем план на день переезда.


Договариваемся, кто принесет шуруповерты из дома – необходимо минимум 2 шуруповерта и 2 большие плоские отвертки из фикспрайса (ими удобно поддевать крепления в стойках, а также из них получается отличный рычаг, если что поддеть, поднять и т.д.).


День переезда (пятница)

Приезжаем на работу с ноутбуком, зарядкой к нему. Помним про 2 шуруповерта. Я ещё беру набор фломастеров – рисовать поверх схем. Рекомендую моток малярного скотча.


Проверяем еще раз наличие бэкапов.


На сайт вешаем баннер, что «с 18:00 технические работы, возможны перебои в работе call-центра».

Все инструкции по восстановлению, IP адресацию, схемы сетей, телефонные справочники копируем на ноутбук. Вы же помните, ваша справочная система и шары будут отключены. Еще хорошо бы дистрибутивы серверной винды и live-cd к линуху. А также Putty, tftp32, Wireshark.

Распечатывается в 4 экземплярах текущая схема сети и будущая схема сети. Печатаются все контакты всех поддержек провайдеров, а также то, что они спрашивают: ИНН, номер личного кабинета или что ещё. Печатается телефонный справочник админов филиалов.


К 12 дня выключаются все дублирующие контуры: по 1 серверу из кластеров. 1 контроллер домена, один почтовик, один edge и т.д. Также к 12 ИТ выключает свои ПК и переходит на ноутбуки. Эта первая партия грузится кому-то в машину и уезжает в новый офис.


У организации в пятницу рабочий день до 16, но все всё равно пакуют вещи и трындят, так что основной народ выпинывают по домам в 14. Но бизнес-процессы филиалов завязаны на ГО. Так что грузчики носят мебель, пакуют людей, а мы пока выключаем вторую партию – то, что не нужно для работы филиалов или без чего можно пережить – это сервер антивируса, FTP, мониторинг, сервер видеоконференций, WSUS, все пользовательские коммутаторы и телефония ГО.


Также где-то в 15 у нас назначено переключение городских телефонов. Как только доезжает но нового офиса партия с телефонией – я подключаю и проверяю. Городской телефон – последний резерв для нашего 8800, а значит должен работать хотя бы один аппарат. В новый офис уезжает один из маршрутизаторов и проверяется, что остальные специалисты call-центра из ночной смены смогут подключиться через него по VPN. Эту ночь они будут работать на удалёнке, кроме одного на физическом городском телефоне в самый переезд.


Начиная с 16 стараемся освободить одну стойку и UPS, на новом месте всё ещё некуда втыкать сервера. 2 сетевухи в NIC Team и два блока питания на разных упсах этому способствуют. Сервер можно переставить из стойки в стойку попеременно отключая по одной паре проводов. Часть серверов просто кладем на пол работать. Ребята разбирают стойку, отдают грузчикам. И один UPS (120 кг) тоже.


Кто-то в новом офисе собирает стойку и подключает ИБП, у остальных перерыв до восьми вечера где-то.


В 20:00 выключается всё, кроме call-центра и того, что нужно операторам для работы (а им нужна почта, единая БД с данными, маршрутизатор, коммутатор под это… короче, в сумме серваков 5 + кусок сети). Разбираем вторую стойку. Все грузимся и едем монтировать на новом месте.


Я занимаюсь сетью: первая задача инет, всё распределить, всё связать, коммутаторы под серваки и IPMI. У нас инет получился на одном этаже, а все сервера и большая часть сетевого оборудования на другом, соответственно, всё прокинуть через межэтажные розетки, всё подписать на схеме, потом DHCP, Контроллеры домена, почта. Проверяю каналы с филиалами дальше, чем +5 часов от мск – если не осилили по инструкции, перенастраиваю (да, авто-failover там очень херово отрабатывает, поэтому ручками). Перебиваю вся внешнюю зону DNS под новые адреса.


Все монтируют сервера, проверяют их работу. Это не быстро, так как грузчики их замотали в пупырку, а снаружи они не подписаны, а начать хочется опять же с критичного.

Сага о переезде Системное администрирование, Переезд, План, Длиннопост

Где-то в 22 прерываемся и едем за call-центром в старый офис. Всё отрубаем, всё забираем – всё, сюда больше не вернёмся в ближайшее время.


Врубаем всё для call-центра на новом месте, проверяем, что операторы могут работать. Параллельно продолжаем монтировать сервера.

Добиваю каналы со всеми филиалами. Попутно разгребаем неизбежные косяки, втыкаем сеть в соответствии со схемой. Проверяем, что всё запустилось. Втыкаем остальные сервера (те, что еще в первой партии – дубли и ненужное). Синхронизируем и реплицируем всё, что рассинхронизировалось. Кроссируем кабинет для операторов контакт-центра. Всё, к 3-4 утра разъезжаемся спать.


В 8 нас будит следующая смена операторов – им косячно перевозчики подключили компы. У двух нет сетевого кабеля, одной не подключили монитор и т.д. Но у них есть пара работающих мест и они пока переживут.


К 10 утра мы снова в офисе. Теперь делимся – один идет проверяет компы по списку приоритеа – у нас это call-центр, бухгалтерия, топ-менеджмент. Потом сколько успеет остальных. Много где надо тянуть кабель, много где наоборот - длинную мотню заменить коротким. Всех нужно скроссировать. Попутно принтеры надо подключить и тоже скроссировать отдельно, проверяем на свежую голову, что всё работает. Рассасываемся дальше спать часов в 18. В Воскресенье все появляемся на пару часов в разное время – подключить свои рабочие места, помочь бухгалтерии, у которой отчет, проверить еще сколько-то компов на местах у юзеров, порешать всё, что не работает.


Понедельник – решаем проблемы по мере поступления – у кого-то умер винт при переезде, у кого-то моник коцнули, у кого-то розетка не туда скроссирована. Часть телефонов попали в сеть другой организации и требую теперь только шифрованный конфиг и прочие мелочи. Ну и начинается месячник "мне дует" и "меня облучает, пересадите".


Итого:

У нас был большой косяк с электричеством, мы про него забыли.

У меня был косяк с тем, что Ростелеом не отрабатывал failover как обещал, а я не проверила заранее.

Еще косяк с контакт-центром, можно было взять ip АТС c десятком номеров на месяц – на время переезда было бы проще, не подумала.

Если у вас есть пустые стойки в новом офисе – всё гораздо быстрее.

Перевозить много юзеров малым составом эникейщиков не стоит, лучше нанять фирму. Фирма косячит, но это лучше, чем самим, просто поверьте (если у вас конечно нет бригады в 4 эникейщика в хорошей физической форме).


Послесловие:

Я не буду как в прошлом посте отвечать на каждый коммент и оправдываться, почему так, а не иначе. С удовольствием почитаю ваши советы и что-то мы возьмем на вооружение в следующий раз. А что-то проигнорирую, ибо на то есть причины.

Цель данного поста – описать переезд глазами админа. Мне бы такой пост очень помог в первый наш переезд, когда у нас был косяк на косяке. Постаралась упомянуть всё, что вспомнила. А на хабре пишут ванильные посты про супер-современные офисы.

Показать полностью 1
574

Один пинг проходит и тишина – решение проблемы

Кому не интересно, можно сразу переходить к блоку «как лечить».


Симптомы:

Итак, ранним осенним утром внезапно отвалились почти все сервисы для одного из филиалов. Симптомы: один пинг проходит и дальше «тишина». Иногда может пролететь еще 1 icmp, но редко. При повторном запуске пинга даже одного пакета уже не пролетает, если не выдержать паузу в несколько минут. Отвалились не все сервисы, но большинство.

Та часть схемы сети, которая нас интересует:

Один пинг проходит и тишина – решение проблемы Системное администрирование, Пинг, Перенаправление, Сети, Маршрутизация, Длиннопост

Понятно по схеме, что грешить сразу стали на красный ящик WatchGuard Firebox, но на нём явно никаких блокировок в логах не обнаружено. Поэтому коллега пока пускал трафик до самых важных сервисов в обход, а я ставила WireShark на то, что не столь нужно вот-прям-щас.


Что происходит:

Итак, что показал WireShark:

Один пинг проходит и тишина – решение проблемы Системное администрирование, Пинг, Перенаправление, Сети, Маршрутизация, Длиннопост

А показал он нам, что после первой же пары request/reply нам прилетело от Watchguard сообщение ICMP redirect (type 5; code 1), в котором сказано примерно следующее «братюнь, да что ты мне своими реквестами отвечаешь, я тут посмотрел – у меня есть более крутой маршрут для этого хоста – шли всё на шлюз 10.77.10.254».


Вот тут и дошло до меня, что ICMP – это не только пинги, но и «Internet Control Message Protocol». Из вики: «ICMP-сообщения с типом 5 используются маршрутизаторами для обновления записей в таблице маршрутизации отправителя». Далее, собственно, request по-прежнему приходит с WatchGuard, а reply уходит на D-Link. При этом, на сервере есть статический маршрут в сеть 10.97.0.0/16 (через 10.77.10.3), а системе строго срать на этот маршрут! Всё потому, что на самом деле при получении сообщения redirect, маршрут на хост (то есть более специфический) добавляется в таблицу маршрутизации на 10 минут. Но route print его не показывает. И не нужно гнать на винду: во всех debian были всё те же симптомы.


Почему это происходит:

Беда Особенность Watchguard, как и микротиков, что Site-to-Site IPSec не является интерфейсом, не участвует в таблице маршрутизации, и, соответственно, маршруты на сеть за поднятым туннелем вы в ней не увидите. На нашем ватче был маршрут 10.0.0.0/8 на 10.77.10.254, так как за D-Link находятся все остальные филиалы (агрегированные по /16 каждый), чтоб не писать маршрут на каждый филиал (их 50, а динамической маршрутизации нет). Из-за особенностей Watchguard получилось так, что на 10.97.0.0/16 маршрута он не видел. Раньше, кстати, всё было ок до последнего обновления прошивки.


Почему некоторые сервисы и все компы были доступны: на них стоял касперский с сетевым модулем, который отбрасывал эти сообщения как небезопасные.


Что было сделано и не помогло:

Попробовали задрать метрику на маршруте 10.0.0.0/8 на WatchGuard – не помогло. Попробовала сделать правило фильтрации по типу ICMP и блочить эти сообщения – не помогло, через это правило трафик с сообщением редиректа не проходил.

Один пинг проходит и тишина – решение проблемы Системное администрирование, Пинг, Перенаправление, Сети, Маршрутизация, Длиннопост

Ну и были перечитаны кучи мануалов по отключению редиректа на WatchGuard – ничего рабочего не нашлось.


Как лечить в итоге:

На линухе лечится тремя командами (2 чтоб прям вот сейчас, одна, чтоб прям вообще).

Запрет приёма редиректа:

/sbin/sysctl -w net.ipv4.conf.eth0.accept_redirects=0

Запрет отправки редиректа:

/sbin/sysctl -w net.ipv4.conf.eth0.send_redirects=0

И чтоб вообще:

echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects

Ну и может networking рестартануть, делала машинально.

При этом редиректы продолжают падать, но эффекта не оказывают:

Один пинг проходит и тишина – решение проблемы Системное администрирование, Пинг, Перенаправление, Сети, Маршрутизация, Длиннопост

На винде правится параметрами реестра, но эффекта до перезагрузки не оказывает (даже если выключить-включить сетевой интерфейс). Параметр в ветке

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

называется EnableICMPRedirect и выставляется в 0. По некоторым советам гугла (про Windows 2000 простихосподи), добавляла еще EnableICMPRedirects (во множественном числе). НО! После ребута сообщения redirect на машинах с исправленном параметром вообще не регистрируются WIreShark’ом, что меня несколько смутило (а вдруг вернутся?). Ну и ребутать over 100 серваков – такая себе идея.


Так что в итоге убрала маршрут 10.0.0.0/8 и добавила вместо него два:

10.0.0.0/10 и 10.64.0.0/11 – получились все сети от 10.0 до 10.95 включительно, а 97-ая, как видите, не вошла, что нас в принципе устроило. Проблема ушла.


То, что обычно пишут в начале поста:

Предыдущий мой пост на ИТ тематику был более 2 лет назад.

Чуть раньше этого я познакомилась на пикабу с классным чуваком, а полтора года назад мы поженились. Сисадмин и программист – норм сочетание оказалось =)


Я попробовала писать на хабр (мне даже одобрили аккаунт за тот пост), но мне не понравилось – на пикабушечке и аудитория поживее и можно не так цензурить текст.


А ещё наш офис вместе с серверной, которая уже стала мини-ЦОД для компании два раза за два года переехал. Если кому интересно – напишите в комментах, могу сделать пост о том, как происходит такой переезд, что мы планируем на каких этапах и т.д. На идеал не претендуем, происходит та ещё трешанина, но рассказать могу.

Показать полностью 3
130

Этика в работе системного администратора

Обсуждали мы с @pfsenses нехорошее поведение человека из вот этого поста и вспомнилось мне, что давно хотела написать пост об этике в работе системного администратора. В том числе – поднять вопросы, на которые у меня нет четкого ответа. Обсуждение приветствуется.


Итак, проблема номер 1 – доступность данных, систем и манипуляций с ними. Будем честны, если вы админ небольшой фирмы или глава админов (в смысле, не менеджер, а всё ещё админ) фирмы среднего размера, то вы можете сделать с системой всё. Исключение составляют большие фирмы с реальным разделением труда или задроченные на ИБ (большие банки, например, или там ФСБ), где половинкой пароля владеет админ, а половинкой безопасник, или сети между собой не связаны или еще какие крутые заморочки. Мы про реальную жизнь, а она подсказывает, что админ средней компании может сделать всё. Конечно, грохнуть всю систему – это уголовно наказуемо. И если не совсем идиоты её проектировали, то и восстановлению она более-менее поддаётся. Но серьёзно поднасрать и устроить длительный перерыв работы компании – вообще не требует усилий. Я считаю, что мы этого не делаем потому что

а) ещё раз – это уголовно наказуемо,

б) Это «волчий билет» в профессии

в) А нафига? Профита нет, я это любовно строил, а теперь ломать?

Фактически, работа строится на вере работодателя в то, что мы осознаем ответственность, психически адекватны и не захотим вредить. Собственно, сюда же я отнесу и отношение к найденным внутренним уязвимостям. Нашел – сообщи руководству или безопасникам, закрой по возможности.


Вопрос номер 2 – доступность информации работодателя и личной информации сотрудников. С базами работодателя понятно, все мы (надеюсь) подписывали бумажку о неразглашении и нераспространении. Слить базу - опять же, уголовно наказуемо, «волчий билет» и всё такое. Однако, идиоты, сливающие базы, находятся и их успешно ловят. ИМХО – оно того не стоит.

По второй части - кому из нас не приносили личный/корпоративный ноут на «починить», диск на «восстановить», мобильник на «настроить». У кого пользователи совсем не хранят на рабочих ПК фоточки с отпуска и т.д.? Волей-неволей мы знаем кучу маленьких грязных секретиков других сотрудников. Я считаю неэтичным распространение личной информации людей без их разрешения. Но люди! Вы думайте головой, когда относите свою технику или даёте свои личные данные кому-то! О, ещё классная штука – оставить свой телефон, пароли, кредитку и сказать «ну ты там мне настрой appstore». В общем, что у людей в голове – мне не ясно, но пользоваться доверием этих наивных человеков мне не позволяет совесть. Еще и рассказать им пытаюсь о том, что они не правы, так разбрасываясь данными.


Вопрос номер 3, самый для меня неоднозначный, слежка за сотрудниками. У нас всё цивильно, в договоре это прописано, у старых сотрудников - отдельным приказом с ознакомлением. Однако, слежка за тем, с кем приятельские отношения, слежка за админами филиалов – доставляет некоторый моральный дискомфорт. Особенно, когда они попадаются на горячем. В целом, хорошо, что я плохо схожусь с людьми. Для себя я определила, что есть мой отдел (за которым мне не поручат следить) и есть остальные. Всех предупреждали. Ясно, что инфа, скажем, по посещенным сайтам, предоставляется только по заказу руководства. Но вот слив информации (как в истории с Почтой России, например) – повод для сообщения безопасникам. А как эту дилемму решаете вы?


Вопрос номер 4 частично связан с предыдущим. Это разделение личного и рабочего. С этим мне помог научный руководитель в своё время. Какими бы вы приятелями не были, сколько бы пива не выпили, но личные отношения остаются личными. А по работе у вас есть рабочие обязанности, приказы должны исполняться, отчеты делаться и права урезаться. Да, в среде ИТ обычно неформальные отношения, но это не должно мешать работе или создавать дыры в безопасности.


Вопрос номер 5 – взаимоисключающие требования руководства. Хорошо, если это решается письмом непосредственному руководителю. Но вот, например, дилемма: равные по иерархии начальники просят доступ к шаре служб друг друга (например, финансисты и кадровая служба). И оба же категорически запрещают доступ других служб к своей шаре. Оба они мне не начальники, мои предложения по созданию им папки обмена слушают не всегда. Мой руководитель также не может выдать решение, так как решить в любую сторону – нарушить указания обоих. Обычно таки решается созданием папки обмена (иным компромиссным решением при схожих ситуациях). Как вы разрешаете такие вопросы?


Вопросы номер 6 и 7 на самом деле связаны – это обучение сотрудников и документирование. Под обучением я имею в виду именно передачу знаний среди своих же сотрудников от старших/знающих к младшим/не знающим. Собственно, два аспекта: вы не обучаете и думаете, что незаменимы; или вы обучаете, получаете квалифицированных сотрудников и учитесь сами чему-то новому. Короче, я за обучение. Под документированием я имею в виду составление схем сетей, сводок информации, документирование всех нетипичных действий с системами. То есть, если я уеду в отпуск в горы без связи, кто-то из коллег, пользуясь документацией, сможет сделать то, что делала обычно только я. И да, меня можно уволить, а документация останется. Я считаю это правильным. А вы?


Вопрос номер 8 – отношение к пользователям. Ладно, это не про сисадмина, а про эникейщика. Но он может работать у вас в отделе, или вы можете его иногда подменять на время отпуска. Честно, я ругаю за стёб над пользователями и издевательские шутки. У себя внутри отдела можно обсудить их умственные способности в каких угодно выражениях, но с пользователями будь вежлив и считай, что у них нет чувства юмора.


Вопрос 9 - взаимоотношение с внешними системами. Сюда включу 2 аспекта. Первый – настройка систем, влияющих на внешнюю сеть. Это ваша внешняя зона DNS, настройка внешних IP-адресов, почтовик, возможно, у кого-то BGP. Я не беру телеком, я про обычные конторы. Принцип: не знаешь – не настраивай наобум. От этого зависит работа не только вашей конторы, но и корректная работа Интернет в целом. Второй аспект – взаимодействие с сообществом. Принцип: знаешь, как решить – поделись решением.


Пишите, кто как относится к перечисленным вопросам. У кого какие ещё этические проблемы или моральные дилеммы возникают в связи с профессиональной деятельностью?

Показать полностью
316

Администрирование #05. DNS.

Я опять, как и в статье про DHCP, постараюсь идти от сильного упрощения к менее сильному упрощению. Статья ориентирована на уровень студентов и начинающих админов. Я не буду затрагивать вопросы безопасности или конкретной реализации, но постараюсь затронуть те вопросы, которые «проскакивают», либо вовсе игнорируют популярные статьи типа «что такое DNS».


Часть 1. История.


Наиболее увлекательное художественное описание того, как всё начиналось, доступно в rfc1034.

В давние времена, когда сети были маленькими, а компьютеры большими, кто-то заметил, что, во-первых, IP-адреса запоминать не очень удобно (гораздо удобнее слова, которые имеют смысл), а во-вторых, надо бы как-то обозначать один объект с несколькими сетевыми адресами.


«Давай запишем в текстовый файл соответствия сетевых адресов и понятных человеку имён» - сказал кто-то.

«А давайте!» - ответили остальные.


Сейчас вы можете найти файл «hosts» у себя на компьютере и посмотреть в него – почти так всё и было. Люди запоминали имя, запрашивали по имени ресурс. Система смотрела в файлике соответствие имени и сетевого адреса и возвращала по имени адрес. За файлик назначили ответственного, он вносил туда изменения и раздавал через файлообменник свежую версию всем желающим.


А потом сеть стала расти. Файлик стал очень большой и грозил увеличиваться дальше стремительными темпами, долго скачивался (потому что каналы передачи данных были узкие), поиск по файлу становился затрудненным, изменения вносились не сразу (у ответственного бывает выходной, праздник и болеющий ребенок), а еще корпорациям хотелось иметь свой файлик с шахматами и поэтессами внутренними ресурсами, недоступный никому извне.


«Идите в жопу» - сказал ответственный.

«Вот дерьмо, как же быть?» - подумали остальные.


И придумали DNS – Domain Name System – систему доменных имён. Люди были не дураки. Они подумали: «если мы уж внедряем такую сложную систему, на которую потребуется выделить бабло, давайте запихаем туда всё, связанное с именованием ресурсов!». И запихнули.


Что получилось. Общий смысл остался – по имени возвращается адрес. Теперь доменное имя стало состоять из частей, разделенных точкой (Например, pikabu.ru) и за каждую часть (домен определенного уровня иерархии, уровни нумеруются справа налево) стал отвечать свой сервер имён со своим персональным ответственным (на самом деле, всё немного сложнее, разберем в следующих частях). Система стала распределенной и иерархической. Запрос адреса по имени стало возможным разбить на части, и, пройдясь по цепочке серверов имён, найти нужный с нужным ответом. Каждый ответственный теперь мог менять свой кусочек информации, независимо от остальных. В зависимости от настроек, эта информация становилась доступной для всех через некоторое время. К записи о домене добавили дополнительную информацию: информацию о почтовых серверах, о доступных ресурсах, о псевдонимах, служебную информацию и т.д. Корпорации теперь могли делать так, что изнутри на запрос отвечал один сервер имён, а снаружи компании на тот же самый запрос отвечал другой сервер и возвращал другой адрес.


Сформулируем, зачем нужен DNS:

1) Чтобы при вводе имени сайта, например, pikabu.ru, в браузере, система могла понять, на какой сетевой адрес «стучаться»

2) Чтобы при вводе синонима имени сайта www.pikabu.ru, система могла понять, что это имя всё равно, что pikabu.ru

3) Чтобы когда вы отсылаете письма с яндекса на gmail, сервер яндекса знал, на какой сетевой адрес отправить письмо, то есть, где искать почтовый сервер gmail’a

4) Чтобы в ответ, почтовый сервер gmail мог проверить, что адрес, с которого пришло письмо, принадлежит почтовому серверу яндекса.

5) Чтобы при каких-либо проблемах с данной системой, можно было узнать контакты ответственного лица и связаться с ним


«А давайте будем брать за запись о домене деньги?» - подумал кто-то хваткий. И в чьих-то глазах зажглись зеленые искры в виде долларов. Но это уже совсем другая история.


Часть 2. Домен, зона и другие страшные слова.


Отойдём от абстракций и перейдем к конкретике. Зона – это набор ресурсных записей домена, то есть, фактически – это информация о домене и вся та сопутствующая лабуда, о которой мы говорили в части 1. Причем, заметьте, домен в нашем случае, это не «pikabu», а именно «pikabu.ru», так как, скажем, «pikabu.net» - это уже совсем другой домен. Это как директория «помойка» может лежать у вас как на диске C:\, так и на диске D:\ и это будут две разные директории. Зона может быть текстовым файликом или записью в базе данных сервера имён.

Выглядит, примерно так (мне не жалко):

Администрирование #05. DNS. Системное администрирование, Для начинающих, DNS, Сети, Длиннопост

@ означает подставить имя домена целиком


Ресурсная запись (Resource Record – RR) - собственно, информация о некотором ресурсе- состоит из нескольких полей: Владелец, Тип, Класс, TTL, данные. Владелец – это домен, к которому запись относится. Тип может быть одним из стандартных (например, A, AAAA, MX, NS, SOA, TXT и т.д.). Класс раньше разделял записи для Интернет и для других сетей, сейчас, вроде, используется только IN для Интернет. TTL – время, на которое запись разрешено закэшировать резолверу (рекурсивному кэширующему серверу, см. Часть 3). Ну и данные – собственно нужная информация, формат которой зависит от типа записи.


Запись SOA (Start Of Authority) – это начальная запись зоны и она должна быть обязательно, потому остановимся на ней подробнее. В ней содержится целый ряд полей:


- Первичный (Primary) DNS-сервер для некоторой зоны — DNS-сервер, на котором хранится полная исходная информация об этой зоне.

- e-mail ответственного лица

- serial – серийный номер зоны. Фактически, это номер изменения файла зоны. Если у главного DNS-сервера, отвечающего за зону, есть подчиненные сервера, то они периодически сравнивают номер копии зоны у себя с номером на главном сервере. Если на главном номер больше – подчиненные сервера обновляют у себя зону.

- refresh – это то, как часто подчиненные сервера будут пытаться обновить зону

- retry – это то, как часто подчиненные сервера будут пытаться обновить зону, если в первый раз произошла ошибка (например, главный сервер был недоступен)

- expire – то, сколько времени подчиненный сервер может считать информацию о зоне актуальной, если главный сервер ему так и не ответил

- TTL – мы уже говорили – на сколько можно закэшировать запись.

Администрирование #05. DNS. Системное администрирование, Для начинающих, DNS, Сети, Длиннопост

NS – записи содержат сведения о DNS-серверах, где хранится информация о зоне (их может быть больше одного).

Администрирование #05. DNS. Системное администрирование, Для начинающих, DNS, Сети, Длиннопост

А – запись связывает имя с IPv4 адресом. Кстати, если сделать несколько записей с одним именем, но разными адресами, то в ответах они будут чередоваться (чаще всего по алгоритму round robin) – поэкспериментируйте на pikabu.ru и его трех адресах ;)


MX – записи определяют имена почтовых серверов для данного домена (а чтобы узнать их адреса, на почтовые сервера должны быть А-записи в соответствующем домене). Эти записи примечательны тем, что у них есть приоритет (чем меньше приоритет – тем главнее сервер, равный приоритет – распределение нагрузки).

Администрирование #05. DNS. Системное администрирование, Для начинающих, DNS, Сети, Длиннопост

Чуть позже рассмотрим еще PTR записи. Ну а про остальные, если интересно, можно прочитать в вики.


Часть 3. Как идёт запрос.


Пока у нас есть куча не особо связанных между собой кусков. Сейчас определим еще пару понятий и попробуем посмотреть, как система работает в целом. Вообще, у кого английский хоть на базовом уровне, советую посмотреть зашибенный комикс в шести частях + бонус.


Вы уже поняли, что в системе есть DNS-сервера – сервера имён, на которых хранятся файлы зон. Есть клиенты, которые пытаются узнать адрес по имени (браузер, в котором мы шароебимся по сайтикам, например).


DNS-сервера бывают рекурсивными (которые могут пройтись по всей цепочке и вернуть готовый ответ) и нерекурсивными (которые возвращают информацию о DNS-серверах, ответственных за следующую зону). А еще DNS-сервера бывают кэширующими (которые на время запоминают те ответы, которые через них проходят) и некэширующими (угадайте..).


Вспоминаем, что система DNS иерархическая. У этой иерархии есть вершина (или корень) – корневая зона, за которой зарезервировано нулевое имя, и за которую отвечают корневые сервера. Эта зона невидимо присутствует во всех доменных именах - на самом деле, все они заканчивают на точку-ничего (можно посмотреть на первую картинку с файлом зоны и увидеть эти точки). Корневые сервера содержат информацию о доменах первого уровня (ru, com, net и т.д.). Этих серверов всего 13 штук (но физически их гораздо больше – резервирование, распределение нагрузки, всё такое). Почему 13? Так исторически сложилось: тогда максимальное количество данных в пакете было 512 байт и туда влезало только 13 записей. Корневые сервера нерекурсивные и некэширующие, кстати.


И сейчас я кратенько перескажу тот самый комикс. Итак, вы вводите в своем любимом браузере адрес любимого сайта pikabu.ru – что же происходит с точки зрения DNS?


1) Браузер роется у себя в кэше – может, вы недавно уже заходили на пикабу и он это еще помнит. Если нет, идем дальше.


2) Потом браузер обращается с животрепещущим вопросом «где же pikabu.ru?» к операционной системе. Она проверяет в своём кэше (может, вы недавно пинговали пикабу?) и в файлике hosts. Если не нашла, передает вопрос тому серверу, который у вас указан на компьютере в качестве DNS.


3) Этот сервер, обычно, сервер провайдера, кэширующий и рекурсивный. То есть, он вернет вам адрес сайта или ошибку. Сначала он проверяет свой кэш (может, ваш сосед по общаге только что запрашивал пикабу?). А еще смотрит в своих зонах (может, он за пикабу и отвечает?). Если ничего не находит, этот сервер начинает собирать ответ, используя нерекурсивные запросы.


4) Первым делом, запрос отправляется на ближайший корневой сервер (вру, там еще есть манипуляции с кэшем, но мы их опустим - пусть ничего нигде не найдено). Адреса корневых серверов известны и меняются очень редко, так что они просто забиты руками во все DNS-сервера. Корневой сервер отвечает, что он в душе не знает адреса «pikabu.ru», но вот тебе список серверов, отвечающих за «ru». Кстати, возвращает он имена и «приклеенные» ip-адреса, а то вы могли бы зациклится в своих запросах.

Администрирование #05. DNS. Системное администрирование, Для начинающих, DNS, Сети, Длиннопост

Кстати, слышали, что rpin вроде как передает права на управление зоной ru Ростелекому?


5) Ок, наш сервер сохранил инфу в кэше (и теперь за всеми сайтами, заканчивающимися на .ru будет обращаться уже к этим серверам). Берет верхний сервер из списка и спрашивает его, где же «pikabu.ru»? Ему отвечают списком из трех адресов, он возвращает верхний операционной системе. Все счастливы, все прописали себе в кэш, что могли, подключаемся к этому IP-адресу и читаем пикабу.


Часть 4. Обратная зона.


Случается так, что нам нужна обратная процедура: не по имени узнать адрес, а по адресу имя. Такие запросы, в частности, используют почтовые сервера, чтобы бороться со спамом. То есть, приходит нам письмо от vasya@gaza.net, например, с адреса 1.23.45.6. И мы хотим узнать, а правда ли адрес 1.23.45.6 является адресом почтового сервера этого домена. Для этого нам надо получить имя по адресу 1.23.45.6 и сравнить его с MX-записью домена (кто заморачивается почтовиками, почитайте еще про spf обязательно).


Для преобразования ip-адресов в имена существует специальный домен in-addr.arpa и специальная запись типа PTR. Как это выглядит, видно на скриншоте. У пикабу, кстати, какая-то лажа с его гуглопочтой, так что пример на другом домене (надеюсь, они не обидятся). Обратите внимание, что IP-адрес переворачивается (задача для самостоятельного раздумья – вспомнить про адресацию и понять, почему).

Администрирование #05. DNS. Системное администрирование, Для начинающих, DNS, Сети, Длиннопост

Часть 5. Внутренняя зона – что за зверь?


Это немножко вбоквел. Например, вы зарегистрировали домен не для себя, а для компании. В компании решили организовать доменную структуру (AD поднять, например). И для этой доменной структуры у вас появляется внутренняя зона DNS. Зона, причем, может быть та же самая, что и в инете, но к той интернетовской зоне она не будет иметь никакого отношения. У вас появляются контроллеры домена (или иные DNS-сервера – держатели внутренней зоны) в вашей локальной сети. На всех компьютерах вашей организации в качестве DNS-серверов вы указываете контроллеры домена (на которых поднята роль DNS). Во внутренней зоне находятся записи внутренних ресурсов: все компьютере в домене, внутренние web-порталы, и т.д. На DNS-серверах корпорации указаны «Forwarders» - сервера, на которые пойдет запрос, если ответа не найдется во внутренней зоне (это уже сервера провайдера, обычно).


Ну, предположим, что pikabu.ru – большая корпорация, в которой есть доменная структура и вы в этой корпорации работаете. Если вы изнутри этой зоны (сидя на работе) выполните команду «nslookup pikabu.ru», вы получите список внутренних DNS-серверов компании, а на сайт пикабушечки не попадёте. Всё потому, что вам ответит внутренний сервер компании, в котором прописано, что «pikabu.ru – это ж я сам и есть, а еще все мои дублирующие сервера!». А вот если вы выполните эту команду из дома, получите внешние адреса пикабу – потому что вам ответит DNS-сервер хостинг-провайдера.


Теперь, предположим, вы с работы набрали www.pikabu.ru. Допустим, у вас в корпорации нет компа с именем www и внутреннего ресурса такого тоже нет. Корпоративный DNS не найдет у себя в зоне записи www и перенаправит запрос на адрес форварда. Мы помним, что это адрес сервера провайдера. И вот тут ответ будет идентичный, что изнутри, что снаружи корпорации, потому что мы искали во внешней зоне.


И третий вариант, у вас в домене есть компьютер W01-vasya-PC.pikabu.ru. Изнутри компании вам внутренний DNS вернет его внутренний адрес. А вот запрос извне "Где W01-vasya-PC.pikabu.ru?" вернет вам "такого хоста не существует" - потому что DNS хостинг-провайдера, где находится ваша внешняя зона pikabu.ru (и куда в конце-концов дочапает DNS-запрос) понятия не имеет о вашей внутренней зоне.


Часть 6. Интересные факты:


Сейчас для распределения нагрузки на корневые сервера используется anycast – это такая публикация маршрутов в сети (BGP), при которой, вам ответит географически ближайший сервер, а не тот, до которого маршрут по некоторым причинам короче.


Максимальное имя поддомена 63 символа, максимальное общее доменное имя 255 символов.


Обычно, обратную зону надо просить прописывать своего провайдера. Но есть вариант, при котором провайдер делает у себя пару записей, а вы после этого можете менять PTR-запись прям у себя в админке родного DNS от хостинг-провайдера (ну, насколько я поняла). Статья вот.


P.S.: Что-то дофига получилось, мда. Надеюсь, кому-то стало понятнее. Правки по существу приветствуются.

Показать полностью 6
121

Infinity Call Center

Infinity? А, знаю — редкостное говнище!

(с) Один знакомый программист.


Честное слово, вначале я не хотела портить репутацию программному продукту и пилить пост на пикабу. Но потом подумала, что всё это я хотела бы прочитать до того, как мы решили его купить и внедрить. Это не значит, что мы бы его тогда не купили, просто хотелось бы знать, к чему готовиться.


Осторожно, ненормативная лексика!


Всё ниженаписанное – исключительно моё субъективное мнение.


Чтоб не начинать с чернухи, кое-какие плюсы всё же есть. На мой взгляд, если вам нужен типовой (совсем типовой) Call-центр в ваш небольшой интернет-магазин для впаривания чего-нибудь, то Инфинити вам в общем-то подойдёт. Одну из типовых конфигураций самую малость подпилят под вас, покажут, где менять файлики с текстом впаривания и на этом всё. Реально, под стандартные задачи есть даже какие-никакие инструкции на сайте, жить можно.


Опять же, Инфинити у нас работает и не так плохо, как может показаться из моего поста. Но подгорает-то не от положительных моментов.

А теперь о том, что мне радикально не понравилось. То есть, о минусах.


Сначала, как всегда приходят люди с красивой презентацией. Ясен перец, 50% минимум там либо не упоминается, либо враньё, потому на основных вопросах акцентируемся в диалоге и уточняем несколько раз.


(мы): Будет работать на слабом интернет-канале?

(Инфинити): Конечно, будет! Если там работает IP-телефония, то будет работать и наш клиент.

(мы): Реально маленький канал, до 1 мегабита. IP-телефония работает без нареканий, даже два телефона одновременно.

(Инфинити): тогда вообще без проблем. Мы же сказали, если IP-телефония работает, то и наш клиент будет.


Итог: враньё. 5 мегабит минимум для какой-никакой нормальной работы. Ну, в три можно попробовать ужаться. Клиент на Чукотке (или на 3g модеме в зоне нелучшего приёма) запускается примерно 1:40м (один час сорок минут). Это просто запуск клиента – он грузит свои модули с сервера, судя по всему. А если запуск оборвался, то заново. Карточка позвонившего грузится от 10 до 40 минут (потому что кэп говорит, что мегабит - это не только для инфити, да и не всегда он доступен целиком). Когда обратили на это внимание поддержки, они сказали что-то типа «ну мы ж не думали, что там реально мегабит». Мы решили отдельно запуском софтофона на месте, а клиент инфинити запускается в терминалке через RemoteApp.


И еще о скорости работы и карточках клиента. У нас в карточку подгружается по номеру телефона инфа о клиенте. Ну там, ФИО, пол, возраст и некоторая сопроводиловка. Всего текста на страничку А4 в худшем случае – ничего экстраординарного, никаких фоток и прочей ереси. Филиалы замучили жалобами на медленную загрузку карточки. Глянули Wireshark’ом. 9 мегабайт! Как можно раздуть кусок текста до 9 мегабайт?! Мы даже спросили, может они скриншоты карточки в HD там гоняют? Специально для нас разработчики оптимизировали передачу информации в карточке клиента (до 5 мегабайт на штуку). Тогда-то у нас и стал клиент сносно работать на канале в 4-5 мегабит. То есть, у вас без оптимизации будет та же лажа. Наших программеров оттаскивали от телефона под вопли «дайте мне 10% от цены поддержки и я научу программировать их сраных программистов!».


Внедрение. Как ни странно, внедрение отработали нормально. То есть, хотелки из ТЗ более-менее учтены, правки оперативно вносились. Минус – гонят быстрее провести обучение админов (у нас входило в стоимость 2, кажется, дня обучения). То есть, система еще на стадии подгона под хотелки, в релиз не запущена, трогать ничего нельзя, а вас уже учат с ней работать. Учат на типовой конфигурации и простых примерах, ваши задачи ни разу не учитывают.


Дальше – полный мрак. Система запускается в работу. Ок, первые пробные запуски нормально. Переходим на Инфинити ииии… Специалист техподдержки с вами ровно до 18:00. Вроде бы и ничего страшного, все мы люди. Но мы помним, что после запуска в реальную работу обязательно вылезут косяки. Кредо Инфинити: «Накатим изменения на живую систему в скрипт, который запускается в ночное время. Проверять, конечно, не будем. Трубку брать тоже, мы же работаем с 10 до 18». То есть вам днём, часто не сообщая об этом, вносят изменения в систему. Ночью у вас работает другая логика (с дежурными операторами и другим автоответчиком, например) и всё в 18:00 ломается. Звонки идут в тишину, «набранный номер не существует», сброс звонка через 15 секунд, звонки Москвы идут на Хабаровск – выбери своё, что называется. А в 18:01 уже никто не возьмет трубку и не заглянет в трекер, будь там хоть какой статус у заявки. Тут вариант только разбираться самим и править их свежие косяки «на коленке». Еще можно попытаться вернуть старую логику и тут мы плавно подходим к следующему минусу.


Отсутствие лога изменений. Даже банальной даты создания/изменения скрипта нет. В принципе, если углубиться, то можно найти скомпилированные скрипты в папке Инфинити и посмотреть дату создания файла. Но в самой системе ничего подобного нет. Мы настойчиво попросили писать в поле комментария строку типа «15.04.2016 14:20, сделано то-то. Вася.».


Итак, вы немного освоились, система перестала отрубаться по 3 раза в неделю, и вы решаетесь внести изменения. Ну, потому что надо же когда-то начинать, вы же платите за поддержку, а не за то, чтобы вам вносили изменения, отличные от ТЗ. Например, вам надо что-то чуток изменить в основном скрипте. Вы копируете последнюю версию, открываете иии… Б@#!!! Ну, вы видели значок Хабра? Где что-то среднее между клубочком и Ктулху? Вот что-то подобное вы и наблюдаете. При попытке разобраться, то есть врубить на компонентах отображение направления движения, всё намертво зависает. Оперативки дохрена, а интерфейс её не хавает. Либо шевелите мышкой, либо на экране бегают пузырики данных. Ау, программеры Инфинити! Меня на втором курсе учили, что отображение данных и обработка нажатий пользователя должна быть в разных потоках, чтоб интерфейс «не вис». Ладно, пофиг. Мне потребовалось примерно 10 рабочих часов, чтоб вынести половину в отдельный скрипт и «причесать» остальной трешак. Почему так много? Так я была разбалована Visual Studio, теперь-то скилл прокачан. Сообщаю, здесь нет копи-паста. Ладно, в соседний скрипт скопировать нельзя, но тут нет копи-пасты даже в рамках одного скрипта. То есть, если вам нужно 20 одинаковых компонентов, которые различаются только одним параметром (из 10), то вам 20 раз надо настроить 10 параметров. Скопировать нельзя. Ага, а исходный код можно посмотреть (есть секретная комбинация: зажать Ctrl и нажать иконку сохранения). Код на плюсах, казалось бы – поправь, вставь, скомпилируй! Хрен там, посмотреть можно, скопировать можно, вставить – нет. «Это слишком сложные компоненты».


Итак, пришло время для серьезных изменений! Вы открываете документацию… стойте, где же она? Наверное, на сайте? Нет, там только вики по «стандартным решениям» — в основном, как звонить и пользоваться клиентом. Ну и немного по основным компонентам в стиле «компонент «поднять трубку» используется для того, чтобы поднять трубку». Наверное, нам забыли выслать документацию. Звоним в поддержку и получаем чудесный ответ: «А она еще не написана, в общем то мы и не собирались.» Короче, мы выцыганили примерное описание БД «на отъебись» - только часть баз и таблиц, которые техподдержке показались наиболее значимыми — и это всё. Ни документации системы в целом, ни нашей модификации – ничего этого нет в природе.


Отлично, вы материтесь каждый день, но стокгольмский сидром берет своё, да и просто приноровились к этой чудо-системе. И тут вам начинают жаловаться на неуловимые глюки. Ну там, отчеты врут или звук пропадает. Вы заводите тикет в поддержке, а в ответ тишина. Ну то есть, он даже не принят в работу. День-два-неделя – ноль реакции. Звоните, а в ответ «решаются более приоритетные задачи». Эмм, заглядываете в договор. За поддержку отвалено более полуляма, хоть и российских, но денег – люди как бы не бесплатно работают. После этапа внедрения техподдержка у вас практически отсутствует. У нас, например, начались (и продолжаются) внезапные падения сервиса. То есть, все клиенты зависают, а звонки идут в тишину. При этом переключения на резервный номер не происходит, потому что звонки-то приземляются. Помогает только физический ребут сервера. Реакция на проблему с уровнем «фатально» была до недели (не решение – просто начало работы с заявкой). На более мелкие – от нескольких дней до трех месяцев (бонус в комментариях). Получите сервис за пол-лимона, называется. Ладно, к их чести, менеджер проблему признал (когда мы отказались платить за следующий год, раньше жалобы не помогали). И нам дали три месяца бесплатной поддержки в компенсацию. Стало намного лучше, реакция день-в-день или на следующий. Но! Опять, черт возьми, их эксперименты на живой системе. «Этот скрипт не должен был его уронить, там ничего такого». Конечно, только после его запуска на полдня лёг сервер совместно с номером 8-800 (потому что, чтоб починить, надо было, чтоб звонки шли – логи отслеживать). Опять спрашиваю, у вас что, мощностей на виртуалку нет? Взяли и протестировали бы. Ну, «всё сложно с этим». Лень, я понимаю (правда понимаю, но вы ж, нехорошие люди, за это деньги берёте!).


Ну и еще немного. Техподдержка работает в Инфинити под админской учеткой (что логично). Но если у вас куплена одна админская учетка – вы идете лесом, одновременно работать нельзя. Мы им предложили – да добавьте нам одну лицензию под своего сотрудника! Куплено 120 лицух по 14к каждая. Когда их тоже заколебало, что я постоянно прошу освободить лицуху, нам милостиво предложили сделать одну из наших лицензий администратором (ну хренли, 580к за поддержку + 14к, чтобы она могла работать удобненкько и минус лицуха, которая посчитана для оператора).


Первый чувак из техподдержки нам еще врал, что бэкап делается только с полной остановкой сервера и только из web-интерфейса. Хорошо, следующий сознался, что всё это не обязательно.


А, да, еще полная несовместимость с Каспером (да и со стандартным виндовым firewall тоже). В исключение надо прописывать кучу всего. И всё равно, буквально в начале января в экзешнике задетектился троян. Техподдержка «логично» говорит, что «уберите его в исключения и уведомления антивируса не будут вас беспокоить». Ну конечно, как мы не догадались, не троян же это у них сидит, в самом деле!


Из более свежего. Присылают тут скрипт перезапуска служб (правда же, если за год не разобрались, почему сервер падает, давайте будем просто регулярно перезапускать службы). Вот как бы вы добавили в батник паузу? SLEEP? TIMEOUT? Не наш метод! «ping -n 1 -w 10000 192.168.254.254 >null» — вот супер-метод с ответов мэил.ру! На вопрос, что это за хрень? Ответ: «Это проверенный временем скрипт, мы рекомендуем использовать именно его». Не, конечно, можно и гландны через жопу удалить, вопрос — надо ли?


Чтобы запилить свой отчет вам понадобятся навыки SQL (немного) и навыки экстрасенса (много). К счастью, у меня был под рукой гуру-SQL’щик и прокаченый скилл чтения мыслей.


Из самого свежего. Из одного скрипта надо запустить скрипт поствызывной обработки (это типа «дайте оценку оператору от хорошо до прекрасно, спасибо, что вы с нами»). И сюрприз – ошибка компиляции, вы пытаетесь привести тип Int64 к Integer. Знаете, в какой переменной приведение? В ID скрипта! То есть (как я предполагаю), сделали сначала Int на ID, замутили вызов функции. Потом подумали через несколько лет, а вдруг Integer не хватит? Давай замутим Int64! А в прототипе функции никто ничего не менял. Хуле тестировать, в самом-то деле. Решение – «скопируйте функционал в наш старый скрипт, там ID нужного типа, или забейте, авось не выйдете за диапазон» (второй вариант сработал). Ну, тикет еще в работе, может всё не так, как я додумала, а может всё так, но поправят.


Передать переменную в скрипт, который вызывается особым образом (причем непонятно, почему именно тут его надо вызывать по-другому)? Функционал не предусмотрен. Ну ведь есть же аргументы командной строки, ну почему?!


Из свежих плюсов: новый специалист поддержки, Андрей, отвечает реально быстро, более-менее по делу и даже обратил внимание на одну неточность у меня в скрипте (эх, была бы документация!) – прогресс налицо. Но остального не отменяет.


Итог.. Да нет итога. Работаем с чем есть, я уже относительно разобралась и ваяю скрипты. Наверное, есть много недокументированных возможностей, которые облегчают работу, но их надо еще найти. Гуру-SQL’щик помог запилить отчеты. Всегда приходил на помощь наш цискарь, чтобы снять с инфинити как можно больше функционала (и помедитировать со мной на логи wireshark с ошибками). В общем, для типовой конфигурации с операторами на жирных интернет-каналах можно. Для специфического чего-нибудь с перспективой допиливания своими силами – не советую.


Чуток ответов на вероятные вопросы:


Почему не запилили свою систему? Надо было относительно срочно (за полгода), а программистов отрывать от дела запретили (на них два крупных внутренних программных продукта, очень специфичных и постоянно меняющихся в связи с изменениями в законодательстве + несколько мелких). Нам дали двух программеров на пару месяцев для интеграции с нашей БД. Надо было не только интеграцию, но и красивую мордаху, красивые отчеты и классический функционал call-центра (статусы, учет рабочего времени, скрипты, карточки клиента – вот это всё).


Почему не спросили про документацию? Спросили. Нам сказали, что она есть. Да, мы лошары и поверили.


Почему столько негатива, не всё ж так плохо? Потому что, про то, как инфинити решил все проблемы и погнал бизнес в гору, можно прочитать на сайте Инфинити.


Я ни в коем случае не призываю к написанию других негативных отзывов и не говорю, что данный продукт вообще нельзя применять. Просто подумайте, подходит ли он лично вам в вашей ситуации и оговорите нюансы оказания технической поддержки заранее (в договоре).


Бонус, напоминаю, в комментариях.

Показать полностью
95

Верхняя Пышма - Москва

В декабре меня дёрнуло поучаствовать в обмене (для совсем-совсем опоздавших). Посылку я отправила, а обратного трека особо и не ждала - шутка ли, первый раз и чтоб повезло? А вот повезло, пришел мне трек, а потом и посылка их Верхней Пышмы (я сразу полезла в карту - это возле Екатеринбурга).

Верхняя Пышма - Москва Обмен подарками, Анонимный дедмороз, Тайный Санта, Длиннопост

Кот вертелся, но я его поймала таки в кадр. Открываем, а за нож цепляется что-то меховое (ещё один кот?!). А, нет, это плед! Теплый и мягкий, чтобы долгими зимними вечерами залипать в пикабушечку.

Верхняя Пышма - Москва Обмен подарками, Анонимный дедмороз, Тайный Санта, Длиннопост

У меня теперь есть "План Б" с текилой =)

С шоколадом прям угадал - люблю горький! Большая шоколадка просто "с начинкой", полезла читать состав - интересно же! Глаза сразу зацепились за фразу "состав начинки: .., спирт этиловый", короче, шоколадка от нервов - самое то, что надо, поберегу на 9 января, чтобы облегчить переход к рабочему состоянию.

Верхняя Пышма - Москва Обмен подарками, Анонимный дедмороз, Тайный Санта, Длиннопост

И книжка! Сто лет в бумаге художественную литературу не читала, давно всё в электронке, воскрешу забытые ощущения =) Кстати, не читала и фильм не смотрела, так что угадал.

А в коробке с M&M's оказывается целый набор "для мозговой деятельности"!

Верхняя Пышма - Москва Обмен подарками, Анонимный дедмороз, Тайный Санта, Длиннопост

Магнитики с собакенами уехали в достойную компанию.

Верхняя Пышма - Москва Обмен подарками, Анонимный дедмороз, Тайный Санта, Длиннопост

Ну а кот коробку проигнорировал.

Верхняя Пышма - Москва Обмен подарками, Анонимный дедмороз, Тайный Санта, Длиннопост

Спасибо за подарки, @wa1n261, было круто!

Показать полностью 4
8613

Про хороших родителей (без всяких кавычек)

Хочется немного разбавить грустные истории на пикабу. Мне всегда говорили друзья: «virrasha, у тебя золотые родители!». И таки да.


Единственное, что мама не одобряла – это «мальчишечьи» увлечения. Но это никогда не принимало категоричных форм и не мешало «Деду Морозу» приносить часы с черепашками ниндзя, динозавров или радиоуправляемую машинку. Где-то ко второму классу мама признала за мной возможность выбирать, что носить из одежды и у нас сошли на нет последние конфликты.


Родители приобщили меня к чтению – только недавно рассказали, что «операция Гарри Поттер», с которого всё началось была ими придумана от и до. Это был «подслушанный» мною диалог между родителями типа «А вот помнишь ты мне недавно посоветовал книжку про мальчика-волшебника? Такая интересная! Ему 11 лет, прям как нашей дочке, представляешь?» и далее по тексту. А я - наивняк - верила, что от меня хотели скрыть что-то интересное XD.


Потом родители спохватились, что читаю я всякую дичь и, в основном, вместо уроков. Но и тут не стали накалять: мне выдали все книжки типа «готовые домашние задания» и «100500 готовых сочинений» и сказали, что я уже большая и могу сама распределять своё время, их не волнует, как именно и сколько я буду делать уроки, пока учусь без троек.


Кстати, про помощь с уроками. С математикой у меня не всегда было хорошо и то, что потом «попёрло» - заслуга папы. Я звонила ему на работу и предупреждала, что сегодня есть задача по геометрии (алгебре, физике), которая не даётся. Он говорил, чтобы я ставила будильник на 3 ночи, так как вернется поздно и предпочтет сначала поспать. В 3 часа мы вставали и шли разбирать задачу. Папа подробно объяснял, потом мы переворачивали листок и я должна была подробно и внятно рассказать, как же это решать. Итерации повторялись, пока я не могла четко объяснить свои действия. В результате этого у меня не было «пробелов» в знаниях и с 9 класса произошел качественный скачок – я внезапно стала всё понимать сама. А как вы делаете уроки с ребенком?


Мои дневники никогда не читали, кстати. Даже со школьным надо было бегать за мамой, чтобы она посмотрела, а не просто подписала не глядя.


Папа был модератором одного крупного форума, меня часто брали с собой на разные «митинги» (форумные встречи) – и на природу, и в бар. Мне было мега-интересно! Родители говорят, я им совсем не мешала, меня просто можно было всюду взять с собой =) Не знаю, конечно, может расстраивать не хотят.


Папа втихую от мамы купил мне первый складной нож, я была так рада! А мама давала жизненные советы по разным конфликтным ситуациям и выслушивала всякие «он таак посмотрел!».


В 14 лет мне сказали, что «мы радикально против курения, но если хочешь попробовать, то папа купит тебе сигарет». Не захотела.


На 16 лет мне подарили пачку презервативов со словами «мы против половых отношений до 18 лет, но если припрёт, то мы за безопасный секс, поэтому пусть будут», а мама провела ликбез на огурцах. Не пригодились.


Где-то с того же времени родители стали звонить и предупреждать, если аномально рано возвращались с работы.


Меня всюду отпускали с условием, что я говорю с кем, куда и на сколько иду. При этом родители тоже мне сообщали, куда идут. Просто безопасность большого города. Это выглядело примерно так: «Мы с компанией к username делать лабы в ночь, буду завтра вечером. Адрес такой-то.», «Хорошо, пришли смс вечером и утром, как доедешь до института». Однажды меня вечером позвали играть в преферанс. Мама сказала, что одну в криминальный район ночью на последнем автобусе меня не отпустит. И только я хотела встать в позу, как добавила, что лучше отвезет меня на машине, заодно будет знать адрес. И строго сказала, чтоб до 6 утра я на улицу не совалась, осталась там ночевать. Мы, кстати, и в правду играли в преф.

Про хороших родителей (без всяких кавычек) Родители, Родственники, Длиннопост

Мне разрешали собирать студенчески пьянки дома и не мешали нам при этом. На три моих дня рождения родители уезжали в дом отдыха на выходные, оставляя мне квартиру.


Вы пьянствовать в лес? Не понижай градус и напиши смс в 9, что всё в порядке.

Едешь на слет сисадминов? Кипяти воду и купайся выше по течению, чем находятся туалеты. Пиши смс два раза в день.


Когда я пошла работать, родители развернулись на полную: год они ходили на танцы, потом мама с подружкой осваивали кулинарные тренинги. Сейчас они пару раз в неделю ходят в караоке клуб, папа в лиге караокеров. Иногда мама говорит мне «мы с папой в клуб, пошли с нами, что ты как старая бабка!», а я отказываюсь, говорю, что лучше посплю, чем это «бумс-бумс» слушать))


Меня поддерживали в выборе друзей, института, работы, мне помогали и меня хвалили. Всегда были на моей стороне. Воспитывали? Ну, вроде как, не моральный урод получился. У меня лучшие родители – это точно!

Показать полностью 1
199

План адресации в учебных сетях - выдумка или реальность

С одной стороны, пост скорее для студентов. С другой же стороны, многие состоявшиеся специалисты никогда не задумывались о такой простой вещи, как адресация в учебных сетях.

Всё, что я здесь напишу – это сугубо моё личное мнение, которое не претендует на истину в последней инстанции. И да, тут будет много поясняющей воды.


Зайду издалека. Если вы проходите что-то связанное с сетями (или посещаете курсы, а может просто решили сварганить тестовую среду с друзьями под пивко), то рано или поздно дело доходит до практики – построения сети на живом оборудовании или во всяких там эмуляторах. Я сейчас буду рассматривать пример лабораторной в университете/на курсах. Итак, на доске рисуется некоторая схема сети, а дальше у нас два варианта:


1) Преподаватель расписывает всю-всю адресацию (рис.1)


2) Преподаватель расписывает концептуальное задание, а адресация остается на ваше усмотрение (рис.2)

План адресации в учебных сетях - выдумка или реальность Системное администрирование, Сети, Для начинающих, IT, План, Длиннопост
План адресации в учебных сетях - выдумка или реальность Системное администрирование, Сети, Для начинающих, IT, План, Длиннопост

Первый вариант понятен – за нас уже подумали. Но не факт, что хорошо (и мы всегда можем предложить свой вариант с преферансом и гимназистками – вдруг прокатит). Рассмотрим плюсы и минусы конкретного примера с рисунка 1 (синие кружки – хосты, оранжевое – линки, зеленое – сеть на самом хосте и «за ним»).


Плюсы:

1) Препод делал эту лабу раз 800 именно в таком виде и может отдебажить с закрытыми глазами

2) Возможно, у него уже написана методичка под эту адресацию.

3) В принципе, одинаковые IP для хостов (192.168.х.1) – это удобно.


Вообще, на мой взгляд, плюсы на этом заканчиваются (да и то: два из них для преподавателя, а третий сомнителен) и начинается полная Ж для нас:


1) Если вы видите и делаете эту лабу первый раз, у вас все десятые айпишники сливаются перед глазами. Мы делали во второй раз – просто при конфигурации интерфейсов на 4 человека и восемь интерфейсов было сделано три ошибки с перепутанной единичкой/двойкой.

2) При прописывании маршрутов эти описки множатся

3) Дебажить – просто ад. Постоянно пялиться на схему, сверять сети. Сети опять сливаются перед глазами. На слух тоже плохо воспринимаются адреса.

4) При усложнении конфигурации (добавлении пары ликнов, как на рис.2) вообще пропадает логика адресации. Только схема, только хардкор.


Подход, тем не менее, очень часто используется и имеет право на жизнь. Но теперь представьте, что вы уже не на первом курсе. У вас не 4 хоста, а 14, по числу студентов в группе и соединены они не по кругу, а как попало (рис.3). И задачи у вас посложнее.

План адресации в учебных сетях - выдумка или реальность Системное администрирование, Сети, Для начинающих, IT, План, Длиннопост

Немного вбоквел. На прошлой неделе я счастливо посещала курсы, на которых мы в очередной раз не сошлись с преподавателем в некоторых концептуальных вопросах. Его мнение – не стоит тратить время на такие глупости, как выбор толкового плана адресации, не надо усложнять, надо скорее делать, так как время не резиновое. Моё мнение – один раз расписать логику адресации (я делаю это уже на автомате и быстро), зато снизим ошибки конфигурации и облегчим дебаг. Победил преподаватель, расписав схему а-ля рис.1. Роман, если читаешь, извини, что я так громко возмущалась, но я до сих пор не согласна. Конец вбоквела.


Сейчас несколько общих советов, годных для любого плана адресации:


1) План адресации вам всё-таки нужен, иначе обязательно пойдут пересечения сетей, особенно «популярных», вроде 10.1.1.0/24


2) Выбирайте строго одного человека, который выберет план адресации, пусть даже хреновый. Время принятия решения возрастает в степени количества участников (один человек – 5 минут, 3 человека – 5^3=125 минут)


3) Не мельчите сетки и указывайте популярные маски, если иное не обозначено условиями задачи. В учебной сети нет цели сэкономить адреса. Помните, что вокруг вас люди, которые даже с калькулятором сетей не особо представляют себе, как одна сетка /25 делится на две /26. Короче, /24 – ваш безусловный выбор (если только вы не проходите тему агрегации сетей).


Теперь посмотрим на рис.4 – Это бывший рис.2 с расписанной альтернативной адресацией. И сейчас будут конкретные советы.

План адресации в учебных сетях - выдумка или реальность Системное администрирование, Сети, Для начинающих, IT, План, Длиннопост

В данном случае, план адресации сформулирован правилами:


1) На сеть между двумя хостами X и Y назначается адрес вида 10.1.XY.0/24, где X – номер меньшего по номеру хоста, а Y – адрес большего по номеру хоста.

2) На хост X назначается адрес 10.1.XY.Х/24, на хост Y адрес 10.1.XY.Y/24

3) VLAN между хостами имеет номер XY

4) Адрес сети за хостом имеет адрес вида 192.168.100+X.0/24

5) Адрес хоста во внутренней сети назначается 192.168.100+X.Х/24


Эта сеть легко расширяется. 100+Х мы брали, чтоб не пересечься с популярной дефолтной сеткой 192.168.1.0/24, на которой, скорее всего, висит сеть с инетом.


А внимательный пикабушник посмотрит на рисунок 3 и скажет, что данная схема нормально расширяется только до 9 хостов, а дальше мы имеем вероятность вылезти за рамки числа 254 в XY. НО! У нас же остался неиспользованный октет!


В сети более, чем на 9 хостов используйте правила:


1) На сеть между двумя хостами назначается адрес вида 10.X.Y.0/24, где X – номер меньшего по номеру хоста, а Y – адрес большего по номеру хоста.

2) На хост X назначается адрес 10.X.Y.Х/24, на хост Y адрес 10.X.Y.Y/24


Пример с рис.3: На линке между 12 и 9 хостами будет сеть 10.9.12.0/24, на 9ом будет адрес 10.9.12.9/24, а на 12ом 10.9.12.12/24.


И ещё несколько советов:

1) Используйте как можно более разные сети для связей разной природы. Скажем, 10.1.XY.0/24 для физических линков, а 172.16.XY.0/24 для навешивания на GRE туннели.

2) В схеме 10.X.Y.0/24 у вас еще есть запас сетей 10.100+X.100+Y.0/24

3) Аккуратно относитесь к номерам VLAN, если нумеруете хосты с нуля. VLAN 1 занят под native. И за к номерам за 1000 тоже аккуратно относитесь, лучше сделать пару исключений из логики, если пошли такие VLAN’ы.


Что мы получаем: Зная только номера хостов соседей можно спокойно расписывать себе адреса, пока они там телятся. Глядя только на схему с хостами и связями, можно прописывать на своей стороне уже всё, что надо (и не надо расписывать на доске адресацию по всем 14 хостам). В любом месте, запуская tcpdump (или аналог), мы по прилетающим адресам точно можем сказать, откуда они прилетели и быстро найти это место.


На мой взгляд, удобная и хорошо масштабируемая в рамках учебных задач схема.


Собственно, вот и всё, чем хотелось поделиться. Выбирать из этих или придумывать свой вариант – решать вам.

Показать полностью 3
150

История не о победе, а о траблшутинге

Недавно на работе обнаружился легкий трешачок. Как это было: внезапно посыпались заявки «не работает интернет». Быстро выяснилось, что с этих компьютеров прокся (Forefront TMG) не аллё – не пингуется. Методом научного тыка (самый быстрый метод) выясняли, что если пингануть проблемный комп с прокси – проблема уходит. Тестировать было некогда - вой не прекращался, так как 180 компов не напингуешься (конечно, скрипты, да. Интересно, стресс-собеседования проходят примерно так?), а пинг на широковещательный адрес нужного эффекта не давал. День мы продержались. Вечером ничего не нашли, к утру проблема не ушла, всех перекинули на резервный канал без всякой прокси и стали вдумчиво разбираться. Кого интересует чисто результат – пролистывайте вниз.


Что первое приходит в голову? Да сама прокся чудит. Добавлены несколько правил, впрямую разрешающие любой трафик из локальной сети к localhost и обратно, из локалки в локалку и т.д. Поднят им приоритет по самое некуда. Медитирую на простыню логов Forefront и тут вопрос: а где, собственно, request’ы? Не приходят. То есть, не режутся, а их вообще нет.


Прокся временно реабилитирована, но не забыта. Ставлю Wireshark на клиенте и на сервере и снова медитирую на простыню с пакетиками. Оппа, на клиенте arp-запрос who-has есть, а на сервере нет. То есть клиент спрашивает «у кого адрес 10.77.10.1?» широковещательно, а этот запрос приходит всем, кроме самой прокси! Ясен перец, ничего не пингуется – записи в arp-таблице у клиента нет.


Переставлены дрова на сетевую карту. Не помогло. Обновлён BIOS – аналогично. Смена IP – всё то же самое.


Под подозрение попал свич и я позвонила нашему цискарю. Свич был быстро реабилитирован, зато прибавилось идей.


Итак, для чистоты эксперимента был взят свич из коробки с дефолтными заводскими настройками и никогда не подключавшийся к нашей сети. В него воткнута прокся, ноутбук вне домена и еще раз ноутбук (через хвост USB-LAN). Зазеркалированы порты ноутбука и прокси в третий порт (как по очереди, так и оба сразу) и с третьего порта снят лог Wireshark’ом.


Результат: на порт сервера на свиче arp-запрос приходит, а вот на сам сервер уже нет. Как только с сервера уходит симметричный запрос who-has с адресом клиента, на сервер тут же проваливается клиентский запрос, с сервера уходит ответ с MAC-адресом и всё становится хорошо до протухания записи в arp-таблице клиента.


Что ещё проверено. С Debian live-cd ситуация ровно аналогичная. С другой виндой (уже без следов прокси) – тоже. С сетевого оборудования в качестве клиента тоже. При прописывании руками статической записи в arp-таблицу клиента всё работает. Кстати, вы знали, что «arp –s» в новой винде уже не работает? Вместо него используется команда powershell New-NetNeighbor.


Было также обращение в техподдержку производителей сервера. Сервак уже не на гарантии, но всё же. Посоветовали перевести IPMI из Failover в Dedicated. Не помогло.


Никто из моего окружения сказать в чем может быть проблема не смог, поэтому был сделан вывод «в физике» и с чистой совестью куплена еще одна сетевуха. На просторах инета находила еще две аналогичные ситуации, проблема там также не была решена.


Как можно обойти, если нет возможности заменить сетевуху: прописыванием на каком-нибудь сетевом оборудовании статической записи arp и перенаправлением всех клиентов через это оборудование. Или (если это прокся) в проблемный порт втыкается провод от провайдера и прописывается статическая запись у провайдера.


Всё происходило на материнке supermicro с одним из портов встроенной сетевухи. В тех двух случаях из инета тоже были материнки supermicro, так что какая-никакая, а статистика.


P.S.: для чего и кого этот пост? Для тех админов, которые, возможно, тоже с этим столкнутся. Чтоб была хоть какая информация на русском языке. Чтобы им было легче локализовать проблему. А может, кто и подскажет чего, чем черт не шутит - пикабу богат на таланты.

Показать полностью
28

Ошибка подключения vpn 720

Ошибка 720 у меня возникла после установки Eset (точнее после удаления каспера и замены его на eset). Есть два способа лечения: классический и неклассический. Первый мне помог в прошлый раз, когда устанавливался касперский, но в этот раз пришлось искать лучше. На всякий случай: испробовано только на Win8.1


Итак, способ номер раз (на него хватает инструкций в инете, но я кратенько повторю):


Открываем консоль от имени администратора и пишем команду:

netsh int ip reset reset.log


Если всё ок, то переходим ко второй команде:

netsh winsock reset


Если же на первую команду вывелось «Сброс - сбой. Отказано в доступе.» на любом этапе, то надо немножко поизвращаться. Скачиваем программу ProcessMonitor вот отсюда.

Запускаем её, отключаем всё, кроме событий, связанных с обращениями к реестру. И задаём два фильтра: «Process name is netsh.exe» и «result is ACCESS DENIED». После повторяем команду (или разбиваем её на две – для ipv4 и ipv6 соответственно).

Нам нужны две ветки реестра, которые отобразятся в программе. Надо открыть реестр (regedit), найти эти ветки, в контекстном меню выбрать «разрешения» и дать все права группе «все» (они пропадут после перезагрузки).

Ошибка подключения vpn 720 VPN, Ошибка 720, Windows 8, Длиннопост

Как сделали – повторяем команду и видим, что она выполнилась. Не забываем про netsh winsock reset. Перезагрузка и вот уже всё хорошо.


Если всё не хорошо, то переходим к плану Б.


Открываем диспетчер устройств. После создания vpn-подключения в контейнере «сетевые адаптеры» появилась куча устройств с названием «wan-минипорт что-то-там» и вот беда – некоторые из них с желтым восклицательным знаком и ошибкой «Это устройство работает неправильно, т.к. Windows не удается загрузить для него нужные драйверы. (Код 31)». Собственно, по коду 31 можно нагуглить мануал.


Краткий перевод для ЛЛ:
Щелкаем правой кнопкой мыши устройство Минипорт WAN (сетевой монитор) и нажимаем кнопку «Обновить драйверы».
Нажимаем кнопку «Поиск драйверов на этом компьютере», «выбрать драйвер из списка драйверов устройств на компьютере»
Снимаем флажок «только совместимые устройства». После этого надо немного подождать.
В столбце слева выбираем Microsoft, а в столбце справа выбираем Адаптер замыкания на себя Microsoft KM-TEST.
После установки драйвера удаляем получившееся устройство.
После удаления устройства щелкаем правой кнопкой мыши имя компьютера в диспетчере устройств и выбираем команду «Обновить конфигурацию оборудования».

Всё, устройство появилось уже без восклицательного знака. А теперь повторяем шаги для всех таких устройств с ошибкой 31.

Вот и всё, пробуем подключиться по vpn к любимой работе.

Показать полностью 1
Отличная работа, все прочитано!