Архив рубрики: LAN

Не открывается web-интерфейс HP 1910. Свитч не пингуется.

Если у вас достаточно крупная сеть и вы используете коммутаторы HP 1910, то вы тоже могли столкнуться с такой проблемой: в определенные моменты времени вы просто не можете открыть админку коммутатора и даже пинговать его не можете. Но при этом, с других компьютеров/серверов он вполне может открываться и пинговаться. И более того, если вы будете долго и упорно его пинговать — вам он тоже начнет отвечать! Причины этой, на первый взгляд непонятной проблемы, очень просты: у свичей HP 1910 очень маленькая ARP-таблица — 256 записей. Со временем, при работе в сети >256 хостов, она может заполниться на 100% и может случиться так, что ваш адрес туда не попадет.

Как это лечить:

  1. Для начала, необходимо все же попасть на свитч с какого-нибудь адреса (например, с DHCP-сервера — чаще всего запись о нем есть в ARP-таблице).
  2. Заходим в ARP-management и удаляем все динамические записи.
  3. Добавляем там же необходимые нам статические записи (например, IP-адрес и MAC того компьютера/сервера, с которого чаще всего осуществляется доступ к свичам). Полезно будет также добавить IP и MAC шлюза по умолчанию — это защитит от внезапного появления в сети еще одного шлюза (но в этом случае лучше еще и статическую запись MAC с привязкой к порту сделать).

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

Обновление прошивки HP 1910 через COM-порт

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

Для форматирования флэшки необходимо подключиться консольным кабелем, настроить соединение (38400, 8, 1, N) и нажать при загрузке Ctrl+B. Таким образом мы попадем в BootWare-меню. В нем необходимо нажать Ctrl+F и согласиться с форматирование флэшки. Желательно перед этим убедиться в наличии у вас свежей прошивки в виде файла *.bin :)

Далее перезагружаем коммутатор и снова входим в BootWare. На этот раз он сделает это сам — прошивки-то нет. В Bootware выбираем пункт 2 «Enter Serial SubMenu». Т.к. файл прошивки весит более 10 Мб — лучше переключить Serial-интерфейс на скорость 115200. Для этого жмём и снова 5 (пункт 115200). И тут настает время задуматься над тем, каким именно образом мы будем слать на него файл. Далеко не всё ПО умеет слать файлы в COM-сессию. Putty, например, такого не делает. Для этого придется найти старенький, но так необходимый HyperTerminal (последний раз он входил в комплект Windows XP). В нем создаем новое подключение, выбираем параметры 115200, 8, None, 1, None (см. скриншот).

Далее жмем «ОК» и подключаемся. Выходим на один уровень выше (пункт 0). И выбираем пункт 2 — Update Main Application File. Коммутатор переходит в режим приема файла, а мы нажимаем «Transfer»->»Send File», выбираем в окошке прошивку коммутатора и протокол Xmodem:

Отдыхаем минут 40 и по окончанию передачи на запрос коммутатора выдаем имя файла. После этого выходим на основной уровень меню, File Control (4), Display All Files (1). Проверяем, чтобы напротив нашего файла прошивки стоял флаг М.

После этого выходим в главное меню и загружаемся (1). Если флэшка умерла не совсем — коммутатор загрузится и будет работать еще долго.

Загрузка cisco 4000 в ROMMON.

В процессе различных экспериментов с версиями прошивок cisco ISR 4000 может возникнуть ситуация, когда девайс перестает реагировать на ваши действия (в т.ч. в консоли). Т.е. он вполне себе отображает процесс загрузки, на него можно даже по ssh зайти… Правда, после входа по ssh не появляется стандартного приглашения командной строки. Что делать и как жить дальше?

Все довольно просто. Надо подключиться консольным кабелем к циске, выключить ее секунд на 30, открыть com-порт, например, в PuTTY, включить девайс. После появления первых строк текста в консоли — надо нажать Break и дождаться прерывания процесса загрузки с появлением приглашения ROMMON. Выглядит это примерно так:

Initializing Hardware ...

System integrity status: 00000610
Rom image verified correctly


System Bootstrap, Version 15.4(3r)S5, RELEASE SOFTWARE
Copyright (c) 1994-2015 by cisco Systems, Inc.

Current image running: Boot ROM0

Last reset cause: PowerOn
Cisco ISR4331/K9 platform with 4194304 Kbytes of main memory


no valid BOOT image found
Final autoboot attempt from default boot device...
Warning: filesystem is not clean
Warning: filesystem is not clean
File size is 0x1bcc9bfc


monitor: command "boot" aborted due to user interrupt


rommon 1 >

Если нажатие кнопки Break не помогает, можете воспользоваться соответствующей командой из меню PuTTY (Special command -> Break)

После появления приглашения можно выполнить команду dir bootflash: для просмотра файлов прошивок на флэшке и загрузить нужный образ (тот, с которым все было хорошо) командами:

BOOT=bootflash:isr4300-universalk9_npe.03.16.02.S.155-3.S2-ext.SPA.bin

sync

