Надо отметить, что, порыв сообщества на тему атаки на хост ESXi, я не смог найти достаточно инфы об уязвимостях позволяющих получить доступ к ноде или соседям по ноде, поэтому собственно и решил, что оптимальным решением будет убрать хост в DMZ, предоставив к нему доступ из интернета и закрыв локалку. Другое дело что существуют различные варианты атаки на L2 OSI теоретически позволяющие ломануть DMZ на уровне VLAN’а, но это уже совсем другая история, не имеющая отношения к этой. Тем более что и современные средства организации VLAN’ов предоставляют богатый функционал защиты и минимизируют риски от подобных атак. Если кому то интересно покопать на тему атак на VLAN, то дам несколько ключевых букаф:
CAM flooding;
MAC flooding;
VLAN Cross-talk Attacks;
VLAN Hopping;
ARP spoofing;
Spanning-Tree attacks;
VRRP / HRSP tampering

У VMware, кстати, имеется специальный продукт под это дело, именуемый vShield Zones. Но сейчас не о нем речь.

Так вот- VLAN’ы: VMware понимает VLAN только одного типа Ethernet фреймов 802.1Q. Для организации VLAN желательно использовать технологию virtual switch tagging (VST), которая позволяет предотвратить часть атак L2 направленных на компрометацию MAC адреса, путем запрета его изменения, а также блокировок поддельных передач. Чуть более подробно можно прочесть на офф.сайте VMWare.  Более того, в отличии от VGT Mode, VST не требует дополнительно драйвера в операционке для поддержки 802.1Q транка, что естественно является неоспоримым преимуществом в плане простоты и легкости интеграции.

Перед манипуляциями с ESXi необходимо настроить свич, для чего переводим порт к которому подключается ESXi в состояние транка, не забывая про единственно поддерживаемый тип фрейма IEEE 802.1Q (dot1q). В режиме VST Mode ESX/ESXi  не поддерживает так называемые родной (native) VLAN ID, поэтому при присвоении портам того же VLAN ID что и на ESXi такие пакеты будут дропаться на стороне VMWare. Более подробно о настройке конфигурации VST, можно на офф.сайте.

Настраиваем VLAN транк на ESXi, для чего открываем WebSphere щелкаем на нашу ноду и в правом фрейме идем Configuration -> Networking -> Properties.
Выбираем виртуальный коммутатор (virtual switch / portgroups) во вкладке Ports и идем в его редактуру: General -> присваиваем номер VLAN в поле VLAN ID -> вкладка NIC Teaming -> из списка Load Balancing выбираем Route based on originating virtual port ID. После этого проверяем что в активных адаптерах кто то есть, после чего все сохраняем и тестим соединение с другой стороной VLAN’а.

Максимум что мне приходило на почту- это была первая версия Дыбалы, которую мне в свое время переслали ребята из РТКОММа и я тогда конечно намучился, получая по почте около 150 мегов. Так что когда 5-6 лет спустя я обнаружил у пользователя в почтовом ящике письмо с вложенным роликом на полгига, которые он пытался отправить по почте, я даже не удивился.

Вообще пользователей стоит приучать к тому, что максимальное вложение письма должно составлять 20-25 мегов, но и даже таких объемов идеально избегать, пользуясь архиваторами и не забывая о том, что почтовые программы (больше всего конечно мелкомягкие) любят дописывать от себя 10-15%. И если твой админ позволяет отправлять 30+ метров почты, то это не значит что на принимающей стороне работает такой же добряк. Вообще большие сообщения это головняк для админа, так как они загружают почтарь который вынужден держать сессию на получение такого письма, да к тому же забивают почту. Поэтому пользователей стоит приучать использовать другие механизмы передачи файлов через интернет. Естественно, что админ может предложить юзверям пользовать общедоступные веб-ресурсы, вроде депозита или рапидшары, но более корректно в моем понимании- это иметь собственный FTP сервер, позволяющий выкладывать и скачивать с него файлы.

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

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

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

На счет подключения к веб-серверу- тут все просто- просто прописываем либо субдомены для каждой папки, либо паролим каждую папку и даем адреса вида: наш_сайт/папка1

Но самое веселое во всем этом, что данная уязвимость была найдена итальянским безопастником Луиджи Ориемма аж в мае 2011 года, и данные о ней были переданы в Microsoft, которые разродились срочным патчем только после того, как данные об этой дырке просочились в инет.

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

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

Дело в том, что у Windows XP SP2 имеются ограничение на число одновременных сессий tcp (а точнее сессий согласования TCP half-open), установленное в режим 10. Сделано это было мелкомягкими умышленно, для ограничения распространения червяков и дос-атак, которые с выходом Windows XP расцвели буйным цветом, и в первоначальной версии Windows XP этого ограничение отсутствовало, но мелкомягкие посчитали, по своей обычной традиции, что нет смысла бороться за живучесть системы, и проще зарезать число конкурирующих сессий.  Причем в XP это реализовано на уровне системного файла TCPIP.SYS, который необходимо патчить с помощью программы: EventID 4226 Patcher Version 2.23d которая увеличит это число до 50.

Для того чтобы увеличить до максимума число возможных сессий в виндовой сетке, следует сделать следующее: запустить глобальные политики CTRL+R -> gpedit.msc ->Конфигурация компьютера -> Конфигурация Windows -> Параметры безопасности -> Локальные политики -> Параметры безопасности -> Интерактивный вход в систему -> выставляем его в 0 (отключение ограничения)

или же внести правки в следующий ключ реестра:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\CachedLogonsCount
изменив значение CachedLogonsCount на 50 или 0

В Vista SP2 и Windows 7 это ограничение уже было убрано из драйвера протокола, но в системе имеется ограничение на использование сетки для шаринга и печати, установленное в 20 соединений. Проверить это можно, вбив в dos-promt  (CTRL+R -> cmd) команду net config server, которая выведет максимальное число пользователей.

А также максимальное число входящих подключений к IIS, которое можно настроить через ключ реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpNumConnections (тип: DWORD, задав его от 5000 до 65536)

Собственно принципиальная схема работы следующая: FTP-сервер работающий под ProFTPd с хранением учеток в базе MySQL. К нему есессно подрублен контроль файлов и clamav. Сам сервак находится в DMZ за фаерволом, где на него подключены собственно порты 20, 21 и все выше 1024, для отработки пассива. Также ставим apache и открываем 80 порт на фаерволе, так как некоторым тупым бургам понадобится скачивать из локалок, а по своему опыту работы я неоднократно сталкивался с ситуацией когда у таких “васяток” банально нет чела который им мог бы объяснить как переключить ftp-клиента в пассивный режим, а факи которые им шлешь на почту, почему то не вспомогают. Вот для таких граждан необходимо также иметь web-сервер на котором завести некоторое количество папочек, запароленных на основе .htaccess.

Остальные пакеты это samba сервер, через который внутренние клиенты раскидывают файлы по папкам, с аутентификацией на уровне пользователей. Тут собственно можно сделать два варианта: либо разрешить прохождение smb пакетов из сетки через фаервол, либо засунуть сервак вторым интерфейсом в локалку, но это не особо хорошая идея, ибо хотя шансов что нам сломают ftp крайне мало, но все равно это получается лишний вход. В принципе можно его вывести вторым шнутом во внутренний DMZ, куда уже фильтровать пакетики от внутренних сетей. Такой ход более гиморный, но зато и наиболее спокойный.

Каждому юзверю, или отделу создается папка- желательно конечно с квотированием, иначе ftp-сервер превращается в неконтролируемую файлопойку похуже файл-сервера. В этой связи есть смысл подрубить еженедельную отправку на почту статистики вывода:
df -ah
du -ch -d 1 /ftphome

Теперь по защите всего это хозяйства, как я и сказал: на фаерволе делаем маппинг по портам, или же безусловную трансляцию, закрывая все порты ниже 1024 порта, кроме 20, 21 и 80 вовне, а внутрь от сервера пропускаем все или же только smb протоколы.

После чего все это дело настраиваем и радуемся жизни.

Приехал в офис и стал ломать голову каким образом все коннектится, ибо естественно ни в какой интернет пакеты не уходят, а ломятся на внутреннюю адресацию. В итоге оказалось, после длительных лазаний под столами и трейсов пакетов, что все замучено через так называемый wi-fi мост, с которым я морочился на уровне совмещения рутеров Linksys. Тоже самое поднимается на беспроводных точках доступа от D-link, но тут все было завернуто через оборудование Ubiquiti Networks- американского производителя беспроводного оборудования для 4G и WiMax.

До этого момента я с ними не сталкивался, и оказалось что все те мосты что я делал на указанном оборудовании- просто детский лепет по сравнению с кирогазами Ubiquiti, поскольку они используют их технологию AirMax Technology, позволяющую кидать канал в 100Мб на расстояния до 50 километров. Естественно что эти нереальные расстояния требуют специальных антенн и еще более специальных вышек, для того чтобы сигнал не гасился препятствиями, но расстояние в 2-3 километра, можно покрыть за счет стандартных передатчиков, установленных в зоне прямой видимости.

Другое дело, что для того чтобы все это реально заработало и было к тому же законно, то необходимо приобретать сертифицированное оборудование и получать разрешение гостехнадзора на организацию беспроводного моста.  Хотя вроде бы это можно обойти, если поднимать оптический мост, на лазерных передатчиках, но я что то новых решений найти не смог, кроме древнего Unlike OmniBeam 2000/4000, датированного началом 2YK. К тому же в России как я понимаю достать его, в отличии от оборудования Ubiquiti, практически невозможно. Так что вернемся к Ubiquiti Networks.

