По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Введение Добрый день, коллеги! Недавно я получил свой первый сертификат и теперь я сертифицированный специалист 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 и радуемся :) На этом пока все, думаю материал будет полезен как начинающим сетевым администраторам, так и имеющим достаточный опыт работы с сетью профессионалам. Удачи!
img
Зачастую можно столкнуться с задачами, когда необходимо обеспечить доступ к внутренним корпоративным (или домашним) ресурсам из Интернета. В этом случае, нужно выполнить, так называемый "проброс портов". Что это такое, зачем это нужно и как настраивать на примере роутера 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.
img
На самом деле поиск 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 запросов.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59