По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Зачастую можно столкнуться с задачами, когда необходимо обеспечить доступ к внутренним корпоративным (или домашним) ресурсам из Интернета. В этом случае, нужно выполнить, так называемый "проброс портов". Что это такое, зачем это нужно и как настраивать на примере роутера 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.
Управление временем, в любой операционной системе, очень тесно связанно с понятием часовой зоны. Ранее мы рассказывали про работу с утилитой настройки часовой зоны tzselect. В данной утилите с помощью мастера настраивали зону. Но, по сути, утилита нам выдала только переменную для настройки и описание, как настроить для постоянного использования. Можно пойти несколькими путями:
Первый путь:
TZ=’Europe/Moscow’ - задать переменную
export TZ – экспортировать данную переменную.
Для того, чтобы применились параметры нужно перелогинится или перезагрузиться.
И после этого мы можем посмотреть текущую TZ (timezone) в файле - cat /etc/timezone
Вывод будет таким: Europe/Moscow
Второй путь это использовать утилиту timedatectl:
timedatectl list-timezones - смотрим доступные временные зоны
sudo timedatectl set-timezone Europe/Moscow
Значение времени в операционных системах определяется 4 частями:
Значение времени
Стандарт времени или универсальное время
Часовой пояс
Переход на летнее время
Для любой операционной системы есть 2 вида часов – это системные время, которое работает в рамках операционной системы с кучей параметров и аппаратные часы, работа которых определяется схемой на материнской плате и поддерживаются эти часы в работе, благодаря батарейке на материнской плате. Аппаратные часы после включения сервера или компьютера передают свое значение времени операционной системе, а далее система уже сама работает с часами. Аппаратные часы по факту нужны только для старта операционной системы. В настоящее время этот момент стал не столь важным, т.к. практически все сервера имеют доступ в интернет и могут со специальными сайтами синхронизировать время. В случае работы операционной системы на виртуальной машине, время синхронизируется с материнской машиной.
Как мы в прошлой статье уже рассматривали, есть утилита для управления и изменения системного времени - date, а есть утилита hwclock для того, чтобы посмотреть аппаратное время. Для работы данной утилиты необходимы права суперпользователя - sudo hwclock
Вот такой вывод получается, у нас в примере виртуализация на ESXI vmware и виртуализация позволяет синхронизировать часы дочерней операционной системы с аппаратными часами материнского сервера. В вашем же случае, если операционная система будет развернута на Virtualbox, то синхронизации этой происходить не будет (только при старте виртуальной машины) и будет отображаться разница во времени в результате вывода команды. Далее операционная система виртуальной машины и материнского хоста идут независимо друг от друга.
Хотелось бы отметить, что время важно не только для самой операционной системы, но и так же для взаимодействия с другими серверами, например, при использовании авторизации с помощью протокола Kerberos, в котором сервис генерирует токены опираясь на метку времени в операционной системе и, если будет слишком большое расхождение между серверами, токен не будет принят. Исходя из этого команду hwclock можно использовать и для установки времени.
sudo hwclock --set --date=[”нужное_время”] – нужное время задаем в виде dd/mm/yyyy hh:mm
То есть мы можем задать любое аппаратное время. Синхронизация пройдет только при старте операционной системы в нашем случае. Для синхронизации времени одних, часов с другими необходимо выполнить команду sudo hwclock -w.
Но в таком формате синхронизировать время не удобно, в настоящее время практически на всех серверах используется автоматическая синхронизация времени по протоколу NTP.
Данный протокол, обеспечивает синхронизацию системного времени с удаленным сервером в интернете. NTP протокол на транспортном уровне работает, через UDP на 123 порту. В интернете есть такой проект, как NTP Pool Project у которого есть сервера точного времени. Его страничка https://www.ntppool.org/ru/, по данной страничке можно подобрать ближайший к вам сервер точного времени и сделать настройку на него своего сервера или группы серверов.
Вот сервера, актуальные для России:
server 0.ru.pool.ntp.org
server 1.ru.pool.ntp.org
server 2.ru.pool.ntp.org
server 3.ru.pool.ntp.org
Для разовой синхронизации можно использовать следующую утилиту, предварительно установив ее:
sudo ntpdate [адрес_сервера]
В нашем случае получится следующее:sudo ntpdate 0.ru.pool.ntp.org
В результате время синхронизировалось, и утилита показала расхождение, которое было.
Теперь настроим автоматическую синхронизацию времени для этого необходимо установить ntpd демон. Делается это стандартным способом.
sudo apt-get install ntp -y
И отредактировать файл /etc/ntp.conf. Данный демон умеет и сам раздавать время в сети, мы можем настроить другие сервера на синхронизацию с ним, но сейчас необходимо просто настроить синхронизацию текущего сервера с временем сервера в интернете - sudo nano /etc/ntp.conf.
Добавляем сервера в файл, сохраняем и перезапускаем демона - sudo service ntp restart.
И мы можем посмотреть с какими серверами теперь наш сервер может синхронизироваться: ntpdq -pn
Получим вот такой вывод сервером с которыми у нас будет происходить синхронизация.
В первой статье серии EIGRP мы познакомились с функциями EIGRP, рассмотрели пример базовой конфигурации и набор команд проверки. Сегодня, в этой статье, мы углубимся в понимание того, как EIGRP устанавливает соседство, изучает маршрут к сети, определяет оптимальный маршрут к этой сети, и пытается ввести этот маршрут в таблицу IP-маршрутизации маршрутизатора.
Предыдущие статьи из цикла про EIGRP:
Часть 1. Понимание EIGRP: обзор, базовая конфигурация и проверка
Следующие статьи из цикла:
Часть 2.2. Установка K-значений в EIGRP
Часть 3. Конвергенция EIGRP – настройка таймеров
Часть 4. Пассивные интерфейсы в EIGRP
Часть 5. Настройка статического соседства в EIGRP
Часть 6. EIGRP: идентификатор роутера и требования к соседству
Операции EIGRP могут быть концептуально упрощены в три основных этапа:
Этап 1. Обнаружение соседей: посредством обмена приветственными сообщениями EIGRP-спикер маршрутизаторы обнаруживают друг друга, сравнивают параметры (например, номера автономной системы, K-значения и сетевые адреса) и определяют, должны ли они образовывать соседство.
Этап 2. Обмен топологиями: если соседние EIGRP маршрутизаторы решают сформировать соседство, они обмениваются своими полными таблицами топологии друг с другом. Однако после установления соседства между маршрутизаторами передаются только изменения существующей топологии. Этот подход делает EIGRP намного более эффективным, чем протокол маршрутизации, такой как RIP, который объявляет весь свой список известных сетей через определенные интервалы времени.
Этап 3. Выбор маршрутов: как только таблица топологии EIGRP маршрутизатора заполнена, процесс EIGRP проверяет все изученные сетевые маршруты и выбирает лучший маршрут к каждой сети. EIGRP считает, что сетевой маршрут с самой низкой метрикой является лучшим маршрутом к этой сети.
Очень важно, что в когда вы читаете вышеописанные этапы, подробно описывающее обнаружение соседей EIGRP, обмен топологией и выбор маршрута, должны понимать, что в EIGRP, в отличие от OSPF, нет понятия назначенного маршрутизатора (DR) или резервного назначенного маршрутизатора (BDR).
Обнаружение соседей и обмен топологиями
Чтобы лучше понять, как маршрутизатор EIGRP обнаруживает своих соседей и обменивается информацией о топологии с этими соседями, рассмотрим рисунок ниже.
Шесть шагов, изображенных на рисунке выше, выполняются следующим образом:
Шаг 1. Маршрутизатор OFF1 хочет видеть, есть ли какие-либо EIGRP-спикер маршрутизаторы вне его интерфейса Gig 0/1, с которым он мог бы, возможно, сформировать соседство. Таким образом, он осуществляет многоадресную рассылку приветственного сообщения EIGRP (EIGRP Hello) на хорошо известный EIGRP multicast-адрес 224.0.0.10 с просьбой к любым EIGRP-спикер маршрутизаторам, идентифицировать себя.
Шаг 2. После получения приветственного сообщения маршрутизатора OFF1 маршрутизатор OFF2 отправляет одноадресное сообщение обновления (unicast Update message)обратно на IP-адрес маршрутизатора OFF1 10.1.1.1. Это сообщение обновления содержит полную таблицу топологии EIGRP маршрутизатора OFF2.
Шаг 3. Маршрутизатор OFF1 получает обновление маршрутизатора OFF2 и отвечает одноадресным сообщением подтверждения (Acknowledgement (ACK), отправленным на IP-адрес маршрутизатора OFF2 10.1.1.2.
Шаг 4. Затем процесс повторяется, и роли меняются местами. В частности, маршрутизатор OFF2 отправляет приветственное сообщение на адрес многоадресной рассылки EIGRP 224.0.0.10.
Шаг 5. Маршрутизатор OFF1 отвечает на приветственное сообщение маршрутизатора OFF2 одноадресным обновлением (unicast Update), содержащим полную таблицу топологии EIGRP маршрутизатора OFF1. Это unicast Update достигается IP-адрес маршрутизатора OFF2 10.1.1.2.
Шаг 6. Маршрутизатор OFF2 получает информацию о маршрутизации маршрутизатора OFF1 и отвечает одноадресным сообщением ACK, отправленным на IP-адрес маршрутизатора OFF1 10.1.1.1.
На этом этапе было установлено соседство EIGRP между маршрутизаторами OFF1 и OFF2. Маршрутизаторы будут периодически обмениваться приветственными сообщениями, чтобы подтвердить, что сосед каждого маршрутизатора все еще присутствует. Однако это последний раз, когда маршрутизаторы обмениваются своей полной информацией о маршрутизации. Последующие изменения топологии объявляются через частичные обновления, а не полные обновления, используемые во время создания соседства. Кроме того, обратите внимание, что сообщения обновления во время установления соседа были отправлены как одноадресные сообщения. Однако будущие сообщения обновления отправляются как многоадресные сообщения, предназначенные для 224.0.0.10. Это гарантирует, что все EIGRP-спикер маршрутизаторы на сегменте получают сообщения об обновлении.
EIGRP имеет преимущество перед OSPF в том, как он отправляет свои сообщения об обновлении. В частности, сообщения об обновлении EIGRP отправляются с использованием надежного транспортного протокола ( Reliable Transport Protocol (RTP). Это означает, что, в отличие от OSPF, если сообщение обновления будет потеряно при передаче, он будет повторно отправлено.
Примечание: аббревиатура RTP также относится к Real-time Transport Protocol (RTP), который используется для передачи голосовых и видеопакетов.
Выбор маршрута
Маршруты, показанные в таблице топологии EIGRP, содержат метрическую информацию, указывающую, насколько "далеко" она находится от конкретной целевой сети. Но как именно рассчитывается эта метрика? Расчет метрики EIGRP немного сложнее, чем с RIP или OSPF. В частности, метрика EIGRP по умолчанию является целочисленным значением, основанным на пропускной способности и задержке. Также, вычисление метрики может включать и другие компоненты. Рассмотрим формулу вычисления метрики EIGRP:
Обратите внимание, что расчет метрики включает в себя набор K-значений, которые являются константами, принимающие нулевые значения или некоторые положительные целые числа. Расчет также учитывает пропускную способность, задержку, нагрузку и надежность (bandwidth, delay, load, reliability). Интересно, что большая часть литературы по EIGRP утверждает, что метрика также основана на Maximum Transmission Unit (MTU). Однако, как видно из формулы расчета метрики, MTU отсутствует. Так в чем же дело? Учитывает ли EIGRP MTU интерфейса или нет?
В самом начале разработки EIGRP, MTU был обозначен как Тай-брейкер, если два маршрута имели одинаковую метрику, но разные значения MTU. В такой ситуации был бы выбран маршрут с более высоким MTU. Таким образом, хотя сообщение об обновлении EIGRP действительно содержит информацию MTU, эта информация непосредственно не используется в расчетах метрик.
Далее, давайте рассмотрим каждый компонент расчета метрики EIGRP и tiebreaking MTU:
Bandwidth (Пропускная способность): значение пропускной способности, используемое в расчете метрики EIGRP, определяется путем деления 10 000 000 на пропускную способность (в Кбит / с) самого медленного канала вдоль пути к целевой сети.
Delay (Задержка): в отличие от полосы пропускания, которая представляет собой "самое слабое звено", значение задержки является кумулятивным. В частности, это сумма всех задержек, связанных со всеми интерфейсами, которые используются чтобы добраться до целевой сети. Выходные данные команды show interfaces показывают задержку интерфейса в микросекундах. Однако значение, используемое в расчете метрики EIGRP, выражается в десятках микросекунд. Это означает, что вы суммируете все задержки выходного интерфейса, как показано в выводе show interfaces для каждого выходного интерфейса, а затем делите на 10, чтобы получить единицу измерения в десятки микросекунд.
Reliability (Надежность): надежность-это значение, используемое в числителе дроби, с 255 в качестве ее знаменателя. Значение дроби указывает на надежность связи. Например, значение надежности 255 указывает на то, что связь надежна на 100 процентов (то есть 255/255 = 1 = 100 процентов).
Load (Нагрузка): как и надежность, нагрузка-это значение, используемое в числителе дроби, с 255 в качестве ее знаменателя. Значение дроби указывает, насколько занята линия. Например, значение нагрузки 1 указывает на то, что линия загружена минимально (то есть 1/255 = 0,004 1%)
MTU: хотя он не отображается в Формуле вычисления метрики EIGRP, значение MTU интерфейса (которое по умолчанию составляет 1500 байт) переносится в сообщение обновления EIGRP, которое будет использоваться в случае привязки (например, два маршрута к целевой сети имеют одну и ту же метрику, но разные значения MTU), где предпочтительно более высокое значение MTU.
Для улучшения запоминания используйте следующий алгоритм Big Dogs Really Like Me. Где B в слове Big ассоциируется с первой буквой в слове Bandwidth. Буква D в слове Dogs соответствует первой букве D в слове Delay, и так далее.
Однако по умолчанию EIGRP имеет большинство своих K-значений равными нулю, что значительно упрощает расчет метрики, учитывая только пропускную способность и задержку. В частности, значения K по умолчанию являются:
K1 = 1
K2 = 0
K3 = 1
K4 = 0
K5 = 0
Если мы подставим эти дефолтные значения K в расчет метрики EIGRP, то значение каждой дроби будет равно нулю, что сводит формулу к следующему:
Чтобы закрепить знания по вычислению метрики, давайте проведем расчет метрики и посмотрим, соответствует ли она нашей таблице топологии EIGRP. Рассмотрим топологию, показанную на рисунке ниже.
Предположим, что мы хотим вычислить метрику для сети 198.51.100.0/24 от роутера OFF1 для маршрута, который идет от OFF1 до OFF2, а затем выходит в целевую сеть. Из топологии мы можем определить, что нам нужно будет выйти с двух интерфейсов маршрутизатора, чтобы добраться от маршрутизатора OFF1 до сети 198.51.100.0 /24 через маршрутизатор OFF2. Эти два выходных интерфейса являются интерфейсами Gig0/1 на маршрутизаторе OFF1 и интерфейсом Gig0/3 на маршрутизаторе OFF2. Мы можем определить пропускную способность и задержку, связанные с каждым интерфейсом, изучив выходные данные команд show interfaces, приведенных в следующем примере.
Определение значений пропускной способности и задержки интерфейса на маршрутизаторах OFF1 и OFF2
Из приведенного выше примера мы видим, что оба выходных интерфейса имеют пропускную способность 1 000 000 Кбит/с (то есть 1 Гбит/с). Кроме того, мы видим, что каждый выходной интерфейс имеет задержку в 10 микросекунд. Значение пропускной способности, которое мы вводим в нашу формулу вычисления метрики EIGRP, - это пропускная способность самого медленного канала на пути к целевой сети, измеряемая в Кбит/с. В нашем случае оба выходных интерфейса имеют одинаковую скорость соединения, то есть мы говорим, что наша "самая медленная" связь составляет 1 000 000 Кбит/с.
Для примера ниже показаны общие значения по умолчанию для пропускной способности и задержки на различных типах интерфейсов маршрутизатора Cisco.
Общие значения по умолчанию для пропускной способности и задержки интерфейса:
Наше значение задержки может быть вычислено путем сложения задержек выходного интерфейса (измеренных в микросекундах) и деления на 10 (чтобы дать нам значение, измеренное в десятках микросекунд). Каждый из наших двух выходных интерфейсов имеет задержку в 10 микросекунд, что дает нам суммарную задержку в 20 микросекунд. Однако мы хотим, чтобы наша единица измерения была в десятках микросекунд. Поэтому мы делим 20 микросекунд на 10, что дает нам 2 десятка микросекунд. Теперь у нас есть два необходимых значения для нашей формулы: пропускная способность = 1 000 000 Кбит/с и задержка = 2 десятка микросекунд. Теперь давайте добавим эти значения в нашу формулу:
Вычисленное значение показателя EIGRP составляет 3072. Теперь давайте посмотрим, является ли это фактической метрикой, появляющейся в таблице топологии EIGRP маршрутизатора OFF1. Выходные данные команды show ip eigrp topology, выведенные на маршрутизаторе OFF1, показаны в следующем примере.
Проверка метрики EIGRP для сети 198.51.100.0/24 на маршрутизаторе OFF1
Как и предполагалось, метрика (также известная как допустимое расстояние) от маршрутизатора OFF1 до Сети 198.51.100.0 /24 через маршрутизатор OFF2 составляет 3072. Напомним, что в этом примере мы использовали значения K по умолчанию, что также является обычной практикой в реальном мире. Однако для целей проектирования мы можем манипулировать K-значениями. Например, если мы обеспокоены надежностью каналом связи или нагрузкой, которую мы могли бы испытать на линии, мы можем манипулировать нашими K-значениями таким образом, чтобы EIGRP начал бы рассматривать надежность и/или нагрузку в своем метрическом расчете. В следующей статье мы рассмотрим, как мы можем изменить эти K - значения в EIGRP по умолчанию.