На их сайте представлено большое количество оборудования, но для наших целей построений Wi-Fi моста на стандарте 802.11 a/b/g подходит серия NanoStation или же NanoStation Loco, представляющие собой устройства с ethernet интерфейсом 10/100 BASE-TX, коим они подключаются к проводной локальной сети и способны устанавливать беспроводной мост на расстояния до 20 километров со скоростью 25Мб/с, что для терминального подключения, или прокинутого канала интерент в удаленный фоис- более чем достаточно. Также имеется более совершенное устройство Ubiquiti Rocket позволяющее поднимать скорость передачи данных до 100Мб/с.

По деньгам подобное решение получается примерно следующим:
Ubiquiti Rocket M5 стоит в районе 9к рублей, за два передатчика
Ubiquiti NanoStation обойдется где то в районе 6-7к рублей за два передатчика
Направленная антенна Rocket Dish 5G обойдется по 9к за антенну, то есть 18к рублей за прием-передачу
Ну и желательно чтобы в комплект входила грозозащита, предохраняющая активное оборудование от атмосферных разрядов, например Ethernet РГ4 PoE – районе 800 рублей за штуку

Если у нас расстояние небольшое, то мы вполне можем ограничиться парочкой NanoStation или NanoBridge с антигрозовой защитой (без приобретения дополнительных антенн), и подобное решение обойдется всего в 10-12к рублей по российским ценам за оборудование. Если же заказывать у производителя оборудования Ubiquiti Networks, то полагаю что возможно уложиться и вообще в 5-6к рублей.

Хотя это конечно не безопасно, особенно исходя из концепции параноидальности на сетевом экране, тем более что не далее как в этом феврале была найдена уязвимость BIND 9 ветки, приводившая к DoS севера имен, при трансфере зоны или динамическом обновлении, но тем не менее пропатчив BIND и открыв его только вовнутрь сетки, решил что пользовать можно.

И вот в процессе настройки, когда вроде бы named резолвился для localhost но почему то не хотел стартовать на внутреннем интерфейсе, я решил раскомментировать строку в named.conf содержащую следующее выражение:
query-source address * port 53;

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

Изначально я полагал, что допустил в синтаксисе правил какую то ошибку, из-за которой правила не догружались до конца, но оказалось что таблица правил фаервола была загружена полностью. Да и ssh висел на порту, а вот named почему то отсутствовал. Попытка его стартануть не увенчалась успехом, так что я полез в логи, где обнаружил что прописал в named.conf фалы для зоны “.” дважды, точнее я то прописал один раз, не заметив, что они уже были обозначены. Что и приводило к падению демона named. Но что еще более поразительно- это же и приводило к нестабильной работе сервера ssh, отрубавшего логин к серверу.

Судя по всему, в случае падения демона named, резолвить имена подключений не получалось, так как в /etc/resolv.conf стоял только 127.0.0.1, и по этой самой причине соединение и рубилось на корню.

Так что на всякий случай добавил в /etc/ssh/sshd_config строчку отрубающую резолв имен: UseDNS no , хотя, в принципе, можно было бы и добавить дополнительных DNS серверов в resolv.conf

Yota 4G:
в районе 2к рублей за модем (PC Express или USB-stick);
~5к рублей за wi-fi точку доступа на основе технологии 3G;
тарифные планы 1400 рублей в месяц, без ограничений на скорости до до 10 Мбит/сек downstream, до 3 Mбит/сек upstream;
Также можно подключиться за 700 рублей в месяц на скорости 512кб/c down и 128кб/c up;
Про лимиты трафа не сказано, а особо искать не было желания, так что принял за то что они отсутствуют

SkyLink 3G интернет:
порядка 2к за модем (PC Express или USB-stick);
точки доступа от 8к рублей, либо рутер D-Link за 3к + к нему модем от 3к рублей;
Тарифы от 900 рублей за безлимитный город и 2500 рублей за областной на скорости 3Мбит/сек.;
При превышении трафика порога в 2Гига, скорость падает до 128кб/c

Билайн 3G интернет:
1200 рублей за модем;
точек доступа я не обнаружил;
тарифный безлимит 450 рублей до 7,2Мб/c;
По истечении порога в 2 Гбайта, скорость доступа в Интернет снижается до 64 Кбит/c.

МТС 3G интернет:
1400 рублей за модем (2к если модем еще и с wi-fi рутером);
отдельный рутер 4к – с Ethernet портом;
безлимиты 750 рублей (лимит: 500 Мб в сутки, 8Гб в месяц) и 1350 рублей (лимит: 1Гб в сутки, 12 Гиг в месяц). Скорость в районе 3,6Мб/c;
При превышении суточного порога скорость падает до 64кб/c, то 3 утра следующего дня, при превышении месячного трафика до 16кб/с до конца месяца

Мегафон 3G интернет:
Модемы тоже в районе 1500 рублей;
безлимитка начинается от 500 рублей с лимитом в 2,5Гб, 800 рублей в 4Гб и далее, на скорости в районе 3Мб/с;
При превышении лимита трафика скорость падает до 64кб/с, но лимит можно увеличть на 1,5Гб (за 150 рублей) или на 3Гб (за 300 рублей)

Исходя из всего вышесказанного, для клиента я решил выбирать между йотой или МТС’ом, так как у последнего все выглядело наиболее интересно- как в плане цен, так и в плане правил ограничения на трафик мобильного интернета, поскольку 12 гиг в месяц давали порядка 400 метров в день, чего должно было бы хватить за глаза для серфинга и чтения почты, под угрозой анальной кары для сотрудников за скачивание файлов. Йота опять же выглядела убедительно, но есть опасение, что могут возникнуть проблемы с качеством связи вне пределов Садового кольца, тем более, что на улице где сидел клиент, судя по карте покрытия сети 4G, было несколько пятен, где доступ предполагался только на открытом воздухе.

Тогда как для себя, я, с подачи друга, нашел отличный вариант безлимитного мобильного интернета от Билайна за 300 рублей в месяц. Оказалась интересная особенность безлимитного 3G интернета, в том, что все лимиты на использованный трафик есть только у авансовых тарифных планов (всюду лимит в 1Гб, после чего скорость падает до 64 Кбит/c, а у МТС, как уже писал выше до 16Кб/c), тогда как у тарифного плана с постоплатой, таких лимитов нет, и подключение к интернету происходит на скорости 256 Кбит/с без ограничений по лимиту использования. Поскольку мне 256 Кбит/с было за глаза, то я и прикупил себе постоплатный план с 0 рублей абонентки и включил на ней безлимитный мобильный интернет за 300 рублей в месяц. Пытался найти под него PCMCI модем, но ехать на савелу- было не охота, так что купил за 1200 рублей какой то китайский момед Flyer U12, который на самом деле оказался каким то УГ, ибо скорость на нем почему то была ниже, чем на старенькой Nokia, когда я догадался вставить sim-карту в неё для теста, так что вероятнее всего дело в качестве приема, и, учитывая, что я победил iPhone и могу теперь выходить в интернет через bluetooth соединение, то и надобность в этом модеме совершенно отпала.

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

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

Для Мегафона:
*151#
Такчже если звонки разрешены, можно набрать в суппорт оператора: 0500.

Для МТС:
*123#
Также можно позвонить в службу поддержки МТС: 0887.

Для Билайн:
*110#
Опять же можно отзвонить в поддержку оператора, по номеру: 0611.

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

