Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - luha

Pages: [1]
1
Russian / флудильня
« on: October 14, 2016, 04:48:37 pm »
Буду немного писать не по теме и вообще - нужно же иногда людям просто так потрындеть!

Короче такая вот случилась преинтереснейшая история со мною на днях. Возможно кому-нибудь пригодится эта печальная повесть в качестве заметки.

Решил я как-то завести новый файловый сервер. Данные туда будут поступать постоянно и надо было сделать так, чтобы было хорошо, тоесть с возможностью расширения и управления массивом, чтоб не бомбить всё сразу, а постепенно докладывать новые диски и менять старые на более вместительные и таким способом наращивать ёмкость. Купил 2U стойку на 36 3,5" SAS/SATA HDD и навтыкал в неё 3Tb-ых (на тот момент времени цена за гиг у них была самая адекватная) дисков составленных парами в первом рэйде, а поверх накатил LVM с ext4 64bit разделом... короче всё в лучших традициях и самым фэншуйским образом, чтоб работало.

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

И вот подтыкиваю я в очередной раз свежую пару новеньких 8Tb дисков, настраиваю рэйд, добавляю к группе лвм, переношу лвм-ные экстенты с 3Tb рэйда, вытягиваю 3Tb диски, расширяю группу и жду ночи чтоб расширить ext4 раздел. Ночью останавливаю сервак, для большей надёжности коменчу в фстабе лвм-ный диск и через перезагруз размонтирую систему, прогоняю e2ckfs - без ошибок... начинаю расширение... всё гуд, ошибок нет - поздравляем, теперь ваша система имеет такой-то новый объём, всё короче типа гуд... монтирую - ERROR!!! Неопознанная файловая система, схреняченный суперблок, бла-бла... ночь, я после работы, глаза уже вытекают и тут на те! Тоесть поясню что случилось - в процессе растягивания что-то пошло не так и файловая система вся покоцалась.

Ещё пару часов попинал мертвеца, переключился на аварийную работу с серверов backup и спать. Спать не получалось - в голове проносились разные варианты что ещё можно сделать, где ещё нужно копнуть, как ещё попробовать и т.п.. Припёрся на работу со спичками и давай ковырять сдохший ext4... а там же ёмкость не пара гигабайт а уже 40Tb насобиралось и любое движение прибивало сервак на десятки часов, плюс весьма негативно сказалась экономия на RAM-е - имеем всего лишь 8Gb плюс 16Gb свапа (думал нафиг надо переплачивать за память на файловом сервере когда строил).

Ковырялся я так с пару дней, перепробовал всё и даже больше. В результате пришло прнимание того, что если бы данные просто лежали и навернулась фс то шанс их вернуть был бы вполне реальным, а вот то, что произошло в процессе растягивания с ext4 свели все попытки к нулю! Причём не диски подвели, не рэйды и не LVM - там всё норм и работает дальше, а вот файловая система при изменении размера подвела (хотя перед этим сто раз растягивал без проблем). Закончилось форматированием по-новому. Теперь потихоньку переливаю на этот сервак инфу с бэкапа и сижу размышляю как жить дальше. Конечно очень удобно было расширяться и для меня такое решение самое подходящее, но авария выявила слабину и теперь придётся разработать иной подход. Веры в надёжность используемых механизмов больше нет.

