По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Протокол передачи файлов (File Transfer Protocol - FTP) - это сетевой протокол, используемый для передачи файлов между клиентом и сервером в компьютерной сети. Самые первые приложения FTP были созданы для командной строки еще до того, как операционные системы GUI даже стали чем-то особенным, и, хотя существует несколько клиентов FTP с графическим интерфейсом, разработчики по-прежнему создают клиенты FTP на основе CLI для пользователей, которые предпочитают использовать старый метод.
Вот список лучших FTP-клиентов на основе командной строки для Linux.
FTP
Операционные системы Linux поставляются со встроенными FTP-клиентами, к которым вы можете легко получить доступ, введя команду ftp в своем терминале.
С помощью FTP вы можете подключаться к серверам анонимно (если эта функция включена на сервере) или использовать свои учетные данные пользователя, загружать и скачивать файлы между локальным компьютером и подключенными серверами, использовать псевдонимы и так далее.
Кроме того, при использовании FTP для передачи файлов между компьютерами соединение не защищено и данные не шифруются. Для безопасной передачи данных используйте sFTP (Secure File Transfer Protocol) или SCP (Secure Copy).
LFTP
LFTP - это бесплатная утилита командной строки с открытым исходным кодом, разработанная для нескольких протоколов передачи файлов (например, sftp, fish, torrent) в Unix и аналогичных операционных системах.
Она включает в себя закладки, управление заданиями, поддержку библиотеки readline, встроенную команду зеркального отображения и поддержку параллельной передачи нескольких файлов.
lftp доступен для установки из репозиториев по умолчанию с помощью диспетчера пакетов, как показано ниже.
$ sudo apt install lftp [На Debian/Ubuntu]
$ sudo yum install lftp [На CentOs/RHEL]
$ sudo dnf install lftp [На Fedora]
NcFTP
NcFTP - это бесплатный кроссплатформенный FTP-клиент и первая в истории альтернатива стандартной FTP-программе, разработанная для упрощения использования и нескольких улучшений функций и производительности FTP.
Его функции включают в себя повторный набор номера, фоновую обработку, автоматическое возобновление загрузки, завершение имени файла, индикаторы выполнения, поддержку других утилит, таких как ncftpput и ncftpget.
NcFTP доступен для установки из репозиториев по умолчанию с помощью диспетчера пакетов.
$ sudo apt install ncftp [На Debian/Ubuntu]
$ sudo yum install ncftp [На CentOs/RHEL]
$ sudo dnf install ncftp [На Fedora]
cbftp
ctftp - это гибкий клиент FTP / FXP, который позволяет пользователям безопасно и эффективно передавать большие файлы без использования электронной почты. Обычно он работает в командной строке, но вы можете запустить его в полу-GUI, используя ncurses.
Его функции включают в себя внутренний просмотрщик, который поддерживает несколько кодировок, листинг с пропуском, удаленные команды для команд вызова UDP, таких как race, load, fxp, raw, idle и т. Д., И шифрование данных с помощью AES-256, среди прочего.
Yafc
Yafc - это FTP-клиент с открытым исходным кодом, разработанный для замены стандартной программы FTP в системах Linux с поддержкой POSIX-совместимых систем.
Он полностью бесплатен с богатым списком функций, который включает в себя рекурсивный get / put / fxp / ls / rm, организацию очередей, завершение табуляции, псевдонимы и поддержку SSH2 и прокси.
Yafc доступен для установки из репозиториев по умолчанию, используя менеджер пакетов.
$ sudo apt install yafc [На Debian/Ubuntu]
$ sudo yum install yafc [На CentOs/RHEL]
$ sudo dnf install yafc [На Fedora]
Функционал модуля CallerID Lookup Sources позволяет устанавливать некие источники для преобразования номерных идентификаторов входящих вызовов CID (caller ID) в имена. После чего, можно привязать входящий маршрут к специальному источнику CID. Таким образом, любой входящий вызов будет сперва проверен на соответствие номера и имени по заданному источнику и, если такое соответствие будет найдено, то вместо длинного номера, на экране Вашего телефона отобразится знакомое имя вызывающего абонента. Можно также создать небольшой список соответствия имен и номеров в модуле Phonebook.
/p>
Настройка модуля
Перейдём к настройке. Для того чтобы попасть в модуль CallerID Lookup Sources, с главной страницы, переходим по следующему пути: Admin -> CallerID Lookup Sources. Обратите внимание на предупреждение, которое открывается при входе в модуль. Процесс поиска имени входящего абонента (name lookup), который запускает данный модуль, может замедлить работу Вашей IP-АТС.
По умолчанию, в модуле уже есть один источник – сервис определения CallerID Name - OpenCNAM. Мы не будем подробно рассматривать данный вариант, поскольку, чтобы им воспользоваться, необходимо иметь аккаунт в OpenCNAM.
Рассмотрим, какие ещё источники предлагает данный модуль. Для этого нажмите Add CIDLookup Source, откроется окно добавления нового источника
В поле Source Description предлагается написать краткое описание нового источника.
В поле Source type выбирается тип источника. От того, какой тип будет выбран на данном этапе, будет зависеть то, где система будет искать соответствие CID входящих вызовов. Рассмотрим каждый тип:
internal - Для поиска имени используется база astdb, а для её заполнения – модуль Asterisk Phonebook
ENUM - Поиск осуществляется по DNS в соответствии с конфигурационным файлом enum.conf
HTTP - Выполняет HTTP GET - запрос , передавая номер звонящего в качестве аргумента, чтобы получить правильное имя
Рассмотрим каждое из полей, которое необходимо заполнить при выборе данного источника:
Host - IP-адрес или доменное имя сервера, куда будет отправлен запрос GET
Port - Порт, который прослушивает сервер (по умолчанию - 80)
Username - Логин для HTTP аутентификации
Password - Пароль для HTTP аутентификации
Path - Путь к файлу для запроса GET. Например, /cidlookup.php
Query - Строка запроса, специальный токен [NUMBER], в котором будет заменен на номер необходимого абонента. Например, number=[NUMBER]&source=crm.
В случае выбора в качестве источника для поиска сервера HTTPS всё остаётся прежним, за исключением порта. По умолчанию используется порт 443.
MySQL - Поиск имени звонящего осуществляется по базе MySQL
Рассмотрим каждое из полей, которое необходимо заполнить при выборе данного источника:
Host - Имя сервера MySQL
Database - Имя базы данных MySQL
Query - Строка запроса, где специальный токен [NUMBER], будет заменен на номер необходимого абонента. Например, SELECT name FROM phonebook WHERE number LIKE '%[NUMBER]%'
Username и Password для авторизации на сервере MySQL
Character Set - Набор символов MySQL. Чтобы оставить набор символов по умолчанию, оставьте это поле пустым
Пример работы Internal
Для демонстрации примера работы данного модуля, создадим тестовый источник - test_internal.
Поиск в нем будет осуществляться по базе astdb, которая заполняется при помощи модуля Asterisk Phonebook. Перейдём в данный модуль и создадим тестовую запись.
Теперь, необходимо зайти в модуль Inbound Routes и добавить туда правило проверки входящих CID по ранее созданному источнику test_internal.
Готово, теперь, если на номер данного входящего маршрута позвонит 456123789, то на экране нашего телефона мы увидим имя John Doe.
Если вы хотите подробнее узнать о настройке входящих маршрутов, почитайте соответствующую статью в нашей Базе Знаний.
В первой части статей о протоколе Border Gateway Protocol (BGP) мы узнали и разобрали протокол BGP, а затем изучили типы сообщений BGP и состояния соседства. Сегодня, в этой статье, вы узнаете об одном из самых сложных аспектов BGP: как он принимает решение о выборе маршрута.
В то время как протоколы маршрутизации, такие как RIP, OSPF и EIGRP, имеют свои собственные метрики, используемые для выбора «лучшего» пути к целевой сети, BGP использует коллекцию атрибутов пути (PAs).
Предыдущие статьи цикла про BGP:
Основы протокола BGP
Видео: Основы BGP за 7 минут
BGP- атрибуты пути (Path Attributes)
Когда ваш спикер BGP получает BGP префикс, к нему будет прикреплено множество атрибутов пути, и мы знаем, что они будут иметь решающее значение, когда речь заходит о том, чтобы BGP выбрал самый лучший путь к месту назначения.
Все атрибуты BGP- маршрута, делятся на четыре основные категории.
Well-Known Mandatory
Well-Known Discretionary
Optional Transitive
Optional Non-Transitive
Обратите внимание, что две категории начинаются с термина Well-Known. Well-Known означает, что все маршрутизаторы должны распознавать этот атрибут пути. Две другие категории начинаются с термина Optional. Optional означает, что реализация BGP на устройстве вообще не должна распознавать этот атрибут.
Тогда у нас есть термины mandatory и discretionary, связанные с термином Well-Known. Mandatory означает, что обновление должно содержать этот атрибут. Если атрибута нет, тогда появится сообщение об ошибке уведомления, и пиринг будет удален. Discretionary, конечно, будет означать, что атрибута не должно быть в обновлении.
У необязательных категорий атрибутов есть- транзитивные и нетранзитивные. Если он транзитивен, то устройство должно передать этот атрибут пути своему следующему соседу. Если он не является транзитивным, то может просто игнорировать это значение атрибута.
Пример 1 показывает проверку нескольких атрибутов пути для префикса, который был получен маршрутизатором TPA1 от маршрутизатора ATL. Обратите внимание, что мы используем команду show ip bgp для просмотра этой информации, которая хранится в базе данных маршрутизации BGP. В частности, этот вывод показывает атрибуты Next Hop, Metric (MED), LocPrf (Local Preference), Weight, и Path (AS Path).
TPA1#show ip bgp
BGP table version is 4, local router ID is 10.10.10.1
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal, r RIB-failure, S Stale
Origin codes^ I – IGP, e – EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 100.100.100.0/24 10.10.10.2 0 200 i
Атрибут Origin
Атрибут ORIGIN в BGP-это попытка записать, откуда пришел префикс. Существует три возможности, когда речь заходит о происхождении этого атрибута: IGP, EGP и Incomplete. Как видно из легенды примера 1, коды, используемые Cisco для этих источников, являются i, e, и ?. Для префикса, показанного в примере 1, можно увидеть, что источником является IGP. Это указывает на то, что префикс вошел в эту топологию благодаря сетевой команде внутри конфигурации этого исходного устройства. Далее в этой статье мы рассмотрим сетевую команду во всей ее красе. Термин IGP здесь предполагает, что префикс произошел от записи протокола внутреннего шлюза (Gateway Protocol). Допустим, у нас есть префикс в нашей таблице маршрутизации OSPF, а затем мы используем сетевую команду внутри BGP, чтобы поместить его в экосистему BGP. Конечно, IGP - не единственный источник префиксов, которые могут нести этот атрибут. Например, вы можете создать локальный интерфейс обратной связи на устройстве, а затем использовать сетевую команду для объявления этого локального префикса в BGP.
EGP ссылается на ныне устаревший протокол внешнего шлюза (Exterior Gateway Protocol), предшественник BGP. В результате вы не увидите этот исходный код.
Incomplete означает, что BGP не уверен в том, как именно префикс был введен в топологию. Наиболее распространенным сценарием здесь является то, что префикс был перераспределен в Border Gateway Protocol из какого-то другого протокола, обычно IGP.
Возникает вопрос, почему исходный код имеет такое значение. Ответ заключается в том, что это ключевой фактор, когда BGP использует свой алгоритм для выбора наилучшего пути к месту назначения в сети. Он может разорвать «связи» между несколькими альтернативными путями в сети. Мы также уделяем этому атрибуту большое внимание, потому что это действительно один из хорошо известных, обязательных атрибутов, которые должны существовать в наших обновлениях.
Атрибут AS Path
AS Path - это well-known mandatory атрибут. Он очень важен для наилучшего поиска пути, а также для предотвращения петель внутри Border Gateway Protocol.
Рассматривая нашу топологию, показанную на рисунке 1, рассмотрим префикс, возникший в TPA. Обновление отправляется в TPA1, и TPA не добавляет свой собственный AS 100 в AS Path, так как сосед, которому он отправляет обновление, находится в своем собственном AS в соответствии с пирингом iBGP.
Когда TPA1 отправляет обновления на ATL, он добавляет номер 100 в обновления. Следуя этой логике, ATL отправит обновления на ATL2 и не будет добавлять свой собственный номер в качестве AS. Это будет работать до тех пор, пока ATL2 не отправит обновления на какой-то другой AS, предшествующий AS 200. Это означает, что, когда мы рассматриваем образец AS path, как показано в примере 2, крайним правым в пути является AS, который первым создал префикс (100), а крайним левым- AS, который доставил префикс на локальное устройство (342).
Пример 2: Пример BGP AS Path
Атрибут Next Hop
На самом деле нет ничего удивительного в том, что префикс BGP имеет атрибут под названием Next Hop. В конце концов, маршрутизатор должен знать, куда отправлять трафик для этого префикса. Next Hop атрибут удовлетворяет эту потребность. Интересным моментом здесь, однако, является тот факт, что Next Hop в BGP работает не так же, как это происходит в большинстве IGP. Также следует отметить, что правила меняются, когда вы рассматриваете iBGP в сравнении с eBGP.
При рассмотрении протокола внутреннего шлюза, когда устройство отправляет обновление своему соседу, значением Next Hop по умолчанию является IP-адрес интерфейса, с которого отправляется обновление. Этот параметр продолжает сбрасываться каждым маршрутизатором по мере прохождения обновления через топологию. Next Hop принимает простую парадигму «hop-by-hop».
С помощью BGP, когда у нас есть пиринг eBGP и отправляется префикс, Next Hop действительно будет (по умолчанию) IP-адресом спикера eBGP, отправляющего обновление. Однако IP-адрес этого спикера eBGP будет сохранен в качестве Next Hop, поскольку префикс передается от спикера iBGP к спикеру iBGP. Очень часто мы видим атрибут Next Hop, являющийся IP-адресом, который не является устройством, передавшим нам обновление. Это действительно адрес, который представляет собой соседний AS, который предоставил нам префикс. Таким образом, правильно думать о BGP как о протоколе «AS-to-AS» вместо протокола «hop-to-hop».
Это может вызвать определенные проблемы. Основной вывод состоит в том, что вы должны гарантировать, что все ваши спикеры BGP могут достичь значения Next Hop указанного в атрибуте, чтобы путь считался допустимым. Иначе говоря, спикеры BGP будут считать префикс недопустимым, если они не смогут достичь значения Next Hop.
К счастью, эту проблему можно обойти. Вы можете взять устройство iBGP и проинструктировать его, установив себя в качестве значения Next Hop всякий раз, когда вам это нужно. Это делается с помощью манипуляции пирингом командой neighbor, как показано в примере 3.
ATL (config)# router bgp 200
ATL (config-router)# neighbor 10.10.10.1 next-hop-self
Атрибут BGP Weight (веса)
Weight (вес) - это очень интересный атрибут BGP, так как он специфичен для Cisco. Хорошая новость заключается в том, что, поскольку Cisco является гигантом в отрасли сетей, то многие другие производители будут поддерживать использование Weight в качестве атрибута.
Weight также является одним из самых уникальных атрибутов, поскольку это значение не передается другим маршрутизаторам. Weight - это значение, которое присваивается нашим префиксам как локально значимое значение. Weight - это простое число в диапазоне от 0 до 65535, и чем выше значение веса, тем выше предпочтение этого пути. Когда префикс генерируется локально, он будет иметь вес 32768. В противном случае вес префикса по умолчанию равен 0.
Как можно использовать вес? Поначалу это покажется странным, так как он не передается другим спикерам BGP. Однако все просто. Допустим, ваш маршрутизатор получает один и тот же префикс от двух разных автономных систем, с которыми он работает. Если администратор хочет предпочесть один из путей по какой-либо причине, он может манипулировать локальным значением веса на предпочтительном пути и мгновенно влиять на процесс принятия решения о наилучшем пути BGP.
BGP Best Path (выбор лучшего пути)
Как было сказано ранее, мы знаем, что у IGP есть метрическое значение, которое является ключевым для определения наилучшего пути к месту назначения. В случае с OSPF эта метрика основана на стоимости, которая основана на пропускной способности. У BGP существует множество атрибутов пути, которые может иметь префикс. Все они поддаются алгоритму выбора наилучшего пути BGP. На рисунке 2 показаны шаги (начиная сверху), которые используются в выборе наилучших путей Cisco BGP.
Изучая эти критерии выбора пути, вы можете сразу же задаться вопросом, почему он должен быть таким сложным. Помните, когда мы имеем дело с чем-то вроде интернета, мы хотим, чтобы было как можно больше регулировок для политики BGP. Мы хотим иметь возможность контролировать, насколько это возможно, как префиксы используются совместно и предпочтительно в такой большой и сложной сети.