1. Если вы не планируете соскакивать из офиса через полгода, надо выделять место под постановку шкафа для патч-панели, на которую будет разводиться сетка, и коммутационного оборудования.
2. Если вы не можете выделить комнату под серверную, то хотя бы постарайтесь отгородить уголок где будет стоять оборудование и крайне желательно, чтобы шкафы запирались на ключик и были вне зоны действия безумных уборщиц, манагеров и прочего люда, который может выдернуть бесперебойник из сети, для того чтобы зарядить свой телефон
3. Админы не птицы, так что расшивать патч панель под потолком не самое приятное занятие. К тому же каждый раз лезть на стремянку чтобы посмотреть линкует ли кабель на неуправляемом свиче- на самом деле издевательство над инженером.
4. Оборудование имеет свойство греться, поэтому его желательно держать в комнате с работающим кондеем, а не бухгалтерами, которые летом открывают окна, так как боятся простудиться и в комнате стоит стабильные 35. Учтите что некоторые производители железа, например SUN, гарантируют работоспособность оборудования до 25 C в помещении.
5. Сетку надо разводить в одно место. Если такой возможности нет, то постарайтесь обеспечить наличие управляемых свичей, или хотя бы с гигабитными портами на борту, чтобы можно было соединить удаленные свичи по транку или же на скорости в гигабит.
6. При построении кабельной системы требуйте схему разводки, причем крайне желательно, чтобы расшивали сеть на патч-панель не как бог на душу положит, а по какому то алгоритму- например по комнатам.
7. Сетку надо кидать как минимум витой парой категории 5Е, желательно экранированной. Если вы настолько гениальны что пускаете слаботочку и силовые кабеля по одному коробу то экранирование маст-хэв. Если вы еще не поняли, то силовые кабели и слаботочку желательно вести разными каналами.
8. Гигабитную сетку оптимально разводить витой парой 6 категории. Не жлобитесь на кабельной системе- потом будите себя ругать дважды.
9. Никаких шаманств в расшитии восьмижильного кабеля на 2 джека, так как оптимальная скорость на 100Mb получается только за счет расшивания всех 4 пар. Работаю не все, но при расшитии по 2 пары- вопрос почему тормозит сетка- адресуйте себе.
10. Все провода должны заканчиваться патч-панелью, так как лапша из торчащих из стены кабелей- неуправляема.
11. Кабельную систему ведите в коробах, или фальш-потолках, полах. Никаких замуровываний кабелей в стену, так как в случае обрыва админ будет шаманить с лозой. Лучше пустите короб по полу, или же убирайте кабели в плинтуса.
12. Покупайте хорошие джеки и крамперы, так как дешевые и бракованные джеки могут портить оборудование.
13. Кабельная система должна идти одними маршрутами, а не разбегаться как тараканы по потолку.
14. Кабели в фальшпотолках убирайте в кабель-канал. Тоже самое касается и соединений офисов через нейтральную территорию. Даже убрав в него один кабель, вы практически 100% гарантируете то, что какой нить электрик офис-центра не рубанет вам сетку, перерезав неизвестный кабель.
15. Обжимайте кабели в соответствии со стандартами: европейскими или американскими. Никаких отсебятин, так как люди которые будут работать после вас, помянут вас хорошим словом, а не матерной бранью, обнаружив что вся сетка расшита по разному и выдержан только один стандарт- то что кабель прямой.
16. Не оставляйте длинных хвостов при прокладке кабеля- максимум 25-30 сантиметров. Если все таки оставили, то скрепляйте их кольцом стяжками или же теми же жилами витой пары.
17. Старайтесь избегать изломов кабеля.
18. Если вставляете розетку, то расшивайте её, а не сворачивайте кабель.
19. Подписывайте розетки и патч-панели. Каждый раз лезть в схему очень быстро надоедает.
20. Разводите всю СКС витой парой, так как в последствии будет проще эксплуатировать.
21. Прежде чем разводить кабельную систему- правильно посчитайте количество компьютеров и сетевых устройств в комнате, после чего добавьте еще 2-3 розетки.
22. Если внедряете какие то свичи или хитрые комбинации из кабелей- не ленитесь отображать это на схеме сети. Схема сети обязательна для наличия, так как на разведку боем новый админ потеряет  от пару дней до недель.

Вроде пока все что пришло в голову, если вспомню что то еще, то допишу позже.

Тогда приходится влезать в это болото, которое называется маршрутизация средствами Windows платформ. Для начала посмотрим что  у нас прописано в таблице маршрутизации на сервере. Входим в терминальную консоль cmd и даем команду:
> route PRINT
которая нам высветит список имеющихся в системе интерфейсов, таблицу маршрутизации и постоянные маршруты. Кстати точно эту же картинку можно получить и командой:
> netstat -rn
Теперь собственно мы можем добавить статический маршрут, средствами командной строки. Предположим что нам надо срутить пакеты в сеть 172.16.0.0/24 через внутренний маршрутизатор 192.168.10.250, для чего задаем следующую команду:
> route add 172.16.0.0 mask 255.255.255.0 192.168.10.250 if 1
на самом деле можно со спокойной совестью опустить, маршрут подцепится и без этого, просто пакеты будут рутиться через внутренний интерфейс 127.0.0.1. Для того чтобы удалить данный маршрут достаточно сказать:
> route delete 172.16.0.0
При добавлении машртура мы можем получить загадошное сервисное сообщение “Запрошенная операция требует повышения”, для чего правой клавишей шелкаем в иконку командной строки и говорим “запуск от имени администратора”.
Но вся беда с том, что такие маршруты живут до следующей перезагрузки, поэтому нам необходимо сказать чтобы маршруты сохранялись на потсоянной основе, для чего задаем ключик -p:
> route -p add 172.16.0.0 mask 255.255.255.0 192.168.10.250

Собственно для меня это наиболее удобный вариант, так как не требует ковыряния с системе, да и подходит как для Windows Server, так и для простых рабочих станций под управлением виндусни; но особо беспокойные умы могут  воспользоваться на MS Server службой Network Policy and Access Services, для чего идем в Диспетчер сервера -> Роли -> Добавить роли -> Службы политики сети и доступа -> Маршрутизация (автоматом добавится Служба удаленного доступа) после чего уже в оснастке управления маршрутизации через правый клик на имени сервера включаем машрутизацию и, зайдя в раздел Статические маршруты прописываем необходимые нам маршруты. Там же можно настроить и политики прохождения пакетов (вкладка Основное, свойства интерфейсов), а также динамическую маршрутизацию, путем добавления RIP или IGMP протоколов.

Так что не боясь предстать капитаном очевидность в этот раз я распишу как организовать программный маршрутизатор средствами FreeBSD. И хотя писалось все это еще под 4.2, но тем не менее и под 7.4 все эти же рецепты применимы, разве только с той разницей, что все пакеты отличаются версиями с большую сторону. Сказать откровенно, я предпочитаю программные маршрутизаторы за их дешевизну, простоту и быстроту в настройке, поскольку для программного маршрутизатора сгодится любая древняя машинка, главное чтобы в ней была возможность поставить дополнительные сетевухи. При этом программный маршрутизатор отличается от аппаратных аналогов тем, что произведя один раз настройку маршрутизатора вы следующий настроите уже за полчаса, а не будите копаться в мануалах нового для вас агрегата, купленного клиентом с оказией, не понимая почему це фича вдруг оказалась багой. К тому же вменяемый аппаратный маршрутизатор стоит не малых денег и вполне сопоставим по стоимости с хорошим компом, который помимо того что будет с сотни раз мощнее, также при этом сможет, естественно при желании, стать принт-сервером, фаерволом, проксей, поточным антивирем и еще чем угодно, и что самое основное- это решение маштабируемое, то есть добавление нового интерфейса сопряжено с гораздо меньшими затратами, нежели при попытке расширения аппаратного маршрутизатора, главное подобрать материнку с 2-3 слотами под сетевуху, ибо найти две интегрированные не проблема. И естественно формула скорость работы/цена для программного маршрутизатора будет на порядки ниже аппаратного, так как стоимость гигабитного маршрутизатора уже будет сопоставима с покупкой мощного сервера для офиса. Ну это просто вода относительно того за что я люблю программные рутеры, а теперь собственно перейдем к самой настройке маршрутизатора.

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

Собственно для начала имеем две сетки: 192.168.0.0/24 (основная) и 192.168.10.0/24 (дополнительная) которые нам и надо совокупить посредством нашего настроенного сервера FreeBSD, в который мы же загодя воткнули две-три-четыре и более сетевых карт (максимум который у меня прекрасно существовал было 5 сопряженных сетей, не считая вирутальных интерфейсов). Предположим что для сетевых интерфейсов мы выбрали IP адреса: 192.168.0.1 и 192.168.10.1

Смотрим что за интернерфейсы установлены в системе:
# ifconfig
тут нам главное понять какой интерфейс какой, для чего не плохо было бы ознакомиться с чипами карт. Порядок интерфейсов обычно идет от проца к периферии, а у дополнительных интерфейсов в зависимости от нумерации слотов, возрастая от видюхи. Но проверить все это можно эмперическим путем просто воткнув рабочий кабель в систему, посе чего интерфейс перейдет из статуса status: no carrier в status: active. Предположим у нас в системе два интерфейса rl0 и rl1.
Поняв какие интерфейсы будем сопрягать, идем в /etc/rc.conf и добавляем необходимый интерфейс, так как там уже должен присуствовать один из интерфейсов, если в процессе настройки системы FreeBSD мы поднимали сетку.
##### /etc/rc.conf #####
ifconfig_rl0=”inet 192.168.0.1 netmask 255.255.255.0″
ifconfig_rl1=”inet 192.168.10.1 netmask 255.255.255.0″
#####################
Чтобы поднять теперь интерфейс, выполним
# /etc/netstart
Второй интерфейс rl1 ожил и теперь пингуется из подсети 192.168.10.1, но для того чтобы сервер настроить как маршрутизатор необходимо в ядре разрешить пересылку пакетов между пакетами, за что отвечает парметр net.inet.ip.forwarding. Его значение в системе в данный момент:
# sysctl net.inet.ip.forwarding
net.inet.ip.forwarding: 0
где значение 0 означает что маршрутизация запрещена, поэтому для включения функционала маршрутизации, нам необходимо присвоить этому значению 1, для чего выполняем:
# sysctl net.inet.ip.forwarding=1
net.inet.ip.forwarding: 0 -> 1
Теперь настройка маршрутизации завершена и маршрутизатор будет фурычить до перезагрузки системы, после чего значение net.inet.ip.forwarding переключится обратно в 0. Для того чтобы избежать этого добавляем в файл /etc/rc.conf следующую строку:
gateway_enable=”YES”
после чего уже безбоязненно можем перегрузить машину.
При такой схеме наш маршрутизатор будет рутить только сопряженные с ним сети, представленные интерфейсами, или же алиасами на интерфейсах, в том же случае когда у нас в сети уже существуют маршрутизаторы, прикрывающие еще какие то сети, то тогда поднимаем на нашей машине статическую таблицу маршрутизации. Делается это также в файле /etc/rc.conf
##### /etc/rc.conf #####
static_routes=”network1 network2 network3″
route_network1=”-net 10.10.15.0/24 192.168.0.25″
route_network2=”-net 172.168.10.0/24 192.168.0.25″
route_network3=”-net 192.168.168.0/24 192.168.10.111″
#####################
то есть мы задаем названия маршрутов, которые дальше выводим в виде сетки, и внешнего, для нашего маршрутизатора, интерфейса шлюза.
Также в случае использовании настроенного сервера FreeBSD в качестве внутреннего маршрутизатора, необходимо на внешнем шлюзе, заданном для рабочих станций и серверов сети дефолтным маршрутом, поднять маршрутизацию на внутреннюю сеть задав маршрут в 192.168.10.0, через 192.168.0.1. На самом деле тут обычно и возникает самый косячный момент, особенно в случае использования интернет шлюзом аппаратных фаерволов типо D-Link, у которых вроде функционал рутинга имеется, но чтобы настроить удаленный маршрут надо долго и упорно танцевать с бубном, так что гораздо проще для нашего уже настроенного маршрутизатора задать дефолтовым маршрутом интернет-шлюз, а все машины предприятия завернуть на него- это добавит лишний хоп, но уберет проблему настройки маршрутизации на сторонних серверах.