confreg 0x2102

reset

В этом случае, isr4300-universalk9_npe.03.16.02.S.155-3.S2-ext.SPA.bin — это файл образа в памяти устройства.

Если при попытке просмотра файлов командой dir bootflash: у вас появляется сообщение «Please reset before continuing», то простой reset вам не поможет. Необходимо выполнить следующее:

confreg 0x0

reset

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

Объединение двух сетей с одинаковой адресацией через интернет

Объединить две сети через интернет довольно легко. Создаем site-to-site vpn удобным нам способом и пользуемся. А если надо объединить две сети, в которых совпадают диапазоны используемых адресов? Например, две сети с адресацией 192.168.0.0/24. Поначалу может показаться, что идея глупая и это никому не надо. Но есть для этого и практическое применение — обеспечение бесперебойной работы инфраструктуры офиса на время переезда в другое место.

Одним из первых требований, естественно, будет отсутствие совпадающих IP-адресов — в итоге получится одна виртуальная сеть, в которой никто и догадываться не будет, что она разнесена физически на далекие расстояния. Единственным признаком будет увеличение задержек при доступе к «удаленной» части. Впрочем, это требование при сценарии переезда выполнить легко: одинаковых адресов в сети не было и в процессе переезда им неоткуда взяться.

Второе требование — достаточно широкий интернет-канал с низкими задержками. Желательно все это выполнить в пределах одного интернет-провайдера.

И, естественно, третьим требованием будет 2 сервера/компьютера с двумя нормальными сетевыми картами в каждом.

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

После установки debian, ставим пакеты bridge-utils и tinc. Создаем директории /etc/tinc/mynetwork и /etc/tinc/mynetwork/hosts, где mynetwork — имя вашего соединения. В директории /etc/tinc/mynetwork создаем конфигурационный файл tinc.conf и вписываем туда следующие параметры:

Name = segment1
Mode = switch
ConnectTo = segment2

На втором, соответственно:

Name = segment2
Mode = switch
ConnectTo = segment1

В таком режиме, как можно догадаться, tinc будет работать как обычный свитч: пересылаться будут только те пакеты, которые направлены к хостам в другом сегменте. Для этого tinc будет регулярно рассылать ARP-запросы и поддерживать в актуальном состоянии таблицу MAC-адресов. Если же нужна пересылка абсолютно всего трафика — можно воспользоваться режимом «hub», что собственно и соответствует логике работы обычного хаба.

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

tincd -n mynetwork -K

Эта команда генерирует private key и public key и сохраняет их в указанном месте (по умолчанию, в директории /etc/tinc/mynetwork хранится private key, а в директории /etc/tinc/mynetwork/hosts — public key. Имя публичного ключа совпадает с именем, заданным в tinc.conf параметром Name. Редактируем файл с публичным ключом и вписываем в первой строке (до начала —— BEGIN RSA PUBLIC KEY):

Address = 1.2.3.4

, где 1.2.3.4 — внешний адрес этого хоста. После этого копируем файлы из директории /etc/tinc/mynetwork/hosts с одного хоста на другой.

В директории /etc/tinc/mynetwork создаем скрипт tinc-up с содержимым:

#!/bin/sh

ifconfig $INTERFACE 0.0.0.0
brctl addif bridge $INTERFACE
ifconfig $INTERFACE up

Этот скрипт будет запускаться при старте демона tincd. Для автоматической установки соединения при старте системы, необходимо вписать имя сети (mynetwork) в файл /etc/tinc/nets.boot.

И, наконец, последнее, что необходимо сделать для того, чтобы все работало — создать, собственно, мост и сделать так, чтобы при старте системы он создавался автоматически. Для этого создаем скрипт /etc/tinc/createbridge со следующим содержимым:

#!/bin/sh

brctl addbr bridge
ifconfig bridge 192.168.0.2 netmask 255.255.255.0
ifconfig eth1 0.0.0.0
brctl addif bridge eth1
ifconfig eth1 up

, где 192.168.0.2 — адрес хоста в сети, а eth1 — интерфейс, к которому подключена локальная сеть. Делаем скрипт исполняемым и добавляем в /etc/network/interfaces в параметры интерфейса eth1 строку:

post-up /etc/tinc/createbridge

Перезагружаем оба сервера и проверяем наличие соединения между хостами. Если соединение не установлено — смотрим логи и проверяем наличие интернета. Если не помогло — читаем мануал :)

Организация DMZ-подсети на cisco ASA 5510 или как мы переходили на Cisco ASA — часть 4

Приоритезацию трафика для voip и skype сделали, наступил следующий этап подготовки к переходу — организация DMZ-подсети. Сама по себе организация DMZ-подсети ничего сложного из себя не представляет: отдельный порт для отдельной физической сети с отдельной адресацией. Естественно, доступа из подсети DMZ в основную подсеть быть не должно, доступ же из основной сети в подсеть DMZ должен быть без ограничений. Еще несколько условий для нашей реализации DMZ:

  1. Не все сервера из DMZ могут свободно ходить в интернет;
  2. Некоторые сервера могут ходить только по определенным адресам;
  3. Некоторые сервера должны иметь полный доступ в интернет;
  4. Скорость доступа в интернет для всех серверов должна быть ограничена;
  5. К некоторым сервисам в локальной сети все же должен быть доступ из DMZ;

