По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Введение
Добрый день, коллеги! Недавно я получил свой первый сертификат и теперь я сертифицированный специалист Cisco. Но это было маленькое лирическое отступление. Сегодня хочу рассказать о том, как сделать бэкап конфигурации сетевого оборудования. Правда, на оборудовании компании Cisco уже есть встроенная возможность архивации конфигурации. Но в этом случае придется вручную настраивать все оборудование. Если у вас сотни коммутатаров, то думаю даже копи-паст нельзя считать выходом.
В сети есть много платного ПО с очень удобным интерфейсом и под каждую ОС. Но цены на них бешеные, поэтому решили найти опенсорсный аналог. После недолгих поисков нашёл пару программ из которых выбрали rConfig. Тут решил собрать более-менее подробное руководство по установке и настройке данного ПО.
Коротко об rConfig
Как уже и было сказано, программа совершенно бесплатна, работает на CentOS 7, не очень требователен к ресурсам. Правда, на сайте разработчика не нашел информацию о минимальной конфигурации сервера, но вот то, что раскопал в сети:
Выделенный сервер (физический или виртуальный) ;
100 GB свободного места на диске;
1 GB оперативки (рекомендую 4 GB);
Процессор Intel x86_64.
Но минимальные требования к софту разработчик разместил:
Centos 7+
PHP 7+
MySQL 5.6+
Apache 2.4+
Browser IE7+, Firefox3.5+, Chrome11+, Safari3+, Opera 9.4+
Установка
Для начала нужно поднять Linux-сервер. Разработчик рекомендует CentOS с минимальной конфигурацией. Дальше подключаемся к серверу по SSH (можно использовать всем знакомый PuTTY), качаем софт с сайта разработчика, файл установки делаем исполняемым и запускаем его:
cd /home
curl -O http://files.rconfig.com/downloads/scripts/install_rConfig.sh
chmod +x install_rConfig.sh
./install_rConfig.sh
Установка длится около 20-30 минут, нужно ответить на пару вопросов типа настройки NTP, root пароля для MySQL и т.п. Проследить ход установки можно открыв вторую сессию и введя команду
tail -f /home/install.log
После установки требуется перезагрузить сервер. После перезагрузки нужно ввести команду:
/home/centos7_postReboot.sh
Настройка rConfig
После завершения установки (система оповестит об этом) можно переходить непосредственно к самой настройке rConfig. Для начала создаём пользователя базы данных, базу данных и привязываем пользователя к БД:
mysql -u root –p
Enter new password:
mysql> GRANT ALL ON *.* TO 'username'@'localhost' IDENTIFIED BY 'password';
mysql> FLUSH PRIVILEGES;
mysql> CREATE DATABASE rconfig_db;
После этого в браузере открываем веб интерфейс:
https://yourhostname/install
Здесь проверяется соответствие необходимого программного обеспечения требованиям rConfig. Далее принимаем лицензионное соглашение, которое, как правило, никто не читает, и переходим к настройке базы данных:
Кнопкой Check Settings проверяется правильность имени БД, логина и пароля. Затем нажимаем Install Settings. После этого в фоновом режиме запускается скрипт, которые заполняет БД необходимыми данными. У меня в первый раз вышла ошибка, мол данная БД уже есть, но думаю это связано с тем, что я не дождался выполнения команды и несколько раз кликнул по кнопке. Если у вас будет также, просто нажимаем Last затем опять Next, вводим нужные данные, нажимаем на Install Settings и набираемся чуток терпения :) Далее переходим к финальной проверке:
Прежде чем перейти к странице входа в систему, удаляем каталог установки:
rm -fr /home/rconfig/www/install/
Добавление устройства
Для добавления устройства заходим на веб интерфейс системы введя доменное имя или IP адрес сервера, вводим логин и пароль, по умолчанию admin/admin. Затем переходим на вкладку Devices и нажимаем на кнопку Add device:
Вводим название устройства, выбираем категорию (можно добавлять и удалять категории в одноименной вкладке), прописываем IP адрес, можно добавить расположение оборудования, вводим имя и пароль для входа на устройство. Тут сделаю небольшое отступление.
Как правило, в крупных организациях пользуются TACACS+ или RADIUS серверами для авторизации на устройствах, которые используют Active Directory. В соотвествие со внутренней политикой пароль пользователя меняется каждый месяц, значит нам придется каждый месяц заходить и менять пароль для входа на устройство. В настройках rConfig есть интеграция с LDAP, но сам пока не настраивал его, и не знаю будет ли работать так, как нужно. Когда настрою и все заработает, постараюсь написать руководство. А пока для тестов ввёл свой username и текущий пароль. Кроме этого, можно настроить имя пользователя и пароль по умолчанию. Делается это на вкладке Settings:
А при добавлении устройства просто можно поставить галочку перед Default username/password.
В Enable Prompt и Main Prompt я просто ввел hostname устройства и поставил соответствующие символы (, #). Далее выбираем вендора (по умолчанию только Cisco, но можно отредактировать этот список на вкладке Vendors) и вписываем модель. Из выпадающего списка Template выбираем подключение по SSH: Cisco IOS - SSH - Enable - ios-ssh-enable.yml. Нажимаем Save и вуаля, если все прописано правильно, то при клике на названии устройства переходим на новую страницу и там статус устройства должен быть Online:
Дополнительные настройки
По умолчанию система выполняет на оборудовании три команды: show ip access-list, show cdp neighbors и show startup-config. Данное действие можно сократить до одной команды, для этого на вкладке Devices переходим в раздел Commands, выбираем команду и делаем Remove Command:
Просмотреть сохранённую конфигурацию можно на странице Device Management, куда можно перейти кликнув на устройство на вкладке Devices:
01 до удаления лишних, по моему мнению, команд, а 02 уже после.
Можно настроить автоматическое выполнение бэкапа, для чего, собственно, и было затеяно все это дело. Для настройки задания переходим на вкладку Scheduled Task, нажимаем на Add Scheduled Task заполняем соответствующие поля:
Выбираем Download Configuration, задаём название и описание задания. Можно настроить отправку e-mail при выполнении или при ошибке выполнения или выбрать сразу оба. Далее можно выбрать конкретное устройство, а можно выбрать всю категорию. Задаём частоту выполнения, в данном случае я выбрал раз в день. Система автоматом прописывает время выполнения в 00:00, что можно изменить. Нажимаем Save и радуемся :)
На этом пока все, думаю материал будет полезен как начинающим сетевым администраторам, так и имеющим достаточный опыт работы с сетью профессионалам. Удачи!
Зачастую можно столкнуться с задачами, когда необходимо обеспечить доступ к внутренним корпоративным (или домашним) ресурсам из Интернета. В этом случае, нужно выполнить, так называемый "проброс портов". Что это такое, зачем это нужно и как настраивать на примере роутера Mikrotik 951Ui-2HnD – расскажем в данной статье.
/p>
Как это работает?
Давайте представим себе следующую ситуацию – у нас есть корпоративная сеть, в которой пока ещё локально разворачивается сервер IP-телефонии на базе Asterisk, управляется он при помощи графической оболочки FreePBX. Задача состоит в том, чтобы предоставить возможность администратору сервера управлять им из Интернета.
Итак, имеем следующую схему:
Для начала остановимся на понятии “проброс порта”. Проброс порта – это функционал маршрутизаторов, поддерживающих NAT, который позволяет получить доступ к ресурсам локальной сети, из Интернета по средствам перенаправления трафика определенных портов с внешнего адреса маршрутизатора на внутренний адрес хоста в локальной сети.
Иными словами, мы должны настроить на роутере правило, в котором при поступлении TCP запроса на внешний адрес, в данном случае 35.135.235.15 и определенный порт, например 23535, открывался бы доступ к интерфейсу FreePBX, который в данным момент доступен только в локальной сети по адресу 192.168.1.100 и, соответственно на порту 80 (HTTP).
Настройка
Перейдём к настройке. Заходим на адрес нашего роутера Mikrotik 951Ui-2HnD, видим следующее окно:
Скачиваем приложение WinBox. Вводим учётные данные и подключаемся. По умолчанию логин - admin, пароль - пустой. Если у вас уже настроены логин и пароль, то укажите их.
Далее необходимо создать NAT – правило. Для этого переходим по следующему пути – на панели управления слева выбираем IP → Firewall → NAT
Открывается следующее окно:
Нажимаем на +, открывается страница добавления нового NAT- правила.
Задаём следующие параметры:
Chain → dstnat - направление запроса из внешней сети во внутреннюю.
Protocol → tcp, поскольку в нашем случае нужно предоставить доступ к HTTP страничке.
Dst.Port → 23535 - это тот самый порт назначения, на который будет отправлять запрос из вне на получение доступа к FreePBX.
In.Interface → all ethernet - входной интерфейс. Это интерфейс, которым роутер смотрит в Интернет и на котором он будет прослушивать указанный выше порт.
Должно получиться вот так:
На вкладках Advanced и Extra настраиваются расширенные опции, такие как лимит по битрейту, политика IPsec, время, в течение которого правило будет активно и так далее.
Переходим на вкладку Action и объясняем роутеру, какие действия он должен выполнить при поступлении запроса на указанный порт. Выбираем Action → netmap, то есть трансляция с одного адреса на другой. To Addresses → 192.168.1.100, то есть адрес нашёго FreePBX. И последнее - To Ports → 80, то есть запрос на HTTP порт.
Должно получиться так:
Далее нажимаем OK и правило готово. Теперь если вбить в адресной строке браузера сокет 35.135.235.15:23535 то мы попадем на страницу авторизации FreePBX.
На самом деле поиск DNS это не то, что требует частого внимания. Но иногда приходится заботиться об этом. Например, если у вашего провайдера слабые сервера или же в вашей сети часто происходят DNS обращения, то нужно настроить локальный кэширующий DNS сервер.
Как кэширующий DNS-сервер может пригодиться?
Кэширующий DNS-сервер занимается обработкой DNS запросов, которые выполняет ваша система, затем сохраняет результаты в памяти или кэширует их. В следующий раз, когда система посылает DNS запрос для того же адреса, то локальный сервер почти мгновенно выдает результат.
Эта идея может показаться бесполезной. Подумаешь, какие-то там секунды. Но если DNS сервера провайдера тратят много времени на разрешение имени, то в результате падает скорость Интернет серфинга. Например, домашняя страница новостного канала MSNBC для корректной работы обращается более чем к 100 уникальным доменам. Даже если на запрос тратится одна десятая секунды, в итоге получается 10 секунд ожидания, что по нынешним меркам слишком много.
Локальный кэширующий DNS увеличивает скорость не только дома или в офисе, он также помогает работе серверов. Например, у вас есть почтовый сервер с анти-спам фильтром, который выполняет очень много DNS запросов. Локальный кэш намного увеличить скорость его работы.
И наконец, system-resolved поддерживает новейшие стандарты вроде DNSSEC и DNSoverTLS или DoT. Эти технологии увеличивают безопасность при работе в Интренет.
Какой локальный кэширующий сервер выбрать?
В этом руководстве будет использован сервер systemd-resolved. Эта утилита является частью набора управления системой systemd. Если в вашей системе используется systemd, а большинство дистрибутивов Linux используют это, то в системе уже установлен systemd-resolved, но не запущен. Большинство систем не используют эту утилиту.
systemd-resolved запускает небольшой локальный кэширующий DNS-сервер, который мы настроим на запуск при загрузке системы. Затем мы изменим конфигурацию всей системы так, чтобы DNS запросы шли на локальный сервер.
Как проверить используется ли systemd-resolved?
В некоторых дистрибутивах, например Ubuntu 19.04, по умолчанию используется systemd-resolved.
Если у вас уже запущен systemd-resolved, тогда не нужно что-то настраивать в системе. Но нужно проверить на корректность утилит управления сетевыми настройками, такие как NetworkManager, так как они могут игнорировать системные настройки сети.
Перед тем как перейти к следующему разделу проверьте запущен ли в вашей системе systemd-resolved:
$ resolvectl status
Если в ответ получите сообщение ниже, значит в системе не настроен systemd-resolved:
$ resolvectl status
Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.
И наоборот, если на выходе видите что-то подобное, то systemd-resolved уже работает:
Global
LLMNR setting: yes
MulticastDNS setting: yes
DNSOverTLS setting: opportunistic
DNSSEC setting: allow-downgrade
DNSSEC supported: no
Current DNS Server: 1.1.1.1
DNS Servers: 1.1.1.1
1.0.0.1
Включение и настройка systemd-resolved
Отдельно устанавливать systemd-resolved не нужно, так как этот сервис является частью systemd. Всё что нужно сделать это запустить его и добавить в автозагрузку. Для включения данной службы введите команду ниже:
$ sudo systemctl start systemd-resolved.service
Далее нужно ввести следующую команду, чтобы добавить службу в автозапуск.
$ sudo systemctl enable systemd-resolved.service
И наконец нужно прописать DNS сервера, куда будет обращаться локальный сервер для разрешения имен. Есть много разных сервисов, но приведённые ниже самые быстрые, бесплатные и оба поддерживают DNSSEC и DoT:
Google Public DNS
8.8.8.8
8.8.4.4
Cloudflare Public DNS
1.1.1.1
1.0.0.1
Для этого откройте конфигурационный файл systemd-resolved любым текстовым редактором:
$ sudo nano /etc/systemd/resolved.conf
Отредактируйте строку, которая начинается на:
#DNS=
И пропишите одну из вышеуказанных пар. Мы используем Cloudflare Public DNS:
DNS=1.1.1.1 1.0.0.1
Сохраните изменения и перезапустите службу systemd-resolved:
$ sudo systemctl restart systemd-resolved.service
Итак, systemd-resolved уже запущен и готов для выполнения быстрых и безопасных DNS запросов, как только мы настроим систему соответствующим образом.
Настройка системы для использования systemd-resolved
Есть несколько путей настройки системы на использование локального DNS сервера. Мы рассмотрим два наиболее используемых метода. Первый – рекомендуемый метод, второй конфигурация в режиме совместимости. Разница в том, как будет обрабатываться файл /etc/resolv.conf.
В файле /etc/resolv.conf содержатся IP адреса серверов разрешения имен, которые используются программами. Программы при необходимости разрешения доменного имени обращаются к этому файлу в поисках адресов серверов разрешения имен.
Итак, первый метод конфигурации заключается в создании символьной ссылки на /run/systemd/resolve/stub-resolv.conf. В этом случае файл /etc/resolv.conf управляется службой systemd-resolved.
Это может вызвать проблемы в том случае, если другие программы пытаются управлять файлом /etc/resolv.conf. Режим совместимости оставляет /etc/resolv.conf не тронутым, позволяя программам управлять им. В этом режиме, в настройках программ, управляющих файлом /etc/resolv.conf в качестве системного сервера разрешения имен должен быть указан IP 127.0.0.53.
Конфигурация в рекомендуемом режиме
При этом режиме конфигурация проводится вручную. Сначала нужно удалить или переименоваться оригинальный файл /etc/resolv.conf. Лучше переименовать, чтобы при необходимости можно было использовать информацию в нем.
$ sudo mv /etc/resolv.conf /etc/resolv.conf.original
Затем создаем символьную ссылку:
$ sudo ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
И наконец перезапускаем службу systemd-resolved:
$ sudo systemctl restart systemd-resolved.service
Настройка в режиме совместимости
В режиме совместимости, нужно убедиться, что локальный сервер разрешения имен system-resolved запущен и используется системными службами. Откройте файл /etc/resolv.conf любым редактором:
$ sudo nano /etc/resolv.conf
Удалите все строки, которые содержать ключевое слово nameserver и добавьте одну единственную строку:
nameserver 127.0.0.53
Этот файл мажет быть изменён любой программой. Чтобы предотвратить это нужно настроить программы так, чтобы в качестве DNS они использовали адрес 127.0.0.53.
Отладка systemd-resolved
Посмотреть, как система выполняет DNS запросы после внесённых изменений сложно. Самый эффективный метод – это включить режим отладки для службы systemd-resolved, а затем просмотреть файл логов.
systemd-resolved можно перевести в режим отладки созданием специального служебного файла, в котором содержатся настройки отладки. Делается это следующей командой:
$ sudo systemctl edit systemd-resolved.service
Вставьте в файл следующие строки:
[Service]
Environment=SYSTEMD_LOG_LEVEL=debug
После этого служба systemd-resolved автоматический перезапуститься. Откройте второй терминал и просмотрите логи в journald:
$ sudo journalctl -f -u systemd-resolved
Строка, которая содержит слова “Using DNS server” показывает, какой DNS сервер используется для разрешения имён. В нашем случае это DNS сервера Cloudflare
Using DNS server 1.1.1.1 for transaction 19995.
Слова “Cache miss” в начале строки означает, что для данного домена нет закэшированной информации:
Cache miss for example.com IN SOA
И наконец слова “Positive cache” в начале строки означает, что systemd-resolved уже запрашивал информацию об этом домене и теперь ответы возвращает из кэша:
Positive cache hit for example.com IN A
Не забудьте отключить режим отладки, так как в это время создается большой файл логов. Сделать это можно командой:
$ sudo systemctl edit systemd-resolved.service
а затем удалить добавленные выше две строки.
Использование защищенных DNS запросов
systemd-resolved один из немногих DNS серверов, которые поддерживает DNSSEC и DNSoverTLS. Эта два механизма позволяют убедиться, что полученная DNS информация подлинная (DNSSEC) и он не был изменён по пути (DoT).
Эти функции легко включаются редактированием основного конфигурационного файла system-resolved:
$ sudo nano /etc/systemd/resolved.conf
Измените файл следующим образом:
DNSSEC=allow-downgrade
DNSOverTLS=opportunistic
Сохраните изменения и перезапустите службу systemd-resolved.
$ sudo systemctl restart systemd-resolved.service
Пока прописанные DNS сервера поддерживают эти две функции все DNS запросы будут защищены. DNS сервера Google и CloudFlare поддерживают эти механизмы защиты.
Заключение
Теперь ваша система будет выполнять DNS запросы быстро и эффективно даже если провайдер не работает достаточно быстро. Кроме этого, ваша цифровая жизнь лучше защищена новейшими механизмами защиты DNS запросов.