Читали? Своего рода библия. Есть там раздел (по крайней мере в моём — 2-е издание, 1997 год) 32.10 под названием «Военные истории и этика». Так вот, этику мы конечно же трогать не будем, а про обычные подвиги поговорим.
▍ История первая. Грибы (не галлюциногенные)
Примерно в 2000 году направлен был в близкую «командировку» разобраться с одной экзотической железякой. Про год написал совсем не случайно — в этот период наш отдел назывался «системным» и занимался абсолютно всем — эникеем, персоналками, сетями (прокладка, маршрутизаторы, хабы/коммутаторы), серверами (включая «сантехнику») и т.д. Типичные «тыжпрограммисты», как следствие, хождение на домашние компы руководства и «добровольная» помощь всем и во всём, где есть запах персональных компьютеров.
Итак, что представляла собой эта железка. Прежде всего, предприятие, где она расположена — завод резинотехнических изделий. Готовую резину надо проверять на соответствие определённым стандартам и этим, в числе прочих, занимается один из испытательных станков — «разрывная машина». Фотографию конечно не нашёл, есть что-то похожее. В машине зажимается кусочек резины и тихонечко растягивается, пока она не порвётся. В это время снимаются показатели и на персоналке рисуются графики и различные цифры — красивая распечатка прикладывается к партии продукции. И главная проблема в том, что эта машина уже 3 года стоит и не работает, а на компьютере горит красная надпись.
Привели к аппарату, включили его и компьютер — тут я был несколько обескуражен :). В принципе всё знакомо — стандартный писюк, родной MS-DOS, программа. Изюминка на торте — всё на немецком языке! Я своего рода полиглот, проходил в школе французский, а в институте приобщился к играм на английском, но к такому жизнь меня не готовила. Переключение на кодовую страницу и страну в DOS-е бессмысленно, т.к. в то время вопросы локализации программного обеспечения решались без участия операционной системы. Полазить по менюшкам программы не давала красная плашка на экране с непонятной надписью и заблокированный ввод/вывод.
Первым делом обзвонили знакомых, но безрезультатно — если у кого и остались знания немецкого, то на уровне школьной программы: «Ком цу мир битте шнапс дринкин. Яволь!». Через час начал просто рассматривать окружающий пейзаж, симпатичных девушек-мулаток (производство связано с сажей и она незримо присутствует повсюду), оглядел саму машину и начал интересоваться, как она функционировала, пока ещё была исправна.
Гид, по совместительству главный инженер, охотно поделился информацией с демонстрацией на пальцах технологического процесса. Техника конечно красивая и впечатляющая, особенно безопасность на высоте — чтобы не долбануло порванной резинкой, опускается специальный экран из оргстекла, чтобы оператор не совал руки куда не положено — пусть держится за две рукоятки с кнопками (рукоятки разнесены почти на метр), а запускается процесс специальной педалью на полу, т.к. руки заняты. Всюду жёлто-чёрные диагональные полоски. А это что за кнопка? — на одной из горизонтальных поверхностей крупный красный грибок. Есть такой же с другой стороны машины, но почему-то не утопленный. Немного «повтыкали» на оба органа управления и тот, что был утоплен, вытащили — всё сразу нормализовалось.
Видимо кто-то 3 года назад неудачно присел на элемент безопасности. Это сейчас, когда у меня есть корочки по охране труда/промбезопасности/электробезопасности всё выглядит тривиально, а тогда за эту магию меня пытались опоить коньяком и выдать полгрузовика резиновой плитки для покрытия дорожек на даче. Но я был молод, не имел дачи и очень хотел домой :)
▍ История вторая. R-protocols
Так уж случилось, что приобщаться к UNIX-системам я начал в 90-х годах прошлого века и знакомство с r-протоколами уже в то время заключалось в том, чтобы как можно скорее их отключить. Руководствовались в то время скорее не безопасностью, а внутренним представлением об экономии ресурсов.
Итак, время действия также примерно 2000 год. Имеется SCADA-система, построенная на QNX — в то время практически отраслевой стандарт, лучшая система в своём классе. Систему настраивали импортные специалисты, которые передали максимум знаний, но не могли учесть всех нюансов. Помимо основной задачи данная система выдавала (экспортировала) раз в 5 минут файл с определёнными параметрами/переменными, который потом уходил в другие системы, уже не реалтайм, для внутренних учётных задач. Обмен осуществлялся через промежуточный шлюз на базе Linux. Связано это было с тем, что QNX хоть и соответствовала POSIX, но довольно специфично, а также не было штатного решения для работы с центральной базой данных.
Решение было простое и быстрое — на границе сетей поставлен компьютер с Linux, на нём поднят rcpd и ftp. Выбор протокола rcp был обусловлен тем, что QNX довольно специфичный юникс и единственное, что там нашлось на то время — была команда rcp, с помощью которой планировщик и скидывал файл на шлюз. Соответственно, на другой стороне роботы вытягивали по ftp этот файл со шлюза, парсили и скармливали базе данных. Про ftp тоже не спрашивайте — разработчики в своё время откопали левый компонент для дельфей, освоили его и пытались втыкать всюду где только возможно. Всё работало хорошо пока не обновили версию linux на шлюзе.
Сначала казалось, что всё нормально функционирует, но потом обратили внимание, что время копирования с QNX на Linux стало в разы больше, чем было до обновления. Сеть не трогали, QNX тоже — однозначно проблема в Linux. АСУТП-шники ходят и уже в открытую говорят в наш адрес нехорошие слова. Отлов бага осложнялся, тем что оба участника задействованы в технологическом процессе и экспериментировать с настройками чревато и не комфортно. Даже посниферить трафик не получилось, несмотря на использование в качестве активного сетевого оборудования хаба (это энтерпрайз и оборудование жило на балансе лет 10-15, смотря сколько бухгалтер ему прикрутит во время постановки на учёт. Времена были смутные) — все порты заняты. Значит берём кусочки логов, бумажку и сидим анализируем.
Сопоставили время в логах и наблюдаем кто, когда и как проявляет активность. QNX запустил копирование, а реальное формирование файла на Linux начинается спустя пару минут. Читаем маны и конечно же натыкаемся на упоминание ident (Если кто хочет почитать маны по r-протоколам, то в современных системах их практически не осталось, а то что есть слишком убогое. Надо рыться в интернет-архивах). Это своего рода протокол безопасности на заре развития сетевых технологий. Вероятно многие его припоминают, т.к. он наряду с echo, chargen, daytime, qotd и time часто предлагается для реализации в лабораторных работах курсов по сетевому программированию. Остальные могут освежить память в википедии. Проблема в том, что в процессе работы rcp хочет удостовериться, кто на той стороне, чтобы записать его имя красным карандашиком в журнал, и проверяет это единственным знакомым ему способом — по протоколу ident. Клиент ткнулся на порт 113/tcp и замер в ожидании ответа. Вот этот таймаут ожидания нас и напряг. Товарищи, переустановившие linux, вероятно про это забыли или не знали, а также вполне допускаю, что стандартные настройки сетевого стэка были в ранних ядрах совсем другие. В общем, диагноз определён, приступаем к лечению. Навскидку три варианта:
- Посредством хитрых опций сказать QNX и его rcp, чтобы не спрашивал кто на той стороне — не прокатил. Очень скудная реализация rcp на этом юниксе. Да и честно говоря на linux таких опций не нашёл.
- Поднять на linux сервис in.identd. Нормальный вариант, но в итоге не реализован. Причины не помню, вероятно были какие-то капризы со стороны QNX.
- Настроить linux, чтобы он сообщал QNX, что ident у нас отсутствует. Вот так сразу, чтобы не ждал и продолжал работать.
Идём в вариант номер 3, тут нам помогает ipchains — папа iptables и дедушка nftables. Вешаем на TCP/113 отбой с сообщением icmp port unreachable и всё. Файлы летают, репутация Linux восстановлена :)
▍ История третья. Я тебя, ****, по IP MAC вычислю
Опять сеть, хабы, коммутаторы и проблемы на ровном месте. Понадобилось поднять сервер обычный, железный, из семейства Proliant (уже хьюлитовский). Без проблем установили с пластинки linux, настроили что надо на консольке, взяли из эксельки свободный айпишник и приступили к работе по сети. А она не работает. То есть пинги проходят, но как-то нестабильно, а к серверу не подключиться никак. Два, три, десять раз проверили конфиги, поднимали сеть вручную — проблема стабильна.
Залезли на коммутатор Cisco 5550 с модулем RSM и CatOS на борту. Отловили негодяя по MAC-адресу :). То что в эксельке адрес был свободен — это наш косяк, а мы к себе довольно лояльны, осталось найти физическое устройство и сменить на нём адресок. Почему не на сервере? Дело в том, что это будет довольно важный сервер и предварительно была проведена весьма серьёзная работа по вписыванию его ip-адреса в некоторых системах, межсетевых экранах и т.д. через бумажный документооборот. В общем приступаем к отлову некоего мерзавца, у которого нам известны ip-адрес и mac-адрес (из диапазона Hewlett-Packard). Диапазон нам ничего не даст — практически 100% парк компьютеров в конторе от HP. Порт на коммутаторе с данным mac-адресом подключен к хабу hewlett-packard (advancestack какой-то). Детектить mac на хабе можно только физически — смотрим какие порты активны и либо ходим на конечную точку (там кстати тоже может оказаться хаб — тогда рекурсия) и смотрим параметры там, либо тупо откидываем клиента и смотрим на коммутаторе, что изменилось.
В общем, как обычно, гуманные методы были безрезультатны и наши электроники тупо откинули _всех_ клиентов с этого хаба, только кабель до коммутатора остался. Пришли и отчитались о проделанной работе. А результат не изменился — адрес по-прежнему занят, пингуется периодически! Не поверил я электроникам — это ведь хаб Карл, ХАБ! Потопал в серверную/кроссовую ногами. Притопали — действительно хаб, кабеля рядом откинутые, горит только одна лампочка на порту в направлении коммутатора. Хаб точно этот — проверяли отключением кабеля к коммутатору. Протёрли глаза и ещё раз осмотрели хаб — модель, серийник, лампочки и т.д. И тут я вижу — snmp-модуль! Это же хьюлит-пакард, энтерпрайз железо в чистом виде. Любая железка, даже хаб с которого и взять-то практически нечего, должна быть красиво нарисована в HP OpenView или TopTools. В общем первым делом ампутировали этот модуль, а со временем и сам хаб. И если вы думаете, что после этого навели порядок в эксельке с ip-адресами, то глубоко заблуждаетесь :)
▍ История четвёртая. Туннель наизнанку
Наше время. После возвращения Крыма прошло некоторое количество лет и правительство дало чёткий курс на импортозамещение. Как по железу, так и по софту. Наш энтерпрайз, как и все полугосударственные конторы был вынужден взять под козырёк и приступить к формированию планов импортозамещения в строгом соответствии с методикой. Оказалось, что есть одна важная система с терминальным доступом к ферме Citrix, доступ к которой необходим практически на всех рабочих местах. И это не только на нашем энтерпрайзе. Многие восприняли это как манну небесную — это самый железобетонный сдерживающий фактор, и значит на компьютерах можно оставить родненькую винду! Пускай старую, не обновляемую, кривую/косую — но винду, а не линукс.
Казалось бы, в чём проблема? Citrix клиент есть и под линукс, работает вроде без проблем. Но тут оказалось тоже неожиданная «помощь» государства — трафик между клиентом и сервером надо шифровать. И шифровать не просто так, а с помощью казённых алгоритмов. В своё время КриптоПро совместно с Citrix родили специальную .dll которая позволяла виндовому клиенту успешно это осуществлять. Но о линукс-клиентах никто в то время не задумывался и они остались со стандартным набором забугорных шифросьютов.
Итак, для порядку все попробовали поставить отечественный линукс, на него цитрикс-клиента и с наскоку ворваться на ферму — ожидаемо с отрицательным результатом. Потом бумажная артиллерия по головной конторе и долгожданный трофей — «доступ к ТФ с рабочих мест Linux не предусмотрен». Официально работы свёрнуты, но мы бьёмся дальше — уж больно задача интересная.
Авторизация на ферме — стандартный RSA, проблем нет и мы доходим до скачивания .ica-файла где уже спотыкается сам Citrix ICA Client. И понятно почему — не может согласовать протоколы. Изучаем .ica файл, запускаем его клиентом wfica с командной строчки — так проще и быстрее. Можно и сам файлик немного исправлять, по мере понимания формата (документация неплохая имеется, но сайт Citrix уже прикрыли для российских клиентов). В потрохах его видно упоминание ssl-proxy — значит есть стандартный ssl протокол, только с отечественным шифрованием по ГОСТ. Уже теплее. Что будет, если подставить ему библиотеки от openssl из комплекта КриптоПро? Ничего не будет. Посмотрел все файлы из комплекта Citrix через ldd — нигде нет ни одного упоминания внешних библиотек поддержки ssl. Оно и понятно, в зависимостях/совместимости Citrix-клиента про openssl/libressl/gnutls тоже упоминаний нет.
Собственно далее долгое прощупывание как возможностей клиента, так и терминальной фермы, изучение всей доступной документации, бесконечные эксперименты. Т.к. ферма вне зоны нашей эксплуатационной ответственности, то это по сути чёрный ящик, где кроме .ica-файлов с параметрами коммуникаций клиента ничего не получить.
На одном из экспериментов удалось с помощью openssl из комплекта КриптоПро приконнектиться к ферме через sclient. Просто прошла фаза коннекта и проверки сертификатов. Замечательно, нападает некоторое озарение — если на нашем конце поднять stunnel от КриптоПро, то на нашей стороне будет нешифрованный порт к терминальной ферме! Да, вроде коннект имеется, только какой в этом толк, если цитрикс не хочет работать с нешифрованным локальным портом (в .ica файле точку приземления ему поправил).
В общем в настройках в качестве точки приземления указан ssl-proxy сервер, т.е. специальный сервис цитрикса реализующий внутренние proxy-функции, про которые мы не знаем ничего. Если бы в описании формата ica-файла присутствовала возможность указать адрес proxy-сервера без шифрования, то вполне вероятно такой вариант был бы работоспособен. Но нам надо двигаться дальше — хочется клиенту порт с шифрованием — дадим ему такой. Ставим ещё один stunnel, в этот раз из комплекта операционки со стандартными протоколами, которые citrix умеет из коробки. Закорачиваем его на вход stunnel от КриптоПро. Самоподписанные сертификаты сложили, stunnel-и подняли и что удивительно — всё заработало!
Для общего понимания — сделан «вывернутый наизнанку» stunnel в пределах loopback-интерфейса, где на одном конце принимаем шифрованный трафик RSA, а затем его разворачиваем и далее уже шифруем по ГОСТу для передачи во внешний мир на ферму. Этакий MITM, но с благородными целями. Техническая задача решена, но в итоге получилось решение «Шрёдингера» — вроде как и есть, всем хорошо известно, но официально не афишируется. Ждём, когда придёт его время, постигаем дзен.
▍ История пятая. Недоношенная сеть мобильных проксей
Довольно интересная задача и довольно современная. Вышли на меня как-то некие ребята, владельцы сети мобильных проксей. Что-то узлы часто недоступны, а причина непонятна: вешаются сами или сеть пропадает — сами не смогли определить, надо глянуть свежим взглядом, разобраться.
Начал погружаться. Технически конечный узел это так называемый «свисток» huawei с немного поправленной прошивкой — в потрохах у него штатный андроид (читай linux) на который поставлен 3proxy, autossh, dropbear. Как и положено 3proxy проксирует трафик, autossh следит, чтобы dropbear держал туннель с переброшенным портом к центральной машине. Всё завязано на перебросе портов в центральном сервере на виртуальные интерфейсы. Есть ещё скрипт, который регулярно передёргивает второе ядро процессора, на котором живёт проприетарная ОС, управляющая модемными (коммуникационными) делами. Соответственно сотовый оператор меняет нам ip-адрес.
Получается такое интересное решение — вставляешь в usb-dongle симку, саму железку в хаб с питанием, и всё — система запущена, сама подключается к сотовой сети и строит туннель до центра, откуда будут приходить запросы клиентов. В общем запутал всех окончательно, но знающие люди поймут :).
Так как это андроид, да ещё на железке с довольно скромными характеристиками, то ожидать вменяемых логов не стоит (скажу более — на форумах пишут, что флэшка, если её открыть на запись и начать активно юзать, от ввода/вывода очень быстро склеивает ласты). Также внутри у неё busybox вместо bash и полновесных утилит. Работа немного облегчалась тем, что в одной локации была RaspberryPi, в которую был воткнут хаб с этими самыми модемами в количестве около десятка и на них можно было зайти через telnet, не опасаясь обрыва сессии, при передёргивании мобильного канала.
Для начала почитал, что есть из штатных логов — ожидаемо — ничего. Забыл добавить, что у ребят есть своя система мониторинга, которая запрашивает страничку через конкретный узел, но она имеет довольно большое окно и точная реализация её непонятна. На RPi также нашлись какие-то заготовки для агента zabbix — но только заготовки. Вообще, сложилось впечатление, что сисадмин, который это задумал и реализовывал, исчез в неизвестном направлении, не закончив работу. В общем продолжим изучение системы и анализ отказов.
Первым делом на малинке слепил скрипт, который по крону через telnet снимает основные параметры со всех модемов. Сбор информации за сутки проблем не выявил — в сислоге проскакивали сообщения о передёргивании usb-девайсов, но они не особо коррелировались с мониторингом верхнего (прикладного) уровня. Может на хабе питания не хватало, непонятно. Далее пару недель погружался настолько, что даже вытащил с гитхаба исходники и принялся смотреть, как проковырять доступ в закрытую часть проприетарной операционки модема — было подозрение, что внутренние watchdogs шалят. Результатов тоже нет, уже стал подумывать, как вежливо попрощаться, но напоследок попросил логи с центральной машины.
Дали логи. Посмотрел и стало всё понятно — т.к. скрипт на модеме меняет ip-адрес просто переключением диапазонов сотовой сети, то для сетевого стэка свистка это очень и очень неожиданно, но терпимо. Более грустная ситуация на сервере, куда лезет dropbear, чтобы перебросить порт. Сервер видит, как к нему стучится клиент с новым ip-адресом и хочет привязать порт на виртуальный интерфейс, а у него ещё старый клиент там висит и таймаут tcp весьма далёк от истечения. Отлуп ему. Лечится довольно просто — перед передёргиванием сети посылаем autossh сигнал USR1, чтобы он перестартовал своего подопечного (dropbear). autossh корректно гасит dropbear и сессия на стороне сервера закрывается, и пока идёт запуск ssh-клиента, мы успеваем получить новый ip-адрес.
Но это ещё не всё — было ещё одно обращение, аккурат в период каких-то выборов. Трафик попёр, и начались проблемы. Опять сделал некое подобие мониторинга и вскоре чудом успел обнаружить переполнение conntrack на одном узле, вследствие чего пакеты просто отбрасывались. Оно и понятно — usb-dongle устройство индивидуальное и настройки ядра сделаны исключительно для комфортного сёрфинга одного человека.
Увеличил размер таблицы, уменьшил таймаут tcp (до сих пор не понимаю, зачем он по умолчанию в ядре такой огромный) — дал рекомендации для тиражирования на остальные узлы. После этого ребята исчезли, а жаль — я уже мысленно разворачивал полноценную систему мониторинга и делал им балансировщик нагрузки. Не бесплатно разумеется :)
▍The end
Конечно это не всё, но я уже утомился писать, да и многое уже забылось. Жду от вас в комментариях более захватывающие случаи из личной практики :)
