По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
В данной статье мы опишем настройки сети, которые могут очень пригодится для малых и средних сетей. Мы настроим на Cisco ASA DHCP сервер с несколькими внутренними локальными сетями. У нас есть три разных внутренних локальных сети с ПК пользователей и другой инфраструктурой – серверами, принтерами и так далее. Нашей задачей является разделение этих сетей с помощью использования Cisco ASA (данная задача решается как на старых моделях 5500, так и на новых 5500-X). Три внутренних локальных сети будут подключены к одному коммутатору второго уровня с тремя VLAN-ами на данном коммутаторе ASA будет предоставлять доступ к интернету для всех внутренний ЛВС. Кроме того, ASA также будет выполнять функции DHCP сервера для каждой из ЛВС, назначая нужные IP – адреса для каждой из сетей, используя разные DHCP пулы. Кроме того, мы будем использовать один физический интерфейс на ASA для размещения внутренних зон безопасности (“inside1”,“inside2”,“inside3”). Для этого нам необходимо настроить саб-интерфейсы на физическом интерфейсе нашего МСЭ, который подключен к транковому порту коммутатора. Каждый саб-интерфейс будет служить шлюзом по умолчанию для соответствующих подсетей. Касаемо настроек свитча – нам необходим один порт Dot1Q, который будет подключен к фаерволлу, и также необходимо будет настроить порты доступа для внутренних хостов. Топология изображена ниже: Убедитесь, что вы используете лицензию security-plus. Из топологии мы видим: Интерфейс GE1 на ASA – внешняя зона с адресом 100.1.1.1 будет подключен к провайдеру Интерфейс GE0 на ASA – интерфейс, подключенный к транковому порту на коммутаторе. Данный интерфейс будет разбит на три саб-интерфейса, каждый из которых принадлежит свой зоне безопасности и VLAN. Саб-интерфейс GE0.1 - VLAN10 (адрес 10.1.1.254) – зона безопасности “inside 1” Саб-интерфейс GE0.2 - VLAN10 (адрес 10.2.2.254) – зона безопасности “inside 2” Саб-интерфейс GE0.3 - VLAN10 (адрес 10.3.3.254) – зона безопасности “inside 3” Интерфейс Eth0/1, Eth0/2, Eth 0/3 на коммутаторе – настраиваются как порты доступа для соответствующих VLAN-ов (10, 20, 30) Хосты в VLAN 10 – получат адреса с ASA через DHCP (10.1.1.0/24) на интерфейсе “inside1” Хосты в VLAN 20 - получат адреса с ASA через DHCP (10.2.2.0/24) на интерфейсе “inside2” Хосты в VLAN 30 – получат адреса с ASA через DHCP (10.3.3.0/24) на интерфейсе “inside3” Все внутренние локальные сети – данные сети получат доступ к интернету через ASA с использованием PAT (NAT Overload) на внешнем интерфейсе МСЭ Важно отметить, что в данном примере настройка меж-VLAN маршрутизации проведена не была – есть только доступ в интернет. Конфигурация Cisco ASA Ниже указан конфиг для МСЭ ! Данный физический интерфейс разбиваем на три саб-интерфейса (порт подключен к транковому порту коммутатора) interface GigabitEthernet0 no nameif no security-level no ip address ! ! Это саб-интерфейс GE0.1 для VLAN10 interface GigabitEthernet0.1 vlan 10 nameif inside1 security-level 100 ip address 10.1.1.254 255.255.255.0 ! Это саб-интерфейс GE0.2 для VLAN20 interface GigabitEthernet0.2 vlan 20 nameif inside2 security-level 90 ip address 10.2.2.254 255.255.255.0 ! Это саб-интерфейс GE0.3 для VLAN30 interface GigabitEthernet0.3 vlan 30 nameif inside3 security-level 80 ip address 10.3.3.254 255.255.255.0 ! This is the WAN interface connected to ISP Это WAN интерфейс, подключенный к ISP interface GigabitEthernet1 nameif outside security-level 0 ip address 100.1.1.1 255.255.255.0 ! Настраиваем сетевые объекты для трех ЛВС object network inside1_LAN subnet 10.1.1.0 255.255.255.0 object network inside2_LAN subnet 10.2.2.0 255.255.255.0 object network inside3_LAN subnet 10.3.3.0 255.255.255.0 ! Данный ACL полезен тем, что разрешает ходить ICMP трафику (пинг и так далее) access-list OUT extended permit icmp any any access-group OUT in interface outside ! Разрешаем доступ в Интернет – для этого настраиваем PAT (NAT Overload) на внешнем интерфейсе object network inside1_LAN nat (inside1,outside) dynamic interface object network inside2_LAN nat (inside2,outside) dynamic interface object network inside3_LAN nat (inside3,outside) dynamic interface access-group OUT in interface outside route outside 0.0.0.0 0.0.0.0 100.1.1.2 ! Создаем три разных DHCP cущности ! DHCP сущность для VLAN10 – “inside1” dhcpd address 10.1.1.1-10.1.1.100 inside1 dhcpd enable inside1 ! DHCP сущность для VLAN20 – “inside2” dhcpd address 10.2.2.1-10.2.2.100 inside2 dhcpd enable inside2 ! DHCP сущность для VLAN30 – “inside3” dhcpd address 10.3.3.1-10.3.3.100 inside3 dhcpd enable inside3 ! Назначаем DNS cервер для внутренних хостов dhcpd dns 200.1.1.1 На этом все, переходим к настройке свитча. Настройка коммутатора Настройка коммутатора очень проста – необходимо настроить транковый порт и три порта доступа, с указанием VLAN. ! Транковый порт, который подключается к GE0 interface Ethernet0/0 switchport trunk encapsulation dot1q switchport mode trunk duplex auto ! Порт доступа для VLAN10 interface Ethernet0/1 switchport access vlan 10 switchport mode access duplex auto ! Порт доступа для VLAN20 interface Ethernet0/2 switchport access vlan 20 switchport mode access duplex auto ! Порт доступа для VLAN30 interface Ethernet0/3 switchport access vlan 30 switchport mode access duplex auto
img
Часто бывает, что на системе Linux произошла незапланированная или по неизвестным очевидным причинам, перезагрузка. Поиск и устранение первопричины может помочь предотвратить повторение таких проблем и избежать незапланированных простоев. Есть несколько способов выяснить, что вызвало перезагрузку. В этой статье мы обсудим эти способы и способы использования доступных утилит и журналов в системе Linux для устранения таких сценариев. Проверка времени перезагрузки Чтобы посмотреть, когда именно произошла перезагрузка системы можно воспользоваться командами who и last Проверка системных журналов Кроме того, можно сопоставить время перезагрузки, которую требуется диагностировать, с системными сообщениями. Для систем CentOS/RHEL журналы можно найти по адресу /var/log/messages, а для систем Ubuntu/Debian - по адресу /var/log/syslog. Для фильтрации или поиска конкретных данных можно использовать команду tail или любимый текстовый редактор. Как видно из приведенных ниже журналов, такие записи предполагают завершение работы или перезагрузку, инициированную администратором или пользователем root. Эти сообщения могут варьироваться в зависимости от типа ОС и способа запуска перезагрузки или завершения работы, но вы всегда найдете полезную информацию, просматривая системные журналы, хотя этого не всегда может быть достаточно, чтобы определить причину. Ниже приведена одна такая команда, которую можно использовать для фильтрации системных журналов: sudo grep -iv ': starting|kernel: .*: Power Button|watching system buttons|Stopped Cleaning Up|Started Crash recovery kernel' /var/log/messages /var/log/syslog /var/log/apcupsd* | grep -iw 'recover[a-z]*|power[a-z]*|shut[a-z ]*down|rsyslogd|ups' Зафиксированные события не всегда могут быть конкретными. Всегда отслеживайте события, которые дают признаки предупреждений или ошибок, которые могут привести к выключению или сбою системы. Проверка журнала auditd Для систем, использующих auditd – это отличное место для проверки различных событий с помощью инструмента ausearch. Используйте приведенную ниже команду для проверки последних двух записей из журналов аудита. $ sudo ausearch -i -m system_boot,system_shutdown | tail -4 Появится сообщение о двух последних остановках или перезагрузках. Если это сообщает о SYSTEM_SHUTDOWN, за которым следует SYSTEM_BOOT, все должно быть хорошо. Но, если он сообщает две строки SYSTEM_BOOT подряд или только одно сообщение SYSTEM_BOOT, то, скорее всего, система некорректно завершила работу. Вывод при нормальной работе должен быть примерно следующим: $ sudo ausearch -i -m system_boot,system_shutdown | tail -4 ---- type=SYSTEM_SHUTDOWN msg=audit(Saturday 13 February 2021 A.852:8) : pid=621 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success' ---- type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.368:8) : pid=622 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success' В приведенных ниже выходных данных перечислены два последовательных сообщения SYSTEM_BOOT, которые могут указывать на аварийное завершение работы, хотя результаты нужно скорректировать с данными системного журнала. $ sudo ausearch -i -m system_boot,system_shutdown | tail -4 ---- type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.852:8) : pid=621 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success' ---- type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.368:8) : pid=622 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success' Анализ журнала systemd Чтобы сохранить журнал системных логов на диске, необходимо иметь постоянный системный журнал, иначе логи будут очищаться при перезагрузке. Для этого можно либо внести изменения в /etc/systemd/journald.conf, либо создать каталог самостоятельно с помощью следующих команд: $ sudo mkdir /var/log/journal $ sudo systemd-tmpfiles --create --prefix /var/log/journal 2>/dev/null $ sudo systemctl -s SIGUSR1 kill systemd-journald После этого можно дополнительно перезагрузить систему для ввода нескольких записей перезагрузки в журнал, хотя это и не требуется. Приведенную ниже команда позволяет выводить список записанных событий о загрузке из журнала: $ journalctl --list-boots Вот его выходные данные на моем сервере: Как видно на рисунке, в системе есть несколько событий загрузки. Для дальнейшего анализа причины конкретной перезагрузки используйте: $ journalctl -b {num} –n Здесь {num} будет индексом, заданным в команде journalctl --list-boots в первом столбце. В приведенных выше выходных данных можно просмотреть сообщения, зарегистрированные в журнале, и отследить аномалии, если таковые имеются. Заключение Не всегда можно определить причину перезагрузки Linux с помощью одной команды или из одного файла журнала. Поэтому всегда удобно знать команды и журналы, которые фиксируют события, связанные с системой, и могут сократить время, необходимое для поиска первопричины. Приведенные выше примеры дают вам возможность начать поиск и устранение неисправностей. Используя комбинацию таких инструментов и журналов, вы можете быть уверены в том, что произошло и как перезагрузилась ваша система.
img
Одной из наиболее часто встречающихся проблем при звонке на внутренний номер (Extension), зарегистрированный IP-АТС Asterisk, является перевод звонка сразу на голосовую почту. Простой пример – клиент звонит в Вашу компанию, набирает внутренний номер сотрудника (будем считать, что он его знает), с которым хочет связаться, но вместо того, чтобы услышать ответ на другом конце, слышит предложение оставить голосовое сообщение. Если клиенты систематически не могут связаться с нужным сотрудником и попадают прямиком на Voicemail, то это повод для администратора IP-АТС проверить настройки. Обычно, перевод звонка на голосовую почту, означает что внутренний номер, с которым зарегистрирован телефон, находится в статусе DND (Do Not Disturb) или вовсе не зарегистрирован. Включен ли режим DND? Первым делом, необходимо проверить, не включен ли на телефоне пользователя, до которого не могут дозвониться, режим DND. Для этого можно использовать специальный сервисный код (feature code) , который по умолчанию имеет значение *76. Это действие поможет узнать включен ли DND или нет. Зарегистрирован ли внутренний номер на IP - PBX? Для того, чтобы проверить зарегистрирован ли телефон, необходимо перейти по следующему пути Reports → Asterisk Info, далее переходи на вкладку Peers Теперь ищем внутренний номер телефона, до которого не могут дозвониться и проверяем статус его регистрации, он должен быть в статусе OK. Если же отображается какой-либо другой статус, то необходимо проверить правильность параметров внутреннего номера как на самой IP-АТС, так и на оконечном устройстве. Отметим, что маршрутизацией звонка, в случае, если внутренний номер сотрудника не отвечает, занят или вовсе недоступен по техническим причинам Вы можете в настройках самого экстеншена. Для этого, необходимо перейти во вкладку Applications → Extensions, выбрать нужный внутренний номер для редактирования и во вкладке Advanced, в самом низу настроить опции Optional Destinations.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59