В итоге ребутнули сервак ESXi, все поднялось, так что вечером я выехал на удаленную площадку. Прибыв на место, немного пошакалил по свичам, ибо решил было, что проблема крылась в них, но все было вроде нормально, так что я приступил снова к настройке Untangle. Надо отметить, что я, как истинный российский одмин, хотя и веселюсь на эту тему, некоторое время уже как читаю мануал только после того как все сломалось, так что в данном случае я полагал, что официального wiki how-to-install untangle вполне достаточно для того чтобы поставить платформу. Стартанул сервак на ESXi, и как только, судя по процентным соотношениям загрузки, платформа запустила сетевые интерфейсы у меня снова полегла сеть. Это меня подвигло в совершеннейшие не понятки, поскольку сеть лежала наглухо- то есть она отсутствовала как класс- пинги не проходили даже до свича, в который была воткнута машина, не говоря уже про какие то шлюзы и сервера, сидевшие на соседях по каскаду. Рубанув сервер, снова поднял ESXi и удалил с него Untangle, решив поднять его в тестовом варианте у себя на машине. В итоге на след. день, подняв его в оболочке VMware Workstation я так же радостно положил сетку своего офиса, но поскольку доступ к виртуальной среде у меня уже был не по сети, то отрубив интерфейсы на виртуально машине, я полез в инет с извечным вопросом “whatafuck?”.

Оказалось, что в платформе Untangle реализована технология Re-Router (до этого мне с ней как то не доводилось встречаться), благодаря которой данная платформа безопасности  интегрируется в существующую сетевую топологию без каких либо дополнительных перенастроек инфраструктуры, путем заворачивания на себя всего трафика на уровне L2 протоколов. Примерно тоже самое происходит при уязвимости men-in-middle, когда машина внутри сетки производит так называемую атаку ARP spoofing, отвечая на все ARP broadcasts “ЭТО ЙА!” и тем самым беря на себя функционал центрального шлюза и вообще всех машин в сетке, так что в ARP таблице свичей все пакеты замыкаются на интерфейсе Untangle,и даже после падения платформы трафик не будет проходить до динамического изменения ARP таблицы.  Данная технология интегрирована в ядро, и в первом приближении не отключабельна, так что на форуме Untangle тамошние спецы рекомендуют относиться к ней как к данности, и в этой связи, в обязательном порядке, использовать на сервере два интерфейса, даже в случае необходимости использования одного- как в моем варианте VPN-сервера. Но в этом случае рабочий интерфейс надо делать внешним, а внутренний переводить в режим bridge и бриджевать его на внешний интерфейс
Настройка в админской части Untangle: Config -> Networking -> Internal Interface
Config Type: bridge
Bridge to: External (static)

Кстати таким же образом можно организовывать проброс трафика к внешнему шлюзу, но это уже другой разговор. В случае виртуальной машины, как у меня, я просто добавил в работающую конфигурацию еще один интерфейс, подтянул его встроенным detect’ом и привязал к внешнему интерфейсу, после чего лежащая сетка ожила в течении 30 секунд. Еще в течении 15 минут поднял VPN-сервер и настроил подключение. Самое приятное, что openVPN сервер сам генерит клиентскую часть, так что просто логинимся через бродилку к VPN-серверу, заходим внутрь и из настроек openVPN сервера, раздела Clients, говорим для определенного пользователя Distribute Client, после чего либо скачиваем его по приложенным ссылкам, либо отправляем его на email который можно вписать в форму отправки. Клиент после установки получает полностью настроенный OpenVPN клиент, не требующий уже никаких вводов логина и дополнительных настроек.

Но в процессе запуска- выяснилось что машинка не подхватывает IP адрес по DHCP, при работе в bridged mode, а при попытке задать статический IP я получал ругань на тему того, что данный IP уже используется, при том что данный адрес был однозначно свободен. Озадачившись данной проблемой проверил на всякий случай фаервол винды, но как оказалось он был отключен. Поковырявшись в меру возможностей в серваке и vmware, решил не озадачивать клиентского админа, а переставил Player на Workstation и попробовал поднять виртуалку в таком варианте. Но проблема осталась той же самой, при этом когда я переключил сетки в NAT вариант-  поднимался внутренний IP и все начинало нормально шуршать.

В итоге обратился к админу с описанием проблемы и предположением о том, что какая то тулза препятствует нормальному прохождению пакетов, выступая видимо фаерволом. Поковырявшись, админ сказал что обнаружил что на серваке зачем то был установлен, тысячу лет назад, kerio vpn client, который он благополучно снес. После данной манипуляции все зашуршало прекрасно, так что причина крылась именно в kerio vpn client который видимо как любой ipsec клиент имеет встроенный фаервол у которого имеются свои взгляды на прохождение пакетов. У клиента от checkpoint, например, таких проблем замечено не было.

Так что попробовал не особо веря что получится и в итоге пришло письмо от гугля что бабки ушли, через два дня капнули на вебманю, так что теперь рассказываю что и куда.
Для начала идем и регаемся на сайте рапиды- для регистрации указывается мобильник, который необходимо иметь под рукой, так как он будет основным способом связи с вами от сервиса. Имя необходимо зарегать то же самое, что у вас зарегано и в самой системе Google Adsense, тем более что если платеж не пройдет на электронный счет, то башли уйдут обычным путем.

После того как все прошло успешно и вам вылали первый PIN- не выбрасывайте его, ибо он и будет служить паролем для вашего входа на сайт, где в качестве логина используется номер мобильного, без цифры 8. Заходим в личный кабинет, с использованием приведенных ранее параметров, и далее идем создавать шаблон для вывода бабосов: верхнее меню ПЛАТЕЖИ -> левый сайдбар СОЗДАНИЕ ШАБЛОНА -> Платежные системы -> Webmoney

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

