По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Сегодня, в этой статье, вы узнаете, как формируются соседства BGP внутри автономной системы, между автономными системами и даже между маршрутизаторами, которые не связаны напрямую. Кроме того, мы рассмотрим аутентификацию BGP.
Предыдущие статьи цикла про BGP:
Основы протокола BGP
Построение маршрута протоколом BGP
Видео: Основы BGP за 7 минут
BGP-пиринг
Учитывая, что BGP является протоколом маршрутизации AS-to-AS, вполне логично, что внешний BGP (т.е. eBGP) является ключевым компонентом в его операциях. Самое первое, что нам нужно учитывать при работе с eBGP, - это то, что стандарты построены таким образом, что требуется прямое подключение. Это требование конечно можно обойти, но этот момент необходимо рассмотреть. Поскольку предполагается прямое соединение, протокол BGP выполняет две вещи:
Он будет проверять значение времени жизни (TTL), и что значение time-to-live установлено в 1. Это означает прямую связь между одноранговыми узлами EBGP.
Осуществляется проверка, что два устройства находятся в одной подсети.
Еще один важный момент рассмотрения пирингов eBGP - это TCP-порты, которые будут использоваться. Это особенно важно для конфигураций брандмауэров, которые защищают автономные системы. Первый спикер BGP, который инициирует изменения состояния, приходящие по мере формирования соседства, будет получать трафик из случайного TCP-порта, а конечным портом будет TCP-порт 179. Отвечающий спикер BGP будет получать трафик с TCP-порта 179, а порт назначения будет случайным портом. Брандмауэры должны быть перенастроены с учетом изменений в коммуникации. На основе этих изменений спикер BGP инициирует сеанс, и это, вносит изменения для будущего сеанса. Некоторые администраторы даже создают механизмы для обеспечения того, чтобы сформированные пиринги были получены из известного направления.
А как насчет IPv6? Ну, как было сказано ранее в предыдущей статье, BGP очень гибок и работает с IPv6, поскольку протокол был изначально спроектирован с учетом IPv6. Вы можете формировать пиринги eBGP (и iBGP) с использованием IPv6- адресации, даже если вы используются префиксы IPv4 для информации о достижимости сетевого уровня.
Чтобы сформировать в нашей сети пиринг eBGP, необходимо выполнить следующие действия:
Запустите процесс маршрутизации для BGP и укажите локальный AS (router bgp local_as_number).
Предоставить удаленному спикеру eBGP IP- адрес и удаленному AS номер (neighbor ip-_of_neighbor remote-as remote_as_number).
Пример 1 демонстрирует конфигурацию и проверку EBGP пиринга между маршрутизаторами TPA1 и ATL.
Пример 1: Настройка пиринга eBGP
ATL#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ATL(config)#router bgp 220
ATL(config-router)#neighbor 30.30.30.1 remote-as 110
ATL(config-router)#end
ATL#
TPAl#conf t
Enter configuration commands, one per line. End with CNTL/Z.
TPA1(config)router bgp 110
TPA1(config-router)#neighbor 30.30.30.2 remote-as 220
TPA1(config-router)#end
TPA1#
TPAl#show ip bgp summary
BGP router identifier 30.30.30.1, local AS number 110
BGP table version is 4, main routing table version 4
1 network entries using 120 bytes of memory
1 path entries using 52 bytes of memory
1/1 BGP path/bestpath attribute entries using 124 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 320 total bytes of memory
BGP activity 2/1 prefixes, 2/1 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
30.30.30.2 4 220 413 414 4 0 0 06:12:46 1
TPA1#
Примечание: чтобы облегчить понимание BGP, вы можете включить функцию debug ip bgp, при настройке пиринга. Это позволит увидеть переходные состояния в соседстве. Кроме того, чтобы получить больше информации о соседствах, вы можете использовать команду show ip bgp neighbors.
Создание eBGP пиринга, на основе IPv6, выполняется также очень просто, как и на основе IPv4. Единственное изменение заключается в том, что мы заменяем адресацию в IPv4 на IPv6 и активируем соседство. Семейства адресов в маршрутизаторах Cisco для BGP позволяют запускать множество различных схем информирования о достижимости сетевого уровня (NLRI) в рамках одного и того же общего процесса BGP. Пример 2 демонстрирует подход к пирингу IPv6.
Пример 2: конфигурация пиринга EBGP с использованием IPv6
ATL#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ATL(config)#router bgp 220
ATL(config-router)#neighbor 2201:1212:1212::2 remote-as 110
ATL(config-router-af)#neighbor 2201:1212:1212::2 activate
ATL(config-router-af)#end
ATL#
iBGP-пиринг
Если вы внимательно посмотрите на топологию, вы можете заметить, что что-то выглядит необычно. Видно, что есть iBGP-пиринг. Почему существует пиринг iBGP, созданный между TPA1 и TPA2? Это выглядит совершенно неуместно. В данном случае, как говорится, внешность может быть обманчива. Главное, что вы должны усвоить относительно BGP, является тот факт, что существует нечто, называемое правилом разделения горизонта (Split Horizon Rule) iBGP. Это правило гласит, что ни один спикер iBGP не может принять обновление и затем отправить это же обновление другому узлу iBGP. Так же в требовании говориться, о полном объединении наших спикеров iBGP для обеспечения полной осведомленности о префиксах.
Еще одним важным аспектом, связанным с iBGP, является избыточность. Мы хотим установить несколько физических связей между устройствами, но что произойдет, если связь, используемая для BGP, прервется? Как мы автоматически переключимся к пирингу, используя альтернативное подключение?
Простой способ решить эту проблему заключается в реализации loopback-адресов и использовании этих адресов для однорангового соединения. Это то, что мы часто делаем с нашими пирингами BGP, и это может потребовать, дополнительной настройки при использовании подключения к провайдеру. Например, в Cisco мы должны специально указать, что источником пиринга является loopback IP- адрес.
Примечание: еще одним важным аспектом при пиринге между петлевыми адресами в iBGP является то, что loopback-адреса фактически доступны между спикерами BGP. Именно здесь очень удобно использовать протокол внутреннего шлюза (IGP), такой как OSPF или EIGRP.
Пример 3 показывает конфигурацию пиринга iBGP между устройствами TPA и TPA1. Обратите внимание, что мы используем петлевой подход в том случае, если мы хотим добавить избыточные связи между устройствами в будущем.
Пример 3: Настройка пиринга iBGP
TPA#conf t
Enter configuration commands, one per line. End with CNTL/Z.
TPA(config)router bgp 110
TPA(config-router)#neighbor 8.8.8.8 remote-as 110
TPA(config-router)#neighbor 8.8.8.8 update-source loopbackO
TPA(config-router)#end
TPA#
TPAl#conf t
Enter configuration commands, one per line. End with CNTL/Z.
TPA1(config)#router bgp 110
TPA1(config-router)#neighbor 5.5.5.5 remote-as 110
TPA1(config-router)#neighbor 5.5.5.5 update-source loopbackO
TPA1(config-router)#end
TPA1#
eBGP Multihop
В разделе eBGP-пиринг этой статьи, обсуждалось, что ваши соседи будут связаны напрямую. В разделе iBGP мы обсуждали преимущество пиринга между loopback для избыточности. Теперь пришло время ответить на вопрос: Что делать, если ваши спикеры eBGP не подключены напрямую? На самом деле, если мы хотим пиринговать между loopback с eBGP, чтобы воспользоваться потенциальной избыточностью. Как сделать это, поскольку интерфейсы loopback не связаны напрямую друг с другом?
BGP решает эту проблему с помощью опции eBGP multihop. С помощью настройки eBGP multihop вы указываете максимальное количество допустимых прыжков. Это пропускает проверку BGP для TTL на значение равное 1, рассмотренное ранее в этой статье. Но как насчет требования прямого подключения? BGP отключает эту проверку в фоновом режиме автоматически, при использовании функции eBGP multihop. Пример 4 демонстрирует настройку eBGP multihop между TPA1 и ATL. Здесь нужен multihop, потому что мы настраиваем пиринг между loopback устройств.
Пример 4: eBGP Multihop
ATL#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ATL(config)#router bgp 220
ATL(config-router)#neighbor 8.8.8.8 remote-as 110
ATL(config-router)#neighbor 8.8.8.8 update-source loopbackO
ATL(config-router)#neighbor 8.8.8.8 ebgp-multihop 2
ATL(config-router)#end
ATL#
TPAl#conf t
Enter configuration commands, one per line. End with CNTL/Z.
TPA1(config)router bgp 110
TPA1(config-router)#neighbor 7.7.7.7 remote-as 220
TPA1(config-router)#neighbor 7.7.7.7 update-source loopbackO
TPA1(config-router)#neighbor 7.7.7.7 ebgp-multihop 2
TPA1(config-router)#end
TPA1#
BGP аутентификация
Большинство организаций сегодня добавляют аутентификацию в свои настройки BGP, чтобы защитить их от различного рода атак. По общему признанию, аутентификацию немного сложнее настроить на BGP, чем с на других протоколах маршрутизации, поскольку конфигурация — пирингов- это ручной процесс, который должен выполнен на обоих устройствах. Даже с учетом вышесказанного, аутентификация устройств (eBGP или даже iBGP) - отличная идея.
В Cisco настройка аутентификации осуществляется просто. Необходимо задать пароль (т.е. общий секрет) на каждое устройство, настроенное для пиринга. Обязательно усвойте, что этот пароль будет отображаться в открытом виде (по умолчанию) внутри вашей сети. Можно использовать команду service password-encryption для выполнения по крайней мере простого шифрования тех незашифрованных текстовых паролей, которые появляются в конфигурации маршрутизатора.
Аутентификация с шифрованием Message Digest 5 (MD5) – это результат простого задания пароля на устройствах. Пример 5 отображает аутентификацию, добавленную в конфигурации для TPA1 и ATL.
Пример 5. Настройка аутентификации для BGP-пиринга
ATL#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ATL(config)#router bgp 220
ATL(config-router)#neighbor 8.8.8.8 remote-as 110
ATL(config-router)#neighbor 8.8.8.8 update-source loopbackO
ATL(config-router)#neighbor 8.8.8.8 ebgp-multihop 2
ATL(config-router)#neighbor 8.8.8.8 password MySuperSecret121
ATL(config-router)#end
ATL#
TPAl#conf t
Enter configuration commands, one per line. End with CNTL/Z.
TPA1(config)router bgp 110
TPA1(config-router)#neighbor 7.7.7.7 remote-as 220
TPA1(config-router)#neighbor 7.7.7.7 update-source loopbackO
TPA1(config-router)#neighbor 7.7.7.7 ebgp-multihop 2
ATL(config-router)#neighbor 7.7.7.7 password MySuperSecret121
TPA1(config-router)#end
TPA1#
Пользователи очень часто встречаются с ошибкой 32788 в среде виртуализации Hyper-V. Если быть точным, то полная формулировка ошибки следующая:
The application encountered an error while attempting to change the state of %имя_виртуальной_машины%.%имя_виртуальной_машины% failed to change state. The operation cannot be performed while the object is in use with error code 32788
Выглядит это «неприятное» popup окно примерно вот так:
Ошибка появляется, когда пользователь пытается запустить виртуальную машину. Итак, погнали разбираться. Данный гайд подойдет для Hyper-V версий 2012 R2 и 2016.
Краткая матчасть
Ошибка возникает, из за того, что виртуализация это несколько более сложная штука, чем просто создание виртуальных вычислительных машин поверх физического устройства. Внутри каждой есть операционные системы, сетевые адаптеры, виртуальные коммутаторы, устройства для хранения, интерфейсы взаимодействия и другие.
Сам интерфейс Hyper-V – это лишь консоль управления. Устаревшая и неактуальная конфигурация виртуальных машин приводит к возникновению ошибок. В том числе, и ошибке 32788.
Основные причины ошибки 32788
Самые главные причины ошибки 32788, которые мы воспроизводили на опыте:
Конфликт (неточность/неактуальность) конфигурации виртуальной машины;
Изменения виртуального коммутатора (VM switch) на машине;
Исправляем ошибку 32788
Итак, чтобы исправить ошибку, нужно:
Открыть Settings (настройки) виртуальной машины. В списке виртуальных машин, нажмите правой кнопкой мыши на нужную виртуальную машину и выберите Settings;
Откройте настройки сетевого адаптера (Network Adapter Settings). А так же пробегитесь по всем пунктам меню слева (Memory, Processor, IDE Controller и так далее), на предмет обнаружения уведомления с надписью Configuration Error. В нашем примере, виртуальная машина столкнулась с проблемой того, что виртуальный коммутатор (Vswitch), к которому она подключена, более не существует (The network adapter is configured to a switch which no longer exists…)
Вот она, причина ошибки 32788 в нашей случае – устаревшие настройки виртуального коммутатора. Возможно, его кто то удалил, или изменил его имя.
В любом случае, нам нужно исправить это. Создаем новый виртуальный коммутатор (Virtual Switch) типа Internal, для внутреннего использования:
После внесение всех изменений перезагрузите (выполните рестарт) виртуальную машину.
Сразу перейду к делу. Пользователями FreePBX 14 замечен крайне серьёзный баг в утилите fail2ban.
Версия fail2ban, на которой замечен баг - 0.8.14-11 и ниже. Проверить можно командой rpm -qa | grep fail2ban:
fail2ban-fpbx-0.8.14-11.sng7.noarch
Данный баг заключается в том, что после установки чистой FreePBX Distro 14 сервис fail2ban хоть и в активном статусе, однако никаких “тюрем" (jails) он не подгружает и их количество = 0.
Проверить можно командой fail2ban-client status, если Ваш сервер подвержен багу, то Вы увидите:
[root@merionlab]# fail2ban-client status
Status
|- Number of jail: 0
`- Jail list:
Это значит, что например, максимальное число попыток ввода пароля для доступа к вэб-интерфейсу FreePBX или попыток регистрации SIP-клиента с неверным паролем - не ограничено, а IP-адрес, с которого приходят эти запросы не блокируется. Естественно, что модуль Intrusion Detection во FreePBX также не будет работать.
"Тюрьмы" или jails - это такие секции в файле /etc/fail2ban/jail.local, в которых указано, логи какого сервиса необходимо мониторить, чтобы выявлять и блокировать несанкционированные попытки доступа к этому сервису, а также такие параметры как время блокировки, максимальное число попыток и действие, которое необходимо предпринять в случае выявления.
Например, вот секция [asterisk-iptables]:
[asterisk-iptables]
enabled = true
filter = asterisk-security
action = iptables-allports[name=SIP, protocol=all]
sendmail[name=SIP, dest=none@yourpbx.com, sender=none@yourpbx.com]
logpath = /var/log/asterisk/fail2ban
maxretry = 5
bantime = 1800
В ней указано, что нужно мониторить лог /var/log/asterisk/fail2ban, искать в нём 5 попыток неуспешной регистрации (например SIP телефон пытается зарегистрироваться с неверным паролем) и банить IP-адрес на 30 минут. Ну и ещё можно отправку по email настроить о данном факте.
По умолчанию, в файле /etc/fail2ban/jail.local должно быть 7 таких секций - [apache-tcpwrapper], [recidive], [ssh-iptables], [apache-badbots], [pbx-gui], [asterisk-iptables], [vsftpd-iptables]. В каждой указан путь к логам соответствующего сервиса.
Решение
Итак, есть два решения данной проблемы. Первое – остановить сервис fail2ban командой systemctl stop fail2ban и внести следующие изменения в файл /usr/lib/systemd/system/fail2ban.service:
[Unit]
Description=Fail2Ban Service
After=httpd.service
[Service]
Type=forking
ExecStartPre=/bin/mkdir -p /var/run/fail2ban
ExecStart=/usr/bin/fail2ban-client -x start
ExecStop=/usr/bin/fail2ban-client stop
ExecReload=/usr/bin/fail2ban-client reload
PIDFile=/var/run/fail2ban/fail2ban.pid
Restart=always
[Install]
WantedBy=default.target
Затем запустить сервсис fail2ban командой systemctl start fail2ban и сделать так, чтобы сервис включался после ребута автоматически systemctl enable fail2ban.
И вторая – обновить сам fail2ban. Для этого вводим следующие команды:
yum install sangoma-devel
yum update
Проверяем версию fail2ban после обновления - rpm -qa | grep fail2ban:
fail2ban-fpbx-0.8.14-75.sng7.noarch
После данных действий, команда fail2ban-client status должна отобразить верное количество jails и fail2ban с Intrusion Detection должны вновь встать на стражу Вашего сервера:
[root@merionlab]# fail2ban-client status
Status
|- Number of jail: 7
`- Jail list: apache-tcpwrapper, recidive, ssh-iptables, apache-badbots, pbx-gui, asterisk-iptables, vsftpd-iptables
Чтобы случайно не заблокировать свой адрес и игнорировать любые неуспешные попытки доступа к серверу с адресов, находящихся в локальной сети или других доверенных адресов, внесите их или всю доверенную подсеть в секцию [DEFAULT] в поле ignoreip в том же файле /etc/fail2ban/jail.local