Одминский блог

Объединяем интерфейсы в CentOS

Разбираясь, накануне, с настройкой IP адреса в CentOS обнаружил интересную фичу по объединению нескольких интерфейсов в один виртуальный, тем самым повышая скорость передачи данных и создавая функционал отказоустойчивости, с помощью модуля ядра bonding.

Для этого необходимо создать bonding интерфейс, путем создания файла /etc/sysconfig/network-scripts/ifcfg-bond<N> , где N номер объединяемого интерфейса. Содержимое файла аналогично содержимому файла описания настроек обычно интерфейса, с той разницей что директива DEVICE= должна содержать поле bond<N>, где N номер интерфейса.

Пример файла выглядит следующим образом:
DEVICE=bond0
BOOTPROTO=none
ONBOOT=yes
NETWORK=10.0.1.0
NETMASK=255.255.255.0
IPADDR=10.0.1.27
USERCTL=no

После того как файлы будут созданы, можно объединять интерфейсы путем добавления директив MASTER= и SLAVE=  , так что за исключением этих полей оба файла должны выглядеть идентично. Например для интерфейсов eth0 и eth1файлы конфигурации будут выглядеть следующим образом:
DEVICE=eth<N>
BOOTPROTO=none
ONBOOT=yes
MASTER=bond0
SLAVE=yes
USERCTL=no

Для того чтобы  слияние интерфейсов работало, необходимо чтобы модуль bonding был загружен в ядро, для чего необходимо проверить, чтобы в файле /etc/modules.conf присутствовала строка:
alias bond<N> bonding
где N номер интерфейса, и для каждого сконфигурированного интерфейса должна присутствовать своя запись.

Рубрика: Linux | Ваш отзыв »

Настройка IP в CentOS

Настраивал себе систему в VmWare Player, после чего перенесли её на ESX Server, ну и по пути возникла необходимость, из дома, сменить на системе IP адрес и повесить дополнительный алиас на интерфейс. Поскольку настраивал центосину до этого исключительно из окошек Х, пришлось немного поморщить голову, но после прочтения официального мануала, все оказалось проще некуда.

Смена IP производится следующим образом:
Открываем файлец /etc/sysconfig/network-scripts/ifcfg-eth0 и смотрим что мы в нем имеем:

DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:0C:29:BC:B7:60
ONBOOT=yes

Собственно как понятно из файла- IP адрес он цепляет от DHCP сервера, хотя мне казалось что я его задавал лапками, поэтому отрубаем DHCP и меняем настройки на:

DEVICE=eth0
BOOTPROTO=static
HWADDR=00:0C:29:BC:B7:60
ONBOOT=yes
DHCP_HOSTNAME=crm_security.lan
IPADDR= новый_IP_адрес
NETMASK=255.255.255.0
GATEWAY= новый_шлюз
TYPE=Ethernet

После перезагрузки машины или рестарта сетевых служб, с помощью команды service network restart , система переподхватит новый IP адрес.

Теперь по поводу алиасов- там же где мы правили файло с сетевыми настройками, создаем файлик ifcfg-<if-name>:<alias-value> Единственно что надо учесть тот момент что алиас не может цеплять свой адрес по DHCP, поэтому следует задавать статический адрес, для чего создаем файл /etc/sysconfig/network-scripts/ifcfg-eth0:0 и в него прописываем следующие строки:

DEVICE=eth0:0
ONBOOT=yes
BOOTPROTO=static
IPADDR=алиас_IP
NETMASK=255.255.255.255

Если нужно добавить пул алиасов, скажем от 192.168.10.1 до 192.168.10.200, то сделать это можно либо создав 200 конфигурационных файлов для алиаса, либо описав весь пул адресов, для чего создадим файл /etc/sysconfig/network-scripts/ifcfg-eth0-range0 и внесем в него следующие строки:

IPADDR_START= 192.168.10.1 # первый IP в пуле
IPADDR_END= 192.168.10.200 # последний IP в пуле
NETMASK=255.255.255.255
CLONENUM_START=1 # число <alias-value> с которого будет начинаться пул
NO_ALIASROUTING=yes

Рубрика: Linux | Ваш отзыв »

Делегируем управление субдоменом

Возникла необходимость делегировать управление доменной зоной третьего уровня (то есть например newdomain.odminblog.ru) серверам доменных имен хостера. Первое что пришло в голову, это создать зону в named.conf где указать что данный сервер является вторичным и первичным обозначить доменный сервер хостинг провайдера.

Согласуясь с вышесказанным запись в named.conf приобретает следующий вид:

############################################
zone “newdomain.odminblog.ru” {
type slave;
file “slave/newdomain.odminblog.ru”;
masters {
DNS-провайдера;
};
############################################

Но данный вариант по мне не корректен, так что пришлось пойти в изысканиях дальше.  Поковырявшись в доках, мануалах и описаниях на сайте RU-CENTER пришел к тому, что управление зоной можно делегировать в файле описания зоны, подобно тому как это делает провайдер при делегировании PTR записи. Для этого необходимо описать DNS сервера отвечающие за данный субдомен, в разделе определения серверов доменных имен, причем их имена должны принадлежать к субдомену.

newdomain    IN    NS    ns1.newdomain.odminblog.ru
newdomain    IN    NS    ns2.newdomain.odminblog.ru

После чего, через канонический тип имени CNAME определяем доменные сервера провайдера

ns1.newdomain  CNAME  ns1.DNC-провайдера.
ns2.newdomain  CNAME  ns2.DNC-провайдера.

В таком варианте все должно нормально работать. При тестировании попробовал описать DNS сервера провайдера сразу в описании NS для субдомена, используя их хостнеймы, но после такого финта, по непонятной причине отвалились MX-записи для корневого домена, что было довольно неожиданно, ибо вся остальная зона отдавалась замечательно.

Рубрика: Интернет, Сайты и их проблемы | Ваш отзыв »

Ускоряем разрешение доменных имен через resolve.conf

Системный файл /etc/resolv.conf является файлом конфигурации процедур сервера доменных имен. В этом файле хранится информация об используемых DNS серверах, и этот файл перечитывается при вызове процедуры разрешения имен. В файл можно поместить информацию о трех DNS серверах, причем алгорит действия будет таким, что запрос всегда уходит на стоящий первым в списке сервер. В случае если он не отвечает в течении некоторого времени (по умолчанию 5 секунд), то запрос отправляется на вторичный сервер DNS, если он не отвечает, то запрос переходит к третичному серверу DNS. То есть по умолчанию система всегда использует первый из списка сервер, и обращается ко второму и третьему только в случае, если первичный сервер не отвечает.

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

Опиция timeout позволяет задавать время таймаута для присутствия в очереди запросов. По умолчанию этот параметр равен 5 секундам (максимально 30), так что если мы хотим ускорить отработку запроса, то выставляем этот параметр например на 2 секунды:
options timeout:2

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

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

Опираясь на все вышесказанное, resolve.conf  будет иметь следующий вид:

nameserver 1.1.1.1
nameserver 2.2.2.2
nameserver 3.3.3.3
option rotate
option timeout:2

Рубрика: Интернет | Ваш отзыв »

Перепрошиваем свич HP ProCurve

На старой работе возникла проблема с HPшными свичами ProCurve 2XXX серий, которые  закупал лет 6 назад. С месяц назад у ребят началась какая то свистопляска с портами и дуплексами, в связи с чем решили мы их перепрошить. Операция не сложная, но долгая по времени и довольно стремная, ибо система строилась на века, поэтому возникает опасение, что все транки и VLAN могут послетать если что то пойдет не так.

Поскольку я обновлял часть из них буквально перед уходом из конторы, то и версии прошивы были различными. Здесь следует оговорить несколько моментов:

Начиная с версии прошивки I.08.74 устройство не поддерживает FEC trunks (Cisco Systems’ Fast EtherChannel for aggregated links) и CDP (Cisco Discovery Protocol). Вместо них введены, базирующиеся на IEEE стандарте, протокол LACP aggregated links (предназначенный как раз для организации транков) и протокол LLDP для оповещения по сети и сбора информации о соседних устройствах.

Для апргейда до актуальной версии прошики I.10.xx необходимо иметь как минимум версию I.08.07, если она ниже, то сначала обновляемся до неё, после чего вторым обновлением поднимаем прошивку до I.10.xx. Версия промежуточной прошивки может отличаться у разных моделей.

Конфиги созданные с помощью прошики I.10.65 или новее, не поддерживаются предыдущими версиями прошивок, так что в случае варианта даунгрейда устройства, все придется настраивать заново.

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

Перепрошить дейвайс можно двумя способами: через XMODEM соединение, и загрузкой с TFTP сервера. Работу с TFTP я рассмотрю позднее, ибо она требует настроить TFTP сервер, а пока попробуем перепрошить с помощью соединения  XMODEM. Сам XMODEM является простейшим протоколом передачи данных и отлично зарекомендовал себя еще на BBSках в далеких 70х годах. Не буду вдаваться в его подробности, ибо кому интересно тот почитает сам, а перейду сразу к нашей процедуре. Итак для перепрошивки нам необходим сам файл прошивки, скаченный с офф.сайта; стандартный RS-232 кабель  “мама-мама” и компьютер с com-портом, или, в связи с тем, что сейчас найти такой компьютер практически нереально, переходник usb-serial. Подключаемся к свичу с помощью встроенного терминала Windows (пуск -> стандартные -> связь -> HyperTerminal) со стандартными параметрами: 9600 без управления потоком, дважды щелкаем Enter и мы в строке управления CLI. Для начала нам надо перевести терминал на более высокую скорость, ибо загрузка имиджа на 9600 будет идти почти полтора часа. Для этого говорим:
# configure
# console baud-rate 115200
После чего перегружаем свич и подключаемся уже с использованием указанной скорости
Даем команду  # menu и в загрузившимся меню выбираем Download OS и выставив XMODEM говорим execute (также можно сделать это прямо из CLI задав команду # copy xmodem).  После этого нажимаем ентер и задаем отправку файла через терминал:  выбираем Передача -> Отправить файл, во вкладке Протокол выставляем XMODEM и выбираем необходимый файл прошивки.Минут 10-15 файл закачивается после чего перегружаем свич. Процесс первой загрузки будет идти несколько дольше чем обычно, так что не стоит начинать кусать локти раньше времени.

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

Рубрика: Оборудование | Ваш отзыв »

Checkpoint Secure Client VPN для 64битных Windows 7

После анонсирования новой системы Windows 7, вскрылась новая проблема, на которую никто не обращал внимания до этого, не смотря на то, что она уже была озвучена применительно еще к системам Vista: на 64-битных системах Windows Vista/7 невозможно использование IPSEC VPN клиента от Checkpoint – Secure Client, с помощью которого удаленный хост может подключаться к шлюзам Connectra, VPN-1, UTM-1 и Power-1 используя протоколы стандарта IPSEC. Это продукт отлично себя зарекомендовал на большинстве систем Microsoft и Mac, но к сожалению, после установки на 64-битную систему, пакет Secure Client не запускается в принципе, так что использование его невозможно.

И вот здесь начинается некоторая непонятка, ибо Checkpoint обещает выпуск обновленного полнофункционального VPN клиента Secure Client, поддерживающего 64битные системы, только в конце второго квартала, и на данный момент предлагает два вида решения: использование облегченного VPN клиента Endpoint Connect (он также интегрирован в продукт Endpoint Security Client R73), входящего в комплект Connectra, но при этом поддерживающего соединение со шлюзами, начиная от NGX R65 HFA40. В данный момент единственная версия клиента  Endpoint Connect, поддерживающая 64битные системы, является  Endpoint Connect R73, который дает возможность подключения к системам выше R65 HFA40 и Connectra R66.

Для использования этой версии клиента также необходимо произвести апгрейд поддержки Endpoint Connect на шлюзах, путем установки установки патча поддержки R73. Последняя актуальная версия клиента Endpoint Connect, а также патч для шлюза VPN-1 и портала Connectra доступны для скачивания на офф.сайте Checkpoint.

Лицензируется использование этого продукта в виде Check Point Endpoint Security – Secure Access license, путем приобретения лицензии на удаленное рабочее место, то есть если два пользователя работают с одной машины, то нужна всего одна лицензия, если же один пользователь предполагает работать с двух разных машин, то две лицензии.

Другим вариантом использования VPN клиента на 64битныхз платформах, является использование продукта SSL Network Extender (SNX) для построения шифрованного туннеля 3го уровня SSL VPN. Версия SNX R71 HFA1 for Windows поддерживает 64битные платформы Windows 7/Vista/XP. Этот клиент скачивается с портала Check Point Security Gateways по запросу пользователя, пытающегося установить шифрованное соединение через протокол HTTPS. Продукт поддерживает шлюзы, начиная с версии NGX R60 и выше. Для использования версии R71, на шлюзах также должен быть установлен патч поддержки этой версии, который можно скачать на офф.сайте Checkpoint.

Лицензируется использование данного продукта путем приобретения лицензии SNX (на определенное количество пользователей: 25, 100, 250 и т.д) или также Check Point Endpoint Security – Secure Access license, которая приобретается по количеству удаленных рабочих мест.

Так что все разговоры о том, что Endpoint Connect поддеривается только VPN порталом Connectra либо развод на лишние, причем не малые, бабуськи, либо просто незнание материала.

Рубрика: Check Point | Ваш отзыв »

Загрузка виртуальной машины VMware по TFTP

В данный момент стоит задача протестировать работу двух продуктов класса IPS от компаний ISS и McAfee и сравнить их результаты. Для этого нам необходимо запустить оба этих продукта и натравить на них либо сканер, либо как планируем мы- сканер уязвимостей от того же McAfee Foundstone.

McAfee IntrShield у нас уже есть отлаженный и настроенный, а вот ISS Proventia IPS нужно поставить и для  этого инженеры IBM предоставили нам имидж. Но ввиду того что IPS аппаратный комплекс, то имидж представляет собой Boot сервер, с которого устройство, при загрузке должно по DHCP получить IP адрес и после этого по TFTP подтянуть с Boot сервера имидж для перепрошивки устройства. После загрузки, в консоли устройства набираем reinstall и на устройство заливается новая прошивка.

Вообщем встал вопрос, как загрузить виртуальную машину VMware по протоколу TFTP. Для этого запускаем виртуальную машину и тут же входим в консоль и жмем F2 для того чтобы войти в виртуальный биос машины. Там выбираем Boot и плюсиком поднимаем позицию Network boot from AMD Am79C970A наверх. После чего сохраняем и перегружаем машину: все можем спокойно грузить по TFTP.

Рубрика: Подсказки | Ваш отзыв »