Все- теперь идет в Google Adsense – в настройки платежей, и заполняем инфу для вывода: вкладка Мой Аккаунт -> поле Назначение платежа -> раздел Назначение платежа ->  кнопка Настройка Rapida -> где все заполняем теми же именами и фамилиями что и в Рапиде, после чего пишем адрес куда доставлять и (ВНИМАНИЕ!!!) в поле Номер шаблона в “Рапиде” прописываем именно тот уникальный номер, что был присвоен нашему шаблону (чтобы обновить в памяти, проходим в Рапиде по следующему пути: Рапида -> Личный кабинет -> Платежи -> Шаблоны и срисовываем поле Уникальный №. Как пишут люди- если в поле Номер шаблона в “Рапиде” , то бабки просто капнут на аккаунт в Рапиде и вы сможете сами распоряжаться своими бабками как пожелаете- благо там есть все, от вывода бабосов на карту, до коммунальных платежей, но меня история с вебманями устраивает более всего.

Чего и вам желаю!

На D-Link сайте нашел веселые картинки, показывающие как и что сделать, но поскольку мне их публиковать ломы. то распишу руками.
1. Логинимся на рутер
2. Создаем объект на который будем пробрасывать порты:
Objects -> Address Book -> InterfaceAddresses -> Add IP4 Address
Name: Имя-сервера
Address: IP-адресс сервера
3. Создаем правила проброса портов:
Rules -> IP Rules -> Add IP Rule Folder -> Входим в новую папку и Add IP Rule (две штуки)

3.1. Правило проброса:
Вкладка General:
Action: SAT
Service: rdp
Source (interface/network): any/all-nets
Destination (interface/network): core/wan_ip
Вкладка SAT:
Включаем кнопочка на Destination IP
New IP Address: Имя-сервера (из п.2)
New Port: 3389
Включаем чекбокс: All-to-One Mapping: rewrite all destination IPs to a single IP

3.2 Правило прохождения пакета:
Вкладка General:
Action: Allow
Service: rdp
Source (interface/network): any/all-nets
Destination (interface/network): core/wan_ip

По версии D-Link на этой торжественной ноте можно говорить: Configuration -> Save and Activate, но у меня после этого канал поднимался где то на полторы минуты, после чего соединение висло, а рутер говорил что он был перезапущен из-за ошибки: “Could not establish bi-directional communication after configuration upload”. Зная как работает D-Link, я пришел к тому, что второе правило, которое гарантирует прохождение пакета- не отрабатывает тот самый пресловутый  bi-directional , который D-Link обещает всем выбравшим в действии правила Allow, для того чтобы не создавать два правила туда и назад. Но це оказалась не фича, а бага, поэтому я добавил третье правило:

Вкладка General:
Action: Allow
Service: rdp
Source (interface/network): wan/Имя-сервера (из п.2)
Destination (interface/network): any/all-nets

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

Для этих целей мы закупили Wi-Fi рутеры Linksys WRT 160NL- совершенно новые модельки, которые гонятся уже под лейблом Cisco. Но к сожалению родная прошивка рутера не позволяет поднять подобный функционал, по этой самой причине пришлось обратиться к кастомной прошивке DD-WRT, которая базируясь на открытом коде Linux’ового ядра, значительно расширяет функционал обычных рутеров. Я уже имел некоторое количество экзерсисов с этой прошивкой, когда пытался подключить другу torrent клиента и монтирование NTFS’ных дисков на рутере, и если дойдут руки, то о результатах отпишусь позднее. А пока создаем распределенную беспроводную сеть на двух (можно и более) рутерах Linksys WRT 160NL.

Для начала качаем кастомную прошиву с сайта DD-WRT и перепрошиваем основной рутер. Условно назовем его MAIN-AP. Выбираем прошивку для своего рутера, на данный момент актуальная версия v24 SP2 (SVN revision 14896), скачиваем, после чего подключаемся к рутеру через LAN кабелюку и проходим: Administration ->
Дожидаемся завершения прогресса перепрошивки и заходим в консоль администратора. Вводим имя пользователя и новый пароль, после чего настраиваем рутер для работы в обычном режиме- задаем настройки внешней сетки, внутренней, DHCP сервера и Wi-Fi сети. Также необходимо отключить встроенный брандмауэр ибо он может помешать взаимодействию сетевых устройств.

После этого переходим к настройке вторичного рутера. Назовем его Bridge-AP. Для начала задаем ему внутреннюю сетку из того же пула, что и была задана для Main-AP, и отключаем внешний интерейс и DHCP сервер, ибо адреса у нас будет раздавать первичный AP: идем Setup -> Basic Setup и расставляем галочки следующим образом
Connection Type: Disabled
STP:  Disabled
DHCP Server: Disable

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

Далее переключаемся из режима шлюза в режим рутера: Setup -> Advanced Routing и в выпадающем меню ставим Router. Отрубаем также брандмауэр ибо он может мешать работе AP: во вкладке Security -> Firewall отключаем все галки кроме Filter Multicast, после чего отключаем SPI firewall переключая в статус Disable.

После этого переходим к настройке Wi-Fi:
Идем в основные настройки Wi-Fi: Wireless -> Basic Settings и выставляем следующие параметры
Wireless Mode : Client Bridge
Wireless Network Mode : аналогично настройкам MAIN-AP
Wireless Network Name(SSID) : аналогично настройкам MAIN-AP
Wireless Channel : аналогично настройкам MAIN-AP
Wireless SSID Broadcast : аналогично настройкам MAIN-AP
Network Configuration : Bridged

Переходим к разделу настройки безопасности Wi-FI: Wireless-> Wireless Security
Выставляем тип безопасности (WEP, WPA или WPA2-Personal) аналогично настройкам MAIN-AP, точно также задаем и алгоритм шифрования: TKIP, AES, или  TKIP + AES, после чего вводим фразу что мы использовали при настройке MAIN-AP.

Сохраняемся и говорим Administration -> APPLY Settings после чего выключаем рутер, относим его в другое помещение и подключаем его прямым кабелем из его LAN порта в LAN порт рутера MAIN-AP, после чего включаем. Вуаля- у нас в обоих помещениях теперь пашет один и тот же SSID, так что тыкая из одной части зала в другую мы даже можем не заметить, когда мы перейдем на другую AP.

*** Единственный косячный момент который я заметил при работе с DD-WRT именно на Linksys заключается в том, что работать надо в IE ибо в Firefix web-интерфейс почему то подглючивает с завидным постоянством.
Тип шифрования рекомендую выставлять mixed на обоих рутерах, ибо в этом случае скорость передачи данных выше.
Также у меня возникли проблемы с раздачей репитером wi-fi в случае если запрещено широковещательное объявление SSID, поэтому пришлось транслировать имячко сети в эфир.

Обновление от 11.02.2011:  очень странная тема, ибо это решение у меня прожило в районе суток, после чего вторичный рутер перестал раздавать wi-fi в принципе, так что перепробовав 4 возможных прошивки, и перенастроив все решение раз 50, остановился на том, что у меня оба устройства работают в режиме AP. Криво в теории, но на практике работает пока нормально- продолжаю искать причину не понятного глюка.

Это говорит нам о том, что функционал LACP отрубает порты. Сам LACP (Link Aggregation Control Protocol) это протокол обеспечивающий работу транка, то есть объединение нескольких каналов в один для увеличения пропускной способности. Агрегированные каналы LACP используют для повышения пропускной способности канала и для и повышения отказоустойчивости.
Смотрим статистику конфигурации самого LACP

Chife-0# show lacp
LACP

ORT LACP TRUNK PORT LACP LACP
NUMB ENABLED GROUP STATUS PARTNER STATUS
……………..
35 Passive 35 Down No Success
36 Passive 36 Up No Success
37 Passive 37 Down No Success
38 Passive 38 Up No Success
39 Passive 39 Up No Success

LACP исходя из статистики пребывает в passive режиме, но при этом блокирует порты. Происходит это из-за того, что когда порт поднимает линк, passive LACP запрещает его использование до тех пор пока соединение не стабилизируется и не выяснится что это активное соединение. Если утверждение верно, то создается транк, если нет, то порт освобождается.

Для решения данной проблемы есть несколько ступенчатых вариантов разрешения проблемы:
1. Обновить версию прошивки свича до последней стабильной версии.
2. Проверить чтобы на обоих окончаниях сетевого кабеля выставлена одна и та же скорость и нет конфликтов: то есть с обоих сторон должна стоять или Auto-Auto или 100FDx -100FDx, но никак не Auto-100FDx
3. Если все вышесказанное не помогло, то можно отключить LACP если мы не используем его функционал для создании транка. При отключении данного функционала ничего не теряется ибо остается еще два варианта создания транков: HP port trunking (который использую я) и FEC.
Для этого опять же заходим в консоль и далее даем команды:
Chife-0# con t
Chife-0(config)# int all
Chife-0(eth-1-48,Trk1)# no lacp
Chife-0(eth-1-48,Trk1)# write mem

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

switch# config
switch(config)# clock set MM/DD/YYYY HH:MM:SS
switch(config)# wr mem

Немного воды:

Для задачи поддержки обратной зоны существует специальный домен IN-ADDR.ARPA. Сам файл описания зоны домена обратного просмотра состоит преимущественно из записей PTR типа “Pointer”.

[name][ttl] IN PTR [host]

то есть для сервера ns.server.ru c IP= A.B.C.D запись будет следующего вида

$ORIGIN C.B.A.in-addr.arpa.
D PTR ns.server.ru.

или же

123.46.181.62.in-addr.arpa. IN PTR ns.server.ru.

просмотреть информацию об имеющейся реверсивной записи можно командой:

# dig -x A.B.C.D

там же, кстати, можно увидеть и того, кто является ответственным за поддержку пула адресов. Также посмотреть ситуацию по по PTR в том числе можно на сайте http://www.squish.net/dnscheck
Опять же информация по ответственному за пул адресов можно получить командой:
# whois IP

Основной вывод:

В связи с чем еще раз хочу сказать с полной ответственностью- PTR запись размещает у себя провайдер, или тот кто является обладателем пула IP адресов. Хотя ленивый провайдер и может делегировать право ведения обратной зоны и серверу ответственному за поддержку основной (в смысле организации) или предоставить возможность удаленного управления своим сегментом.Делегирование осуществляется перенаправлением запросов на другие сервера, путем создания обратной зоны, состоящей из записи синонимов CNAME.

Например для сети провайдера 172.16.10.0/24, разбитой на подсети 172.16.10.0/25 ; 172.16.10.128/26 ; 172.16.10.192/26 это будет выглядеть так:

############################################
$ORIGIN 10.16.172.in-addr.arpa.
@ IN SOA ns.provider.ru. dnsmaster.provider.ru. (…)
;
; пулл 0-127 /25
;
0/25 IN NS ns.a.ru.
0/25 IN NS ns.a-slave.ru.
;
1 IN CNAME 1.0/25.10.16.172.in-addr.arpa.
2 IN CNAME 2.0/25.10.16.172.in-addr.arpa.
;
; пулл 129-191 /26
;
128/26 IN NS ns.b.ru.
128/26 IN NS ns.b-slave.ru.
;
129 IN CNAME 129.128/26.10.16.172.in-addr.arpa.
130 IN CNAME 130.128/26.10.16.172.in-addr.arpa.
;
; пулл 193-255 /26
;
192/26 IN NS ns.c.ru.
192/26 IN NS ns.c-slave.ru.
;
193 IN CNAME 193.192/26.10.16.172.in-addr.arpa.
194 IN CNAME 194.192/26.10.16.172.in-addr.arpa.
############################################

Сама же организация обязана вести на своем NS сервере запись вида

############################################
$ORIGIN 0/25.10.16.172.in-addr.arpa.
@ IN SOA ns.a.ru dnamaster.a.ru (…)
IN NS ns.a.ru.
IN NS ns.slave.ru.
;
1 IN PTR host1.a.ru.
2 IN PTR host2.a.ru.
3 IN PTR host3.a.ru.
############################################

Для двух других блоков адресов SOA записи будут соответственно:
$ORIGIN 128/26.10.16.172.in-addr.arpa.
@ IN SOA ns.b.ru dnamaster.b.ru (…)

$ORIGIN 192/26.10.16.172.in-addr.arpa.
@ IN SOA ns.c.ru dnamaster.c.ru (…)

*** По мотивам двухчасового разговора по аське с гуру piv_m

Приложение доступно для FreeBSD (тестировано для 7.2 версии), Linux (тестировано для RHEL, SuSe, Debian и Fedore), Windows XP/Vista/2003,а также для Mac OS X (10.4 и 10.5).

Первое, что пришло в голову это воспользоваться стандартной функцией управляемого свича Bandwidth Control , то есть ограничение скорости по порту- наиболее дешево и сердито, но как оказалось, например для имеющихся у клиентов HP ProCurve 2ХХХ серии данный функционал оказался недоступен, после чего погрузился в интернет с ключевым словом шейпер и bandwidth control . Варианты типо checkpoint не рассматривались, поскольку в первом приближении нужен был недорогой и простой аппаратный шейпер, хотя они и присутствуют начиная с safe@office в составе QoS, но устройства начального уровня мне не подходят, поскольку safe@office держит до 50-70 пользователей, а остальные начинаются от трешки зелени.
В результате нарыл некоторое количество моделек:

Для начала россыпью идут устройства от Planet: управляемый свич FGSW-2624SF и 8ми портовые гигабитники GSD-802PS / GSD-802S

почти в этом же ключе, хотя мне нравятся меньше, маршрутизаторы D-Link DGS-3610-26 / DI-1137C-1TP

какой то не понятный, но близкий сердцу названием маршрутизатор TP-Link TL-R480T

вроде как поддерживают большинство маршрутизаторов и рутеров от Linksys WRT310N / EZXS55W / EZXS88W / EZXS16W / WET610N / WRT160N / WRT610N / WRT110 но надо вчитываться в каждое дополнительно

как более дорогой аналог: Cisco Catalyst 3500  (команда Rate Limiting)

ну и наколенные варианты Zyxel P-334WT EE которые я не очень лю, поскольку уже имел опыт неприятной работы с их оборудованием

Вариант с Planet мне понравился больше всего, поскольку пользовался ими длительное время и никаких нареканий на их оборудование не имею, кроме разве что слишком низкой цены но пораскинув немного мозгами, пришел к тому что не плохо было бы иметь на внешнем шейпере и ips с доступом к нефильтрованному трафику, поэтому вероятнее всего в ближайшее время буду настраивать шейпер под freebsd с прикрученным туда же snort’ом

Хосты:            256    128    64    32    16    8    4    2    1
Бит:            1    1    1    1    1    1    1    1    1
Маска подсети:        0    128    192    224    240    248    252    254    255
Кол-во подсетей:    1    2    4    8    16    32    64
Количество хостов:    254    126    62    30    14    6    2
Маска:            /24    /25    /26    /27    /28    /29    /30    /31    /32

В результате чего мы имеем для бинарной маски /24 маску подсети 0, количество подсетей 1 и 254 хоста в ней.
Если мы смещаемся на один бит вправо, то плюсуем его и получаем /25, для вывода маски прибавляем её к тем что она оставила за собой слева: 0+128=128. Это маска подсети, которых для данной маски 2 по 126 хостов в каждой, поскольку 128 – 2=126 (по одному уходит на адрес сети). Собственно вся хитрость, довольно быстро и практично. Если же хочется совсем простоты, то в инете полно ресурсов, которые с радостью проделают эту работу, за ленивого инженера, например этот.

Собственно картиночка очень наглядно демонстрирует положение дел с масками в A, B и C подсетях. Картиночку есессно тиснул, но очень удачно, отсюда

Нужно понимать, что основное преимущество tcpdump перед другими утилитами заключается в том, что в ней возможен подробный и ручной разбор пакетов. Также нужно помнить что по умолчанию tcpdump использует только первые 68 байт пакета, т.ч. если необходимо видеть больше, то следует использовать ключ -s number , где number количество байт которые следует захватить. В случае задания number 0 , произойдет полный захват пакета, поэтому лучше использовать значение 1514, что даст полный захват стандартного, для сетей Ethernet, пакета.
Список наиболее часто используемых ключей:
-c : задается проверка размера файла захвата перед каждой очередной записью захваченного пакета, если размер больше, то файл сохраняется и запись идет в новый файл
-e : выводится ethernet заголовок (канальный уровень) в каждой строке дампа
-i any : прослушивание всех интерфейсов, на случай если вам необходим весь трафик.
-n : запрещает преобразование адресов в доменные или символьные имена
-nn : запрещает преобразование адресов и портов в доменные или символьные имена
-q : Красткий вывод информации, за счет уменьшения вывода информации о протоколе.
-X : выводит как hex так и ASCII содержимое пакета
-v, -vv, -vvv : задает вывод дополнительной информации о захваченных пакетах, что дает возможность более широкого анализа.
Несколько примеров для использования:

# Стандартный вывод пакетов
tcpdump -nS
# Расширенный стандартный вывод
tcpdump -nnvvS
# Глубокий разбор пакета
tcpdump -nnvvXS
# Наиболее подробная информация о трафике
tcpdump -nnvvXSs 1514

Выражения позволяют производить более целевое сканирование и задавать типы трафика. Умение использовать выражения делает tcpdump весьма продуктивным инструментом, в рукам сисадмина. Существует три основных типа выражений: type, dir, and proto.
Опции выражжения type бывают host, net и port.
Для выражения направления задаваемого dir существующие опции src, dst, src or dst, и src and dst.
Несколько стандартных выражений:

host // анализ трафика на основе IP адреса ( также работает с символьными именами, если не задано -n)
tcpdump host 1.2.3.4

src, dst // анализ трафика тольуо для определенного назначения или передатчика
tcpdump src 2.3.4.5
tcpdump dst 3.4.5.6

net // захват трафика принадлежащего определенной сети
tcpdump net 1.2.3.0/24

proto // работает с tcp, udp, и icmp. Нужно помнить что proto не упоминается
tcpdump icmp

port // анализ трафика с определенного порта (входящего или исходящего)
tcpdump port 3389

src, dst port // фильтр базируется на входящем или исходящем порту
tcpdump src port 1025
tcpdump dst port 3389

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

AND
and or &&
OR
or or ||
EXCEPT
not or !

TCP трафик с ресурса 10.15.123.33 с портом назвачения 3379:

# tcpdump -nnvvS tcp and src 10.15.123.33 and dst port 3379

Трафик переходящий из сети 192.168 с назначением на сети 10 или 172.16:

# tcpdump -nvX src net 192.168.0.0/16 and dst net 10.0.0.0/8 or 172.16.0.0/16

Non-ICMP трафик с точкой назначения 192.168.0.2 и из сети 172.16:

# tcpdump -nvvXSs 1514 dst 192.168.0.2 and src net 172.16.0.0/16 and not icmp

Трафик с хостов Eros or Ares , но не идущий на стандартный SSH порт (для данного выражения требуется разрешение имен):

# tcpdump -vv src eros or ares and not dst port 22

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

Также следует помнить о том, что мы можем строить запросы, включающие группы и пулы опций, заданных в одном запросе. Но для того чтобы утилита tcpdump обращала на них внимание их нужно помещать в скобки, беря выражение в одиночные кавычки:
Трафик идущий с хоста 10.0.2.4 на порты назначения 3379 или 22:
# tcpdump ’src 10.0.2.4 and (dst port 3379 or 22)’

Также возможно производить фильтрацию на основе TCP флагов, например для вычленения SYN или RST пакетов:

Анализировать все URG пакеты:
# tcpdump ‘tcp[13] & 32 != 0′

Анализировать все ACK пакеты:
# tcpdump ‘tcp[13] & 16 != 0′

Анализировать все PSH пакеты:
# tcpdump ‘tcp[13] & 8 != 0′

Анализировать все RST пакеты:
# tcpdump ‘tcp[13] & 4 != 0′

Анализировать все SYN пакеты:
# tcpdump ‘tcp[13] & 2 != 0′

Анализировать все FIN пакеты:
# tcpdump ‘tcp[13] & 1 != 0′

Анализировать все SYN-ACK пакеты:
# tcpdump ‘tcp[13] = 18′

Нужно помнить что фильтр обрабатывает данный запрос следующим образом, проверяет 13 байт заголовка TCP пакета и заданный байт флага, на соответствие условию, например:
tcpdump ‘tcp[13] & 2 != 0′ – просмотр и сравнение 13 и 2 байтов заголовка, на условие что данные не равны 0, т.е. заданы 1.

Анализ специализированного трафика:

Анализировать весь IPv6 трафик:
# tcpdump ip6

Анализировать весь трафик с имеющимися флагами SYN и RST:
# tcpdump ‘tcp[13] = 6′

Анализировать весь трафик с имеющимся “evil bit”:
# tcpdump ‘ip[6] & 128 != 0′

Естественно что приведенные примеры не могут охватить всю полноту использования столь мощного инструмента как tcpdump, поэтому как обычно, лучшим другом сисадмина был и остается:
# man man
надеюсь что данная статья сможет несколько облегчить непростой опыт общения с этой замечательной программой

Сервер крутится под Cent OS 5.2, хотя судя по всему все это же действительно и для RHEL . Для начала мы приходим к тому, что не смотря на то, что сервер NFS отсутствует в возможных вариантах установок, он как класс присутствует в системе.
Скрипт запуска сервера находится /etc/init.d/nfs, конфиг сервера /system/config/nfs

Создаем папки для выгрузки логов:

# mkdir -p /archive/phemars                                 # второй каталог аналогичен имени MARS Box
# chown -R nobody:nobody /archive
# chmod -R 777 /archive

В конфигурационный файл /etc/exports задаем каталог, опции монтирования и IP-клиента для каталога выгрузки

/archive/phemars    MARS_IP_Address    (rw)

после изменения этого файла необходимо рестартнуть (reload) демона nfs.

Рестартуем сам сервис

# /etc/init.d/nfs restart

После чего на циске говорим:

# export config IP-Server:/archive/phemars

и получаем ошибку что невозможно подмонтировать. Включив мозг мы приходим к тому, что надо смотреть tcpdump и  логи, откуда выясняем что на нашей системе по умолчанию крутится фаервол iptables, т.ч. открываем на редактирование свод его правил (/etc/sysconfig/iptables), либо задаем правила из командной строки, и открываем следующие порты:

### Для RPC
-A INPUT -i eth0 -p tcp -m tcp –dport 111 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp –dport 111 -j ACCEPT
### Для NFS
-A INPUT -i eth0 -p tcp -m tcp –dport 2049 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp –dport 2049 -j ACCEPT
### Для rpc.statd
-A INPUT -i eth0 -p tcp -m tcp –dport 4000 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp –dport 4000 -j ACCEPT
### Для lockd
-A INPUT -i eth0 -p tcp -m tcp –dport 4001 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp –dport 4001 -j ACCEPT
### Для mountd
-A INPUT -i eth0 -p tcp -m tcp –dport 4002  -j ACCEPT
-A INPUT -i eth0 -p udp -m udp –dport 4002  -j ACCEPT
### Для rpc.rquota
-A INPUT -i eth0 -p tcp -m tcp –dport 4003  -j ACCEPT
-A INPUT -i eth0 -p udp -m udp –dport 4003 -j ACCEPT

########  или же одним веским словом для 4 последних
-A INPUT -i eth0 -p tcp -m tcp –dport 4000:4003  -j ACCEPT
-A INPUT -i eth0 -p udp -m udp –dport 4000:4003 -j ACCEPT

Также следует указать следующие параметры для демонов в файле /etc/sysconfig/nfs
# для сервера rpc.nfsd
RPCNFSDARGS=”–port 2049″

# для сервера mountd
MOUNTD_PORT=4002

# для настройки rpc.rquota новых версий
RQUOTAD_PORT=4003

# для настройки rpc.rquota старых версий необходимо (пакет quota 3.08+) добавить в /etc/services
rquotad 4003/tcp
rquotad 4003/udp

# для сервера lockd
LOCKD_TCPPORT=4001
LOCKD_UDPPORT=4001

# для сервера блокировки на старых системах следует добавить в /etc/modprobe:
options lockd nlm_udpport=4001 nlm_tcpport=4001

# для сервера rpc.statd
STATD_PORT=4000

#Стартуем все сервисы
service nfs start
service nfslock start

Все, повторяем все действия по выгрузке конфига и видим, что mars выгрузил данный под каким то неопознанным пользователем (у нас его uid был 500), собственно для чего мы и клали маску 777

* Если что то не получается, то можем попытаться подмонтировать том к локальной машине, для чего вносим изменения в файлик /etc/exports , где указываем внешний айпишник лоальной машины и говорим (сосбтвенно так и поймали проблему с пользователями, т.к. локальный mount создает файлы с uid nfsnobody)
mount -t nfs -users eth0_IP:/archive/phemars /mnt

***  В наиболее гиморных местах помогло
очень грамотное описание сервиса
на сайте BOG

Наглядную иллюстрацию этой картины, я получил вчера на семинаре, посвященном новому поколению продукта Checkpoint R70 Blades.  Семинар  был посвящен софтварной версии системы предотвращения вторжений IPS Blade, пришедшей на смену системе Smart Defense. Новую систему отличает повышенная производительность,  более совершенные механизмы обнаружения и защиты, и по заверению вендора, в ней решены печально известные проблемы работоспособности Smart Defense.

Так вот, собственно одна из лабораторных работ предполагала настройку VPN-1 с включенным IPS Blade стандартной конфигурации, и последующей эмуляцией атаки через систему.  После удачного завершения лабораторки стали разбирать логи на машине, которая была подключена к внешней системе через провайдера нового поколения Yota; и вот тут то и выяснился очень забавный момент, что с того момента как мы запустили IPS, буквально через полторы минуты, на машину пошли атаки различных типо: IP Fragments, Teardrop, Ping of death.

Teardrop – представляет собой DoS атаку, использующую уязвимость сборки пакетов при фрагментации: атакующая сторона посылает фрагменты перекрывающие друг друга, т.ч. при сборке на стороне жертвы пакета в цельное состояние, происходит зависание системы.

Ping of Death – также относится к DoS атаке, в результате которой атакующая сторона посылает echo запрос заведомо превышающий разрешенный размер для IP протокола в 65,535 байт, т.ч при получении данного запроса и попытке его обработки на удаленной системе происходит переполнение буфера, что в свою очередь приводит систему к  выходу из строя.

Ip Fragment – тип атаки направленной на безусловное установление соединения с атакуемой машиной, путем некорректной сборки фрагментированных пакетов.

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

Вообщем как говорила Рената Литвинова:  как страшно жить! Не знаю как Вы, а я в инет без защиты – ни ногой.

1. Зона покрытия: уменьшить зону покрытия то необходимого максимума, с тем, что ваша сеть не была доступна из вне здания.
2. Широковещательный SSID: Service Set IDentifier (SSID) специализированный технологический код, который прикрепляется к пакету, для идентификации пакета, как составляющей части сети. Когда на роутере задан широковещательный SSID, все приемные устройства в радиусе
приема, получают информацию о доступности данной сети. Для этого данный код необходимо отключать, с тем чтобы настраивать подключением к сети,
путем ввода SSID’а в определенную графу в настройках соединения. Рекомендуется изменять SSID от заданного по умолчанию, а также избегать
названий которые можно связать в вашей личностью-компанией (названия фирм, адреса, фамилии)
3. WPA/WEP шифрование: шифрование соединения препятствует свободному доступу к передаваемой информации, т.е. если атакующий сможет перехватить сеанс связи, то
для доступа к информации ему потребуется расшифровать имеющиееся пакеты, и зашифровать их с помощью того же ключа для дальнейшей передачи.
Существует два алгоритма шифрования: Wi-Fi Protected Access (WPA) и Wired Equivalent Privacy (WEP), причем одновременно использовать можно только один из них.
Но я бы не рекомендовал использовать WEP, т.к. он является по сути устаревшим и небезопасным стандартом, к тому же он доступен для расшифровки сторонними средствами.
Частая смена ключа шифрования, еще более повысит надежность сети
4. Управление ключами: Даже если применяется шифрование, необходимо часто менять ключ шифрования, т.к. в случае длительного сканирования
шифрованных передач, злоумышленник имеет шансы расшифровать его.
5. MAC адреса: Необходимо завести таблицу используемых MAC-адресов, для предотвращения несанкционированного подключения к вашей радиосети. MAC-адрес это уникальный адрес,
назначаемый производителем, своему сетевому устройству, будь то сетевая карта или управляемый свитч. В wi-fi роутерах есть возможность составлять листы доступа к каналу, с фильтрацией
по MAC-адресам, т.е для доступа в сеть – физический адрес карты должен быть занесен в список разрешенных. Злоумышленник может подделать передаваемый MAC-адрес, но для этого он должен знать
его идентификатор.
6. DHCP-сервер: Можно отключить динамическую раздачу IP адресов, оставив только статическую раздачу адресов, добавив используемые в ARP-таблицы.
7. RAS: Использовать сторонние методики аутентификации, как то сертификаты, Radius сервера. Это весьма трудоемкий процесс, и почти недоступен для домашнего использования, но с помощью него возможно наиболее полно защитить wi-fi сеть от несанкционированного доступа, т.к. помимо использования дополнительной аутентификации, при передаче данных, будут использоваться заранее сконфигурированные сертификаты.
8. VPN-сервер: Еще более усилить защиту канала, можно путем запуска поверх WPA Wi-Fi шифрованного канала VPN, со своими паролями и ключами шифрования, такие данные будут чрезвычайно устойчивыми к попыткам взлома шифрования.

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

Такой метод защиты более продуктивен, нежели традиционный ответный, т.к. до выхода заплатке по той или иной уязвимости. Может пройти как несколько недель, так и несколько месяцев. Некоторые уязвимости, вроде адобовских, или майкрософтовских не устраняются по полгода, но превентивная защита нейтрализует подобные уязвимости, на уровне работы сети, не позволяя использовать эти бреши. Точно таким же образом, в свое время, компании, использовавшие решения от ISS или Check Point, получали возможность защититься от таких вредоносных вирусов как Zatob, Sasser, Blaster и Slammer. С 1990 года количество приложений на сетевых серверах увеличивается экспоненциально, и они по-прежнему содержат множество уязвимостей, и только превентивная защита, способна по-настоящему противодействовать потенциальным угрозам, предупреждая их вредоносное действие.
Самая компания ISS является одним из лидеров в области исследований и разработки решений на рынке информационной безопасности. Компания имеет свой собственный центр по исследованию и разработке решений по обеспечению безопасности IBM ISS X-Force. Специалисты центра анализируют и выстраивают корреляционные схемы угроз, исходя из данных ежедневно получаемых по каналам ISS от своих партнеров и клиентов. Постоянно ведущаяся работа, по сбору и анализу данных угроз, позволяет компании ISS предлагать своим клиентам высококачественный сервис предотвращения угроз, чье количество, в последние годы, значительно увеличивается, причем по статистике за последние несколько лет, это увеличение происходит в геометрической прогрессии. Также, дважды в год, центр X-Force выпускает подборк отчетов Risk Report, включающий в себя статистическую информацию по всем аспектам угроз информационной безопасности, как то уязвимости систем, malware, спам, фишинг, уязвимости веб-технолгий и активность кибер преступности. Эти отчеты позволяют клиентам компании составлять собственные прогнозы, а также наглядно иллюстрируют ситуацию с ростом угроз безопасности.
У компании имеется несколько основных продуктов, о которых я подробно напишу в следующий раз, а пока просто перечислю: система централизованного управления SiteProtector , система предотвращения вторжений IPS, веб-фильтр Proventia Web Filter, программно-аппаратный комплекс оценки защищенности сети Enterprise Scanner, сканер уязвимостей сети Internet Scanner, решение для защиты почтового сервиса Proventia Network Mail Security и программный почтовый фильтр Proventia Mail Filter, а также серию многофункциональных устройств по защите сети «все-в-одном» Network Multi-Function Security. Все аппаратно-программные комплексы также доступны и в виде имиджем к VMWare, полностью эмулирующих работу устройства.
Вообщем после прослушивания презентации представителя IBM, сложилось очень приятное впечатление от продуктовой линейки, особенно понравилась система управления SiteProtector, т.к. помимо управления своими комплексами, он дает возможность анализа происшествий на серверах и оборудовании различных производителей, таких как Cisco, Check Point и другие.

**********************************************************

Несколько лет назад я работал в службе технической поддержки электронной почты университетского кампуса. Мне позвонил заведующий кафедрой статистики.
” У нас проблема с отправкой почты с кафедры”
Я:”В чем проблема?”
” Мы не можем послать электронную почту больше чем на 500 миль”
Я роняю чашку с кофе. “Повторите, пожалуйста?”
” Мы не можем отправить письмо адресатам, находящимся далее 500 миль отсюда”, повторяет завкафедрой. “Точнее, 520. Но не дальше”.
Я пытаюсь собраться с мыслями. Крыша начинает медленно меня покидать, но нельзя позволить крыше уйти в разговоре с завкафедрой. Даже завкафедрой статистики. “Хммм… Понимаете, принцип доставки электронной почты не зависит от расстояния. Почему Вы думаете, что не можете отправлять почту далее 500 миль?”

**********************************************************

читать дальше

Смена IP адреса уникальна для каждой отдельной операционной системы, и в данном мануале не рассматривается.  Рекомендую обратиться к мануалам OS, в случае если эта тривиальная процедура вызывает чувство беспокойства

Сценарий:
Host name сервера Smart Center ‘test’.  IP адрес = 10.0.30.200, и адрес на который мы хотим его сменить  10.0.30.150.

Кстати:
Для начала необходимо запросить новую лицензию в  Check Point User Center account.

Поехали:

1. Открываем SmartDashboard и правим объект политики  ‘test’
2. Меняем IP адрес во вкладке ‘General’ на новый IP
3. Правим вкладку Topology, изменяем старый IP на новый адрес, и кликом на OK закрываем объкт
4. Щелкаем  File -> Save.
5. Останавливаем SmartCenter сервер с помощью команды "cpstop"
6. Изменяем файл /etc/hosts file, чтобы ‘test’ перенаправлялся на 10.0.30.150
7. Изменяем IP адрес на внешнем интерфейсе SmartCenter сервера
   ***
   Не забыть поменять маршрут по умолчанию для внешнего интерфейса OS
8. Если лицензия сервера SmartCenter привязывалась к внешнему IP адресу, то изменяем лицензию для нового IP
9. Перегружам SmartCenter сервер
10. Пингуем host tets по его hostname, чтобы убедиться что резолв на новый адрес работает корректно
11. Подключаемся к SmartDashboard, проверяем и устанавливаем Security Policy.

Большинство функциональных возможностей описанных в модели OSI присутствует, в той или иной мере, во всех сетевых коммуникациях, но существует также модели OSI, где 2-3 уровня слиты воедино.

Семиуровневая модель OSI

7. Прикладной Уровень(Application Layer) Прикладной уровень отвечает за доступ приложений в сеть. На этом уровне партнеры связи установлены, качество обслуживания установлено, установление подлинности пользователя и секретность рассматриваются, и любые ограничения на синтаксис данных установлены. (Этот уровень – не приложение как таковое, хотя некоторые приложения могут выполнять функции прикладного уровня.) Задачами этого уровня является перенос файлов, обмен почтовыми сообщениями и управление сетью.
* FTP (англ.  File Transfer Protocol) – протокол передачи файлов
* TFTP (англ. Trivial File Transfer Protocol) – простой протокол передачи файлов
* Telnet (англ. TELecommunication NETwork) – терминальное соединение с удаленным хостом (текстовое управление)
* SMTP (англ. Simple Mail Transfer Protocol) – упрощенный протокол передачи почтовых сообщений
* CMIP (англ. Common Management Information Protocol) – общий протокол управления информацией
* SNMP (англ. Simple Network Management Protocol)- упрощенный протокол управления сетью
* NFS (англ. Network File System)- протокол сетевого доступа к сетевым файлововым системам
* FTAM (англ. File Transfer Access and Management) – метод доступа и управления переноса файлов

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

5 Сеансовый (Session Layer) Сеансовый уровень отвечает за установление сеансов обмена информацией между целевыми хостами.  Стек протоколов сеансового уровня обычно является составной частью функций трех верхних уровней модели.

4 Транспортный (Transport Layer) Транспортный уровень разбивает потоки информации на небольшие фрагменты (пакеты) для передачи их на сетевой уровень. Также занимается сборкой пакетов и контролем доставки и целостности переданных данных.

Наиболее распространенные протоколы транспортного уровня включают:

• TCP (англ. Transmission Control Protocol) – протокол управления передачей
• NCP (англ. Netware Core Protocol) протокол базирующийся на протоколе IPX. В сетях Netware служит для обмена информацией между рабочей станцией и сервером.
• SPX (англ. Sequenced Packet Exchange) — протокол последовательного обмена пакетами
• TP0-4 – протоколы передачи классов от 0 до 4

3 Сетевой Уровень (Network Layer) Сетевой уровень управляет передачей данных и маршрутизация пакетов на основе подсетей и  адресов. На этом же уровне происходит преобразование сетевых адресов в MAC-адреса, для дальнейшей передачи через нижние уровни.

Наиболее часто на сетевом уровне используются протоколы:

• IP (англ. Internet Protocol) – маршрутизируемый  межсетевой протокол, основа стека протоколов TCP/IP
• IPX (англ. Internetwork Packet Exchange)- протокол межсетевого обмена, основа стека протоколов SPX
• CLNP (англ. Connectionless Network Protocol) – сетевой протокол без организации соединений

2 Канальный Уровень (Data Link Layer)  Канальный уровень отвечает за фрагментацию, передачу и прием кадров данных. Этот уровень получает запросы сетевого уровня и использует сервис физического уровня для приема и передачи пакетов данных. Спецификации IEEE 802.x делят канальный уровень на два подуровня: управление логическим каналом (LLC) и управление доступом к среде (MAC).  LLC обеспечивает обслуживание сетевого уровня, а подуровень MAC регулирует доступ к разделяемой физической среде.

Наиболее часто используемые на уровне 2 протоколы включают:

• HDLC для последовательных соединений
• IEEE 802.2 LLC (тип I и тип II) обеспечивают MAC для сред 802.x
• Ethernet- множественный доступ с контролем несущей
• Token ring- сетевая структура с несущим маркером
• FDDI- оптиволоконная сеть
• X.25-протокол предачи наддных на основе телефонных сетей, с контролем ошибок
• Frame relay- протокол ретрансляции кадров

1 Физический Уровень (Physical Layer) Физический уровень принимает пакеты данных от верхнего канального уровня и преобразует их в оптические или электрические сигналы, соответствующие 0 и 1 бинарного потока. Эти сигналы посылаются через среду передачи данных на приемный узел. Механические и электрические/оптические свойства среды передачи определяются на физическом уровне и включаютя:

• Тип кабелей и разъемов
• Разводку контактов в разъемах
• Схему кодирования сигналов для значений 0 и 1

К числу наиболее распространенных спецификаций физического уровня относятся:

• EIA-RS-232-C, CCITT V.24/V.28 – механические/электрические характеристики несбалансированного последовательного интерфейса.
• EIA-RS-422/449, CCITT V.10 – механические, электрические и оптические характеристики сбалансированного последовательного интерфейса.
• IEEE 802.3 — Ethernet
• IEEE 802.5 — Token ring