Собственно, начнем с начала :) То есть с конфигурирования интерфейса:

interface Ethernet0/1
 nameif DMZ
 security-level 99
 ip address 192.168.15.1 255.255.255.0
 no shutdown

Security-level 99 как раз и отвечает за то, чтобы клиенты из DMZ, по умолчанию, не могли достучаться до локальной сети (она у нас имеет security-level 100). Клиенты из локальной сети, при такой настройке, будут иметь доступ к ресурсам DMZ.

Интерфейс сконфигурирован, пора прописывать правила доступа. Для облегчения восприятия, назовем access-list FROMDMZ — очевидно, что действовать он будет на пакеты исходящие из сети DMZ. Несмотря на запрет доступа из сети с меньшим security-level в сеть с бОльшим, лучше после разрешений доступа в локальную сеть к определенным сервисам, указать явный запрет на весь трафик из DMZ в локальную сеть.

Напомню, что Cisco ASA обрабатывает списки доступа (access-list) до первого совпадения. Таким образом, разрешение в начале списка подействует раньше, чем запрет на весь трафик в конце списка.

Итак, разрешим доступ всей подсети DMZ к почтовым серверам и DNS-серверам во всей локальной сети:

access-list FROMDMZ extended permit tcp 192.168.15.0 255.255.255.0 192.168.0.0 255.255.248.0 eq smtp
access-list FROMDMZ extended permit udp 192.168.15.0 255.255.255.0 192.168.0.0 255.255.248.0 eq domain

Далее запретим весь остальной трафик из DMZ в локальную сеть:

access-list FROMDMZ extended deny ip 192.168.25.0 255.255.255.0 192.168.8.0 255.255.248.0

Разрешим доступ к внешним DNS-серверам:

access-list FROMDMZ extended permit udp any host 8.8.8.8 eq domain
access-list FROMDMZ extended permit udp any host 8.8.4.4 eq domain

Создадим object-group для серверов, которым необходим доступ в интернет без ограничений по адресам:

object-group network DMZ-TO-INTERNET
 network-object host 192.168.15.3
 network-object host 192.168.15.5
 network-object host 192.168.15.8

Чаще всего для разрешения доступа к чему-либо более чем для одного клиента удобнее использовать object-group. В списках доступа важен порядок следования правил и правило с конкретным object-group будет всегда на одном и том же месте. Добавление же новых правил в конкретное место — более сложная операция.

Разрешим им доступ:

access-list FROMDMZ extended permit tcp object-group DMZ-TO-INTERNET any
 access-list FROMDMZ extended permit udp object-group DMZ-TO-INTERNET any

Далее можно разрешать доступ к конкретным внешним IP-адресам и в конце добавить запрет для остального трафика.

access-list FROMDMZ extended permit ip host 192.168.15.23 host 1.2.3.4
 access-list FROMDMZ extended deny ip any any

Учитывая то, что на нашей Cisco ASA настроен костыль, похожий на PBR (см. часть 1), нам придется заставить железяку выбирать интерфейс для трафика из локальной сети в DMZ, иначе весь трафик, адресованный на порты 80, 443, 8080 и др. будет уходить не на тот интерфейс. Для этого достаточно добавить правило:

static (DMZ,LOCAL) 192.168.15.0 192.168.15.0 netmask 255.255.255.0

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

no static (DMZ,LOCAL) 192.168.15.0 192.168.15.0 netmask 255.255.255.0
static (DMZ,LOCAL) 192.168.15.0 192.168.15.0 netmask 255.255.255.0

Костыль, но с этим надо как-то жить… На этой позитивной ноте, переходим к ограничению скорости. Создадим object-group и access-list:

object-group network DMZ-LIMIT
network-object host 192.168.15.3
network-object host 192.168.15.5
network-object host 192.168.15.9
access-list DMZ-LIMIT extended deny ip object-group DMZ-LIMIT 192.168.0.0 255.255.248.0
access-list DMZ-LIMIT extended deny ip  192.168.0.0 255.255.248.0 object-group DMZ-LIMIT
access-list DMZ-LIMIT extended permit ip object-group DMZ-LIMIT any
access-list DMZ-LIMIT extended permit ip any  object-group DMZ-LIMIT

Певые две строчки access-list нужны для исключения трафика в локальную сеть и из нее из будущего ограничения скорости: нам надо ограничивать только скорость доступа в интернет

Создаем class-map и policy-map.

class-map DMZ-LIMIT
 match access-list DMZ-LIMIT
policy-map DMZ-LIMIT
 class DMZ-LIMIT
  police output 4000000 10000

И, наконец, применим все к интерфейсу.

access-group FROMDMZ in interface DMZ
service-policy DMZ-LIMIT interface DMZ