Мысли у меня на данную тему следующие. Лучше большие массивы не кантовать ибо опасно. Можно оперировать на уровне экстентов LVM и потихоньку поменять к примеру десять 1Tb дисков на один 10Tb, но если нет подстраховки то дальше этого лучше не действовать. В качестве менее геморройной альтернативы придумал вытягивать половину дисков из RAID массивов (они же в единице работают - зеркалом) и на оставшихся пробовать расширять ФС, если успех - возвращаем диски и рэйд актуализируется, если крах - грузим вторую половину, первую зеруем и возвращаем для синхронизации... сервак, конечно, офигеет на неопределённый срок и есть вероятность грохнуть рэйд если где-нить вылетит диск, но лучше так чем как у меня получилось, да и бэкап же есть! Можно перейти на систему "куча виртуальных дисков работает веселее чем один большой и грустный" - тоесть забиваем очередной LVM раздел и не расширяем его, а тусуем туды-сюды по рэйдам, а как забъётся заводим новый. С одной стороны надёжность даже увеличится т.к. если где-то что-то навернётся то колдовать надо будет над одним относительно маленьким разделом, но с другой стороны повышается сложность администрирования и на ум приходят лишь анекдоты про пользователей с веником разбитым на двадцать разделов и вроде занято лишь пол ёмкости HDD, а места нигде нет. Короче лажа как ни крути.

Предвещаю советы бросить "этот глючный" ext4 и накатать такой суперпуперский xfs/zfs/btrfs/.../xyzfs. Я на это могу сказать лишь то, что никаких личных предпочтений в энтерпрайзе быть не должно - только фактические предпосылки. А предпосылки мы имеем следующие - у ext4 хотябы какие-то механизмы есть на случай аварии, что нельзя сказать про другие файловые системы! Это собственно основное и главное. Любая фс может упасть и насколько мне известно 100% отказоустойчивых пока что в природе не существует. Имел опыт реанимации боевой xfs на одном из серверов запасной копии, экспериментировал над остальными линуксячими фс-ками, а также в моей практике имеется несчётное число реанимаций FAT16-32, NTFS в разных версиях и немного гламурненьких эпплавских систем поскольку в своё время несколько лет работал на восстановлении жёстких дисков и информации (чем и сейчас периодически страдаю). Посему ext4 сам выбираю и могу рекомендовать к использованию как наиболее пригодную. Но если кто-то имеет хороший опыт и желание указать то с удовольствием впитаю свежую мудрость.

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

Собственно вот и всё.

2
Russian / zentyal обрабатываем spam
« on: July 20, 2016, 05:00:50 pm »
Ниже предлагаю к ознакомлению мой скромный опыт по доводке почтового сервера postfix под zentyal для антиспамовой защиты. Надеюсь многим материал окажется полезен и поспособствует улучшению качества работы почтового сервера. Буду рад дельным замечаниям и дополнениям, очень надеюсь с Вашей помощью улучшить собственные методы. Как известно коллективный разум наше всё.

ВНИМАНИЕ! Всё что я тут сейчас насочиняю это лишь наивные заблуждения обычного админа широкого профиля и поскольку тема не является моей узкой специализацией могу местами очень сильно ошибиться! Также могу бредить по причине того что вообще-то занят и только сядешь поработать, так обязательно кто-нибудь разбудит... иными словами отвлекают постоянно и нет возможности спокойно заюзать симулятор Пушкина. Если бездумное повторение моих действий приведёт к порче социалистического имущества и капиталистического престижа то я тут ни при чём и ни за что не отвечаю! Если используемая терминология вводит ваш мозг в фазу коллапсирования, то нужно учесть, что индивидуум, критически мотивирующий абстракцию, не может игнорировать критерии утопического субъективизма, концептуально интеpпpетиpyя общепринятые дефанизиpyющие  оляpизатоpы и диалектической материальной классификацией всеобщих мотиваций в паpадогматических связях пpедикатов pешает пpоблемy совершенствования формирующих геотpансплантационных квазипyзлистатов всех кинетически коррелирующих аспектов гуглением или вообще этот текст просто не для вас. Никакой технической поддержки или удалённой консультации для решения каждой проблемы я не предоставляю, но всегда могу поддержать беседу с хорошим человеком. Намеренно стараюсь не выходить за рамки обсуждаемого вопроса с целью не раздувать, хотя в большинстве случаев подразумеваются разного рода важные мелочи, но из другой оперы, но всёравно влияющие - уточняйте если не понятно, а лучше ищите сами, читайте маны (быстрее получится).

ВНИМАНИЕ №2! Для меня на данный момент самая изученная, проверенная и исследованная версия zentyal 3.4 !!! Всё пишу опираясь на неё и поэтому лишний раз предупреждаю, что у вас на другом релизе может быть как-то иначе (хотя и не должно).

... поехали

Основная концепция представленной методики борьбы со СПАМ-ом:

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

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

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

Метод складывается из:
- применение встроенных механизмов postfix-а
- применение дополнительных почтовых фильтров
- анализирование логов
- анализирование писем
- создание дополнительных шаблонов
- применение собственных скриптов
- взаимодействия с клиентами
- и ещё по мелочам

Грейлистинг.

С опытом я прихожу к мнению что это скорее зло и рекомендую забыть. Это не полноценный механизм где большая часть продумана и многое предусмотрено, а некий недоделок, основанный на том, что где-то должна быть очередь писем. Но кто и где, скажите мне пожалуйста, обязан рассчитывать и как-то регламентировано реагировать на подобного рода «выкидоны»?! Ничего удивительного что глючность такого подхода просто зашкаливает!!! Совершенно здоровый сервак каждому сообщает что он недоступен! Естественно в адекватной и производительной системе, где главное доставить корреспонденцию письмо начинает тут-же переходить дальше по mx записям в поисках следующего сервера... а следующий тоже «недоступен», и следующий и следующий и каждый закидывает в грейлист, а потом получается что забанили ни за что на ровном месте, на собственных граблях. Не, а давайте представим что все себе сделали грейлист! Ты шлёшь мне, я в ответ ставлю тебя в грейлист и шлю тебе, а ты ставишь меня в грэйлист и шлёшь мне, а я с новый идентификатором ставлю тебя и т.д и т.п. пока не надоест. Админы в таком случае плюются друг на друго и ругают один-одного. Даааа! Даже в идеале мы изначально имеем лаг почты просто по документации, что называется из коробки! О чём вообще можно дискутировать, если срочное письмо вдруг зависает на неопределённый срок и никакие повторные попытки выслать тут не помогут, а потом разом прилетает целый мешок. Вы, как всемогущий постмастер вынуждены бессильно пыриться в лог, не имея возможности даже руками вытянуть письмо и отдать получателю, поскольку оно по факту вообще никогда не высылалось! Самый лютый спам можно складировать, но только не жертв грейлистинга! Такая петрушка вообще неприемлема и только одно это полностью исключает применение грейлистинга как фильтра почты, особенно в условиях предприятия. Никогда и ни при каких обстоятельствах нельзя вот так просто с бухты витой пары и барахты старых дискет без вообще малейшей причины отказывать в приёме почты!!! Только по конкретной обоснованной причине и никак иначе! Верхом мастерства будет настройка грейлистинга с обязательной паузой в пол рабочего дня, а лучше сутки - тогда точно почта будет как положено работать и совсем без спама.

Адекватной альтернативой грейлистинга является функция postfix-а по проверке существования адреса с которого приходит почта.



Короче я побежал домой. Завтра меня не будет. Продолжение следует. Буду забивать потихоньку инфу - ещё много осталось, ждите, надейтесь и верьте.

3
Russian / OpenVPN DNS Windows 7 8 10 (DNS Leak)
« on: May 04, 2016, 11:28:04 am »
Столкнулся с проблемой "неправильных" DNS серверов при построении туннеля на виндоус машинах удалённых клиентов. Решил поделится. В народе этот феномен нарекли "DNS Leak" и если хотите больше инфы ищите по этим ключевым словам.

Симптомы: клиент на Win-7/8/10 нормально строит туннель, но в случае отличающихся DNS в удалённой сети от тех, что использует клиент в своей локальной он не может нормально работать поскольку у него не резолвятся удалённые хосты. Иначе говоря остаются работать DNS сервера например глобальные (из интернета), а в удалённой сети сервера недоступны через внешние IP адреса и если пинговать по IP то всё вроде как работает (туннель-то поднят), но по имени нет. Если же удалённая сеть своего DNS сервера не имеет то проблема всёравно присутствует, но остаётся незаметной т.к. клиент просто не замечает разницы.

Причина: в майкрософках окончательно перевели механизм работы сетевых подключений на вроде как более лучший WFP (Windows Filtering Platform). Кому интересно можете погуглить, я не углубляюсь. Факт в том, что этот WFP как оказалось сильно не дружит с любыми туннелями (не только OpenVPN, но вообще всё перекосило). Как по мне технология имеющая в названии слово "windows" изначально обречена на успех, ну да не будем о грустном.

Решение: в случае с туннелем OpenVPN на zentyal самым правильным методом является актуализация у клиента версии OpenVPN на новую с патчем (нужна версия не ниже 2.3.9 лучше новее) и ручное редактирование файла конфигурации "*-client.ovpn" (дописать в конец "block-outside-dns" чтобы задействовать патч против этого лага).

На данный момент доступна OpenVPN 2.3.10 (released on 2016.01.04)
https://openvpn.net/index.php/open-source/downloads.html

В списке изменений для версии 2.3.9 видим:
Fish (1):
      Make "block-outside-dns" option platform agnostic
ValdikSS (1):
      Add Windows DNS Leak fix using WFP ('block-outside-dns')

... тоесть как раз с версии 2.3.9 можно считать баг закрытым. Я тестировал на 2.3.10 если что.

Как это работает: при включенной опции "block-outside-dns" в процессе построения туннеля блокируется порт 53 для всех соединений кроме VPN. После завершения работы порт 53 обратно становится доступным.

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

Надеюсь кому-нибудь поможет. Любые замечания приветствуются.

4
Russian / Firewall Port Forwarding
« on: February 18, 2016, 11:04:27 am »
Всем привет!

Может быть кто-то тоже сталкивался и сможет дать подсказку. Почему иногда не срабатывают правила файервала? Zentyal 3.3.10

Симптомы:

В зенчале всё вроде нормально настроено, работает как роутер, проброс портов по серверам в обе стороны функционирует без проблем. Решил создать чёрный список IP адресов и перенаправлять их на неиспользуемый IP чтобы выдавало ошибку недоступности хоста по причине отсутствия пути (банить спамеров)... сделал объект "BLOCKED_IP" а в "Port Forwarding" забил для каждого внешнего интерфейса по правилу (чтобы "банило" с любого входа) следующего вида:

Interface: eth3
Original destination: Zentyal
Protocol: All
Original destination port: any
Source: BLOCKED_IP
Destination IP: 192.168.1.13
Port: Same
Replace source address: нет
Log: нет
Description: баним спам

И конечно же разместил эти правила самыми первыми в списке (кто не знает поясню, что имеет значение очерёдность в правилах и выполняется только первое подходящее).

Тестирование показывает что всё гуд, адреса таким образом блокируются.

Дальше в течении какого-то времени собираю почту, анализирую скриптами логи и сами тела и что же я вижу? Заблокированные адреса продолжают пробиваться не смотря ни на что! В логе кернела роутера лежат цепи iptables (логов быть не должно т.к. перенаправляет на 13-й адрес без логов дабы не засирать)!!! О_о

Feb 18 03:57:04 router kernel: [1173832.156750] zentyal-firewall redirect IN=eth3 OUT=eth4 MAC=00:1b:21:8d:a0:8d:00:14:1b:c6:e8:00:08:00 SRC=136.243.111.18 DST=192.168.1.1 LEN=60 TOS=0x00 PREC=0x00 TTL=57 ID=47250 DF PROTO=TCP SPT=40991 DPT=25 WINDOW=14600 RES=0x00 SYN URGP=0 MARK=0x2

... из лога вытекает - игнорится предыдущее правило перенаправления на 13-й адрес и выполняется следующее правило где перенаправление идёт на 1-й адрес (собственно поэтому и попало в лог).

Что за #@* мазер фазер

Pages: [1]