По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Классификация сама по себе не приводит к определенному состоянию переадресации со стороны сетевого устройства. Скорее, классификация трафика - это первый необходимый шаг в создании основы для дифференцированного поведения пересылки. Другими словами, пакеты были классифицированы и дифференцированы, но это все. Выявление различий - это не то же самое, что дифференцированные действия с этими классами.
Наше обсуждение QoS теперь переходит в сферу политики. Как управлять перегруженными интерфейсами? Когда пакеты ожидают доставки, как сетевое устройство решает, какие пакеты будут отправлены первыми? Точки принятия решения основаны в первую очередь на том, насколько хорошо пользовательский интерфейс может выдерживать джиттер, задержку и потерю пакетов. Для решения этих проблем возникают различные проблемы и инструменты QoS.
Своевременность: организация очередей с малой задержкой
Сетевые интерфейсы пересылают пакеты как можно быстрее. Когда трафик проходит со скоростью, меньшей или равной пропускной способности выходного интерфейса, трафик доставляется по одному пакету за раз, без каких-либо проблем. Когда интерфейс может соответствовать предъявляемым к нему требованиям, перегрузки не возникает. Без перегрузок нет необходимости беспокоиться о дифференцированных типах трафика. Отметки на отдельных пакетах можно наблюдать в статистических целях, но политики QoS, которую нужно применять, нет. Трафик поступает на выходной интерфейс и доставляется.
Как было рассказано ранее в лекции "Коммутация пакетов", пакеты доставляются в кольцо передачи после коммутации. Физический процессор исходящего интерфейса удаляет пакеты из этого кольца и синхронизирует их с физической сетевой средой. Что произойдет, если будет передано больше пакетов, чем может поддерживать канал связи? В этом случае пакеты помещаются в очередь, выходную очередь, а не в кольцо передачи. Политики QoS, настроенные на маршрутизаторе, фактически реализуются в процессе удаления пакетов из очереди вывода на кольцо передачи для передачи. Когда пакеты помещаются в очередь вывода, а не в кольцо передачи, интерфейс считается перегруженным.
По умолчанию перегруженные сетевые интерфейсы доставляют пакеты в порядке очереди (FIFO). FIFO не принимает стратегических решений на основе дифференцированных классов трафика; скорее, FIFO просто обслуживает буферизованные пакеты по порядку настолько быстро, насколько это позволяет выходной интерфейс. Для многих приложений FIFO - неплохой способ удаления пакетов из очереди. Например, в реальном мире может быть небольшое влияние, если пакет протокола передачи гипертекста (HTTP, протокол, используемый для передачи информации World Wide Web) с одного веб-сервера передается раньше, чем пакет с другого веб-сервера.
Для других классов трафика большое внимание уделяется своевременности. В отличие от FIFO, некоторые пакеты следует переместить в начало очереди и отправить как можно быстрее, чтобы избежать задержки и влияния на работу конечного пользователя. Одно из последствий - это пакет, прибывающий слишком поздно, чтобы быть полезным. Другой удар заключается в том, что пакет вообще не поступает. Стоит рассмотреть каждый из этих сценариев, а затем несколько полезных инструментов QoS для каждого.
Голосовой трафик по IP (VoIP) должен вовремя. При рассмотрении голосового трафика подумайте о любом голосовом чате в реальном времени, который осуществляется через Интернет с помощью такого приложения, как Skype. В большинстве случаев качество связи приличное. Вы можете слышать другого человека. Этот человек может вас слышать. Разговор протекает нормально. С таким же успехом вы можете находиться в одной комнате с другим человеком, даже если он находится на другом конце страны.
Иногда качество звонков VoIP может снижаться. Вы можете услышать серию субсекундных заиканий в голосе человека, при этом скорость передачи голоса нерегулярна. В этом случае вы испытываете джиттер, что означает, что пакеты не поступают стабильно вовремя. Чрезмерно длинные промежутки между пакетами приводят к слышимому эффекту заикания. Хотя пакеты не были потеряны, они не были своевременно доставлены по сетевому пути. Где-то по пути пакеты задерживались достаточно долго, чтобы появились слышимые артефакты. На рисунке 5 показан джиттер при пакетной передаче.
Качество вызова VoIP также может пострадать из-за потери пакетов, когда пакеты на сетевом пути были сброшены по пути. Хотя существует множество потенциальных причин потери пакетов в сетевых путях, рассмотренный здесь сценарий - это "отбрасывание хвоста", когда поступило такое количество трафика, которое выходит за пределы возможностей выходного интерфейса, и в буфере не остается места для добавления в очередь дополнительных излишков. В результате отбрасываются самые последние поступления трафика; это падение называется хвостовым падением.
Качество вызова VoIP также может пострадать из-за потери пакетов, когда пакеты на сетевом пути были сброшены по пути. Хотя существует множество потенциальных причин потери пакетов в сетевых путях, рассмотренный здесь сценарий - это "отбрасывание хвоста", когда поступило такое количество трафика, которое выходит за пределы возможностей выходного интерфейса, и в буфере не остается места для добавления в очередь дополнительных излишков. В результате отбрасываются самые последние поступления трафика; это падение называется хвостовым падением.
Когда трафик VoIP отбрасывается, слушатель слышит результат потери. Есть пробелы, в которых голос говорящего полностью отсутствует. Отброшенные пакеты могут проходить в виде тишины, поскольку последний бит принятого звука зацикливается, чтобы заполнить пробел, продолжительное шипение или другой цифровой шум. На рисунке ниже показаны отброшенные пакеты через маршрутизатор или коммутатор.
Чтобы обеспечить стабильное качество вызовов даже в условиях перегруженности сетевого пути, необходимо применять схему приоритезации QoS. Эта схема должна соответствовать следующим критериям.
Трафик VoIP должен быть доставлен: потеря пакетов VoIP приводит к слышимому прерыванию разговора.
Трафик VoIP должен доставляться вовремя: задержка или прерывание пакетов VoIP приводит к слышимым заиканиям.
Трафик VoIP не должен ограничивать пропускную способность других классов трафика: так же важно, как и VoIP, хорошо написанные политики QoS уравновешивают своевременную доставку голосовых пакетов с необходимостью для других классов трафика также использовать канал.
Распространенной схемой, используемой для определения приоритетов трафика, чувствительного к потерям и jitter, является организация очередей с низкой задержкой (LLQ). Никакие RFC IETF не определяют LLQ; скорее, поставщики сетевого оборудования изобрели LLQ в качестве инструмента в наборе политик QoS для определения приоритетов трафика, требующего низкой задержки, jitter и потерь, например, голоса.
LLQ есть два ключевых элемента.
Трафик, обслуживаемый LLQ, передается как можно быстрее, чтобы избежать задержки и минимизировать джиттер.
Трафик, обслуживаемый LLQ, не может превышать определенный объем полосы пропускания (обычно рекомендуется не более 30% доступной полосы пропускания). Трафик, превышающий предел пропускной способности, скорее отбрасывается, чем передается. Этот метод позволяет избежать потери трафика других классов.
В этой схеме подразумевается компромисс для услуг классов трафика посредством LLQ. Трафик будет обслуживаться как можно быстрее, эффективно перемещая его в начало очереди, как только он обнаруживается на перегруженном интерфейсе. Загвоздка в том, что существует ограничение на то, сколько трафика в этом классе будет обрабатываться таким образом. Это ограничение налагается сетевым инженером, составляющим политику QoS.
В качестве иллюстрации предположим, что канал WAN имеет доступную пропускную способность 1024 Кбит/с. Этот канал соединяет головной офис с облаком WAN поставщика услуг, которое также соединяет несколько удаленных офисов с головным офисом. Это загруженный канал WAN, по которому проходит трафик VoIP между офисами, а также трафик веб-приложений и резервный трафик время от времени. Кроме того, предположим, что система VoIP кодирует голосовой трафик с помощью кодека, требующего 64 Кбит/с на разговор.
Теоретически, этот канал с пропускной способностью 1024 Кбит/с может обеспечить одновременные разговоры VoIP 16 × 64 Кбит/с. Однако это не оставит места для других типов трафика, которые присутствуют. Это занятое соединение WAN! Решение должно быть принято при написании политики QoS. Сколько голосовых разговоров будет разрешено LLQ, чтобы избежать нехватки оставшегося трафика полосы пропускания? Можно было бы сделать выбор, чтобы ограничить LLQ пропускной способностью только 512 Кбит/с, что было бы достаточно для обработки восьми одновременных разговоров, оставив остальную часть канала WAN для других классов трафика.
Предполагая, что канал перегружен, что произойдет с девятым разговором VoIP, если он должен находиться в ситуации, чтобы политика QoS была эффективной? Этот вопрос на самом деле наивен, потому что он предполагает, что каждый разговор обрабатывается отдельно политикой QoS. Фактически, политика QoS рассматривает весь трафик, обслуживаемый LLQ, как одну большую группу пакетов. После присоединения девятого разговора VoIP будет трафик на 576 Кбит/с, который будет обслуживаться LLQ, которому выделено только 512 Кбит/с. Чтобы найти количество отброшенного трафика, вычтите общий трафик, выделенный для LLQ, из общего предлагаемого трафика: 576 Кбит/с - 512 Кбит/с = 64 Кбит/с трафик LLQ будет отброшен в соответствии с ограничением полосы пропускания. Отброшенные 64 Кбит/с будут исходить от класса трафика LLQ в целом, что повлияет на все разговоры VoIP. Если десятый, одиннадцатый и двенадцатый разговор VoIP присоединиться к LLQ, проблема станет более серьезной. В этом случае 64 Кбит/с × 4 = 256 Кбит/с несоответствующего трафика, который будет отброшен из LLQ, что приведет к еще большим потерям во всех разговорах VoIP.
Как показывает этот пример, для управления перегрузкой необходимо знать состав приложений, время пиковой нагрузки, требования к полосе пропускания и доступные варианты сетевой архитектуры. Только после того, как будут учтены все моменты, можно найти решение, отвечающее бизнес-целям. Например, предположим, что 1024 Кбит/с - это максимальное значение, которое вы можете сделать для линии дальней связи из-за ограничений по стоимости. Вы можете увеличить ограничение полосы пропускания LLQ до 768 Кбит/с, чтобы обеспечить 12 разговоров со скоростью 64 Кбит/с каждый. Однако для другого трафика останется только 256 Кбит/с, чего, возможно, недостаточно для удовлетворения потребностей вашего бизнеса в других приложениях.
В этом случае можно согласовать с администратором системы голосовой связи использование голосового кодека, требующего меньшей полосы пропускания. Если новый кодек, требующий только 16 Кбит/с полосы пропускания на вызов, развернут вместо исходных 64 Кбит/с, 32 разговора VoIP могут быть перенаправлены без потерь через LLQ с выделенной полосой пропускания 512 Кбит/с. Компромисс? Качество голоса. Человеческий голос, закодированный со скоростью 64 Кбит/с, будет звучать более четко и естественно по сравнению с голосом, закодированным на скорости 16 Кбит/с. Также может быть лучше кодировать со скоростью 16 Кбит/с, чтобы отбрасывать меньше пакетов и, следовательно, общее качество лучше. Какое решение применить, будет зависеть от конкретной ситуации.
Через интерфейс может пройти больше трафика, чем указано в ограничении полосы пропускания LLQ. Если ограничение полосы пропускания для трафика, обслуживаемого LLQ, установлено на максимум 512 Кбит/с, возможно, что трафик класса более чем на 512 Кбит/с пройдет через интерфейс. Такое запрограммированное поведение проявляется только в том случае, если интерфейс не перегружен. В исходном примере, где используется кодек 64 Кбит/с, передача 10 разговоров со скоростью 64 Кбит/с по каналу приведет к передаче голосового трафика 640 Кбит/с по каналу пропускной способности 1024 Кбит/с (1024 Кбит/с - 640 Кбит/с = 384 Кбит/с осталось). Пока все другие классы трафика остаются ниже общего использования полосы пропускания 384 Кбит / с, канал не будет перегружен. Если канал не перегружен, политики QoS не вступают в силу. Если политика QoS не действует, то ограничение полосы пропускания LLQ в 512 Кбит/с не влияет на 640 Кбит/с агрегированного голосового трафика.
В этой статье о LLQ контекстом был голосовой трафик, но имейте в виду, что LLQ может применяться к любому желаемому виду трафика. Однако в сетях, где присутствует VoIP, VoIP обычно является единственным трафиком, обслуживаемым LLQ. Для сетей, в которых нет трафика VoIP, LLQ становится интересным инструментом, гарантирующим своевременную доставку с малой задержкой и дрожанием других видов трафика приложений. Однако LLQ - не единственный инструмент, доступный для составителя политики QoS. Также пригодятся несколько других инструментов.
Когда мы только начинаем изучать Python, мы закладываем некоторые вредные привычки при написании кода, о которых мы можем даже не подозревать.
Вы можете написать код, который сработает сейчас, но может не сработать в будущем, или вы можете использовать какие-то хитрые ходы вместо встроенной функции, которая могла бы облегчить вашу жизнь.
У большинства из нас сохранились не одна из тех вредных привычек при программировании на Python, что формируются в период первых месяцев обучения. Отличная новость в том, что вы можете с легкостью искоренить их, прочитав приведенный ниже текст.
1. Использование import *
Каждый раз, когда нам становится лень, то возникает соблазн импортировать все необходимое из модуля с помощью from xyz import *.
Это не самый лучший подход по многим причинам. Кот несколько из них:
Это может оказаться неэффективно: если в модуле очень много объектов, то вам придется долго ждать, пока все импортируется.
Это может вызвать конфликт имен переменных: когда вы используете *, то вы понятия не имеете, какие объекты вы импортируете и как они называются.
Как же с этим бороться? Импортируйте либо какой-то конкретный объект, либо весь модуль целиком.
# Using import *
# Bad
from math import *
print(floor(2.4))
print(ceil(2.4))
print(pi)
# Good
import math
from math import pi
print(math.floor(2.4))
print(math.ceil(2.4))
print(pi)
2. Try/except: отсутствие указания исключения в блоке «except»
Я очень долго пренебрегал этим. Сложно посчитать, сколько раз Pycharm давал мне понять (этими противными подчеркиваниями), что не нужно использовать «голое» исключение. Это идет в разрез с рекомендациями PEP8.
# Try - except
# Bad
try:
driver.find_element(...)
except:
print("Which exception?")
# Good
try:
driver.find_element(...)
except NoSuchElementException:
print("It's giving NoSuchElementException")
except ElementClickInterceptedException:
print("It's giving ElementClickInterceptedException")
Проблема «голых» исключений заключается в том, что оно будет перехватывать исключения SystemExit и KeyboardInterrupt, что затрудняет прерывание программы с помощью Control-C.
В следующий раз, когда вы будете использовать try/except, укажите исключение в блоке except.
3. Не использовать Numpy для математических вычислений
Очень часто мы забываем, что в Python есть множество пакетов, которые могут значительно облегчить нашу жизнь и сделать ее более продуктивной.
Одним из таких пакетов является Numpy – пакет для математических вычислений. Numpy может помочь вам вычислять математические операции быстрее, чем циклы for.
Допустим, что у нас есть массив random_scores, и мы хотим получить средний балл тех, кто не сдал экзамен (score>>dict_countries.keys()
dict_keys(['USA', 'UK', 'Canada'])>>>dict_countries.values()
dict_values([329.5, 67.2, 38])
Проблема тут заключается в том, что мы не всегда используем их должным образом.
Например, мы хотим просмотреть словарь и получить ключи. Вы можете использовать метод .keys, но знаете ли вы, что ключи можно получить, просто перебирая словарь? В этом случае использование метода .keys будет излишним.
# Not using .keys() properly
# Bad
for key in dict_countries.keys():
print(key)
# Good
for key in dict_countries:
print(key)
Кроме того, можно придумать некоторые хитрости для получения значений словаря, например, с помощью метода .items().
# Not using .items()
# Bad
for key in dict_countries:
print(dict_countries[key])
# Good
for key, value in dict_countries.items():
print(key)
print(value)
7. Никогда не использовать генераторы (или использовать их всегда)
Генератор предлагает более простой синтаксис при создании новой последовательности (списка, словаря и т.д.) на основе уже определенной последовательности.
Допустим, мы хотим перевести все элементы в нашем списке countries в нижний регистр.
И хотя вы могли бы это сделать просто с помощью цикла for, но также вы можете упростить работу при помощи генератора списка.
# Bad
countries = ['USA', 'UK', 'Canada']
lower_case = []
for country in countries:
lower_case.append(country.lower())
# Good (but don't overuse it!)
lower_case = [country.lower() for country in countries]
Генераторы – это очень полезно, но не злоупотребляйте ими! Помните правило Дзен Python: «Простое лучше, чем сложное».
8. Использование range(len())
Одни из первых функций, которые мы изучили будучи новичками – это range и len, поэтому не удивительно, почему многие люди имеют дурную привычку писать range(len()) при переборе списков.
Допустим у нас есть два списка: countries и populations. Если мы хотим пройтись по обоим спискам одновременно, то, вероятнее всего, вы воспользуетесь range(len()).
# Using range(len())
countries = ['USA', 'UK', 'Canada']
populations = [329.5, 67.2, 38]
# Bad
for i in range(len(countries)):
country = countries[i]
population = populations[i]
print(f'{country} has a population of {population} million people')
И хотя это в принципе выполняет свою работу, вы все равно можете упростить задачу, воспользовавшись enumerate (или, что еще лучше, воспользовавшись функцией zip для сопряжения элементов из обоих списков).
# OK
for i, country in enumerate(countries):
population = populations[i]
print(f'{country} has a population of {population} million people')
# Much Better
for country, population in zip(countries, populations):
print(f'{country} has a population of {population} million people')
9. Форматирование с помощью оператора +
Вероятно, одна из первых вещей, которую мы изучаем в Python, - это то, как соединять строки с помощью оператора +.
Это полезный, но не самый эффективный способ соединения строк в Python. Помимо этого, это не очень красиво – чем больше строк вам нужно соединить, тем больше операторов + вы будете использовать.
Вместо этого вы можете воспользоваться f-строкой.
# Formatting with + operator
# Bad
name = input("Introduce Name: ")
print("Good Morning, " + name + "!")
# Good
name = input("Introduce Name: ")
print(f'Good Morning, {name}')
Преимуществом f-строк в том, что они полезны не только для конкатенации, но и для других целей.
10. Использование изменяемых значений в качестве значений по умолчанию
Если вы включите изменяемое значение (например, список) в качестве параметра функции по умолчанию, то увидите нечто неожиданное.
# Bad
def my_function(i, my_list=[]):
my_list.append(i)
return my_list>>> my_function(1)
[1]
>>> my_function(2)
[1, 2]
>>> my_function(3)
[1, 2, 3]
В приведенном выше коде каждый раз, когда мы вызываем функцию my_function, список my_list сохраняет значения из предыдущих вызовов (а мы, скорее всего, хотим инициировать пустой список при каждом вызове функции).
Чтобы избежать такой проблемы, мы должны установить этот параметр my_list равным None и добавить условие if как показано ниже.
# Good
def my_function(i, my_list=None):
if my_list is None:
my_list = []
my_list.append(i)
return my_list>>> my_function(1)
[1]
>>> my_function(2)
[2]
>>> my_function(3)
[3]
Мы рассказали про принципы работы протокола NAT (Network Address Translation) и теперь настало время рассмотреть его настройку на оборудовании Cisco.
Настройка статического NAT (Static NAT)
Напомним, что статический NAT представляет собой сопоставление внутреннего и внешнего адреса один к одному. Он позволяет внешним устройствам инициировать подключения к внутренним с использованием статически назначенного общего адреса.
Например, внутренний веб-сервер может быть сопоставлен с определенным внутренним глобальным адресом, чтобы он был доступен из внешних сетей.
На схеме показана внутренняя сеть, содержащая веб-сервер с частным адресом IPv4. Маршрутизатор сконфигурирован со статическим NAT, чтобы позволить устройствам из внешней сети обращаться к веб-серверу. Клиент из внешней сети обращается к веб-серверу с использованием общедоступного IPv4-адреса. Статический NAT переводит общедоступный IPv4-адрес в частный.
При настройке статических трансляций NAT выполняются две основные задачи:
Создание сопоставления между внутренним локальным (inside local) адресом и внутренними глобальными (inside global) адресами. Например, внутренний локальный адрес 192.168.1.5 и внутренний глобальный адрес 208.165.100.5 на схеме настроены как статическая NAT трансляция.
После того как сопоставление настроено, интерфейсы, участвующие в трансляции должны быть настроены как внутренние (inside) и наружные (outside) относительно NAT. На схеме интерфейс маршрутизатора Serial 0/0/0 является внутренним, а Serial 0/1/0 – внешним.
Пакеты, поступающие на внутренний интерфейс маршрутизатора Serial 0/0/0 из настроенного внутреннего локального адреса IPv4 (192.168.1.5), транслируются и затем перенаправляются во внешнюю сеть. Пакеты, поступающие на внешний интерфейс Serial 0/1/0, адресованные настроенному внутреннему глобальному адресу IPv4 (208.165.100.5), переводятся на внутренний локальный адрес (192.168.1.5) и затем перенаправляются внутрь сети.
Настройка проходит в несколько шагов:
Создать статическую трансляцию между внутренним локальным и внешним глобальным адресами. Для этого используем команду ip nat inside source static [локальный _IP глобальный_IP]. Чтобы удалить трансляцию нужно ввести команду no ip nat inside source static. Если нам нужно сделать трансляцию не адреса в адрес, а адреса в адрес интерфейса, то используется команда ip nat inside source static [локальный _IP тип_интерфейса номер_интерфейса].
Определим внутренний интерфейс. Сначала зайти в режим конфигурации интерфейса, используя команду interface[тип номер] и ввести команду ip nat inside
Таким же образом определить внешний интерфейс, используя команду ip nat outside
Пример:
Router(config)# ip nat inside source static 192.168.1.5 208.165.100.5
Router(config)# interface serial0/0/0
Router(config-if)#ip nat inside
Router(config-if)#exit
Router(config)# interface serial0/1/0
Router(config-if)#ip nat outside
В результате трансляции будут проходить так:
Клиент хочет открыть соединение с веб-сервером. Клиент отправляет пакет на веб-сервер, используя общедоступный IPv4-адрес назначения 208.165.100.5. Это внутренний глобальный адрес веб-сервера.
Первый пакет, который роутер получает от клиента на внешнем интерфейсе NAT, заставляет его проверять свою таблицу NAT. Адрес IPv4 адресата находится в таблице NAT он транслируется.
Роутер заменяет внутренний глобальный адрес назначения 208.165.100.5 внутренним локальным 192.168.1.5 и пересылает пакет к веб-серверу.
Веб-сервер получает пакет и отвечает клиенту, используя внутренний локальный адрес источника 192.168.1.5.
Роутер получает пакет с веб-сервера на свой внутренний интерфейс NAT с адресом источника внутреннего локального адреса веб-сервера, 192.168.1.5. Он проверяет NAT таблицу для перевода внутреннего локального адреса во внутренний глобальный, меняет адрес источника с 192.168.1.5 на 208.165.100.5 и отправляет его из интерфейса Serial 0/1/0 в сторону клиента
Клиент получает пакет, и обмен пакетами продолжается. Роутер выполняет предыдущие шаги для каждого пакета.
Проверка статического NAT
Полезной командой для проверки работы NAT является команда show ip nat translations. Эта команда показывает активные трансляции NAT. Статические переводы, в отличие от динамических переводов, всегда находятся в таблице NAT.
Router#show ip nat translations
Pro Inside global Inside local Outside local Outside global
--- 208.165.100.5 192.168.1.5 208.165.100.70 208.165.100.70
Другой полезной командой является команда show ip nat statistics. Она отображает информацию об общем количестве активных переводов, параметрах конфигурации NAT, количестве адресов в пуле и количестве адресов, которые были выделены.
Router#show ip nat statistics
Total active translations: 1 (1 static, 0 dynamic; 0 extended)
Peak translations: 2, occurred 00:00:21 ago
Outside interfaces:
Serial0/1/0
Inside interfaces:
Serial0/0/0
Hits:7 Misses:0
Чтобы убедиться, что трансляция NAT работает, лучше всего очистить статистику из любых прошлых переводов, используя команду clear ip nat statistics перед тестированием.
Настройка динамического NAT (Dynamic NAT)
В то время пока статический NAT постоянное сопоставление между внутренним локальным и внутренним глобальным адресом, динамический NAT позволяет автоматически сопоставлять внутренние локальные и глобальные адреса (которые обычно являются публичными IP-адресами). Динамический NAT использует группу или пул публичных адресов IPv4 для перевода. Динамический NAT, как и статический NAT, требует настройки внутреннего и внешнего интерфейсов, участвующих в NAT.
Рассмотрим на примере этой схемы. Мы тут имеем внутреннюю сеть с двумя подсетями 192.168.1.0/24 и 192.168.2.0/24 и пограничным маршрутизатором, на котором настроен динамический NAT с пулом публичных адресов 208.165.100.5 - 208.165.100.15.
Пул публичных адресов (inside global address pool) доступен для любого устройства во внутренней сети по принципу «первым пришел – первым обслужили». С динамическим NAT один внутренний адрес преобразуется в один внешний адрес. При таком типе перевода должно быть достаточно адресов в пуле для одновременного предоставления для всех внутренних устройств, которым необходим доступ к внешней сети. Если все адреса в пуле были использованы, то устройство должно ждать доступного адреса, прежде чем оно сможет получить доступ к внешней сети.
Рассмотрим настойку по шагам:
Определить пул которые будут использоваться для перевода, используя команду ip nat pool [имя начальный_ip конечный_ip]. Этот пул адресов обычно представляет собой группу публичных общедоступных адресов. Адреса определяются указанием начального IP-адреса и конечного IP-адреса пула. Ключевые слова netmask или prefix-length указывают маску.
Нужно настроить стандартный access-list (ACL), чтобы определить только те адреса, которые будут транслироваться. Введем команду access-list [номер_ACL] permit source [wildcard_маска]. Про стандартные access-list’ы можно прочитать в этой статье (а про расширенные в этой). ACL который разрешает очень много адресов может привести к непредсказуемым результатам, поэтому в конце листа есть команда deny all.
Необходимо привязать ACL к пулу, и для этого используется команду ip nat inside source list [номер_ACL] number pool [название_пула]. Эта конфигурация используется маршрутизатором для определения того, какие устройства (список) получают адреса (пул).
Определить, какие интерфейсы находятся внутри, по отношению к NAT, то есть любой интерфейс, который подключен к внутренней сети.
Определить, какие интерфейсы находятся снаружи, по отношению к NAT, то есть любой интерфейс, который подключен к внешней сети.
Пример:
Router(config)# ip nat pool MerionNetworksPool 208.165.100.5 208.165.100.15 netmask 255.255.255.0
Router(config)# access-list 1 permit 192.168.0.0 0.0.255.255
Router(config)#ip nat inside source list 1 pool MerionNetworksPool
Router(config)# interface serial0/0/0
Router(config-if)#ip nat inside
Router(config-if)#exit
Router(config)# interface serial0/1/0
Router(config-if)#ip nat outside
Как это будет работать на нашей схеме:
Компьютеры с адресами 192.168.1.10 и 192.168.2.10 отправляют пакеты в сторону сервера по публичному адресу 208.165.100.70
Маршрутизатор принимает первый пакет от хоста 192.168.1.10. Поскольку этот пакет был получен на интерфейсе, сконфигурированном как внутренний интерфейс NAT, маршрутизатор проверяет конфигурацию NAT, чтобы определить, должен ли этот пакет быть транслирован. ACL разрешает этот пакет, и роутер проверяет свою таблицу NAT. Поскольку для этого IP-адреса нет записи трансляции, роутер определяет, что исходный адрес 192.168.1.10 должен быть переведен динамически. R2 выбирает доступный глобальный адрес из пула динамических адресов и создает запись перевода, 208.165.200.5. Исходный IPv4-адрес источника (192.168.1.10) является внутренним локальным адресом, а переведенный адрес является внутренним глобальным адресом (208.165.200.5) в таблице NAT. Для второго хоста 192.168.2.10 маршрутизатор повторяет эту процедуру, выбирая следующий доступный глобальный адрес из пула динамических адресов, создает вторую запись перевода - 208.165.200.6.
После замены внутреннего локального адреса источника в пакетах маршрутизатор перенаправляет пакет.
Сервер получает пакет от первого ПК и отвечает, используя адрес назначения 208.165.200.5. Когда сервер получает пакет от второго ПК, то в ответе в адресе назначения будет стоять 208.165.200.6.
Когда роутер получает с адресом назначения 208.165.200.5, то он выполняет поиск в таблице NAT и переводит адрес назначения во внутренний локальный адрес 192.168.1.10 и направляет в сторону ПК. То же самое происходит с пакетом, направленным ко второму ПК.
Оба ПК получают пакеты, и обмен пакетами продолжается. Для каждого следующего пакета выполняются предыдущие шаги.
Проверка динамического NAT
Для проверки также используется команда show ip nat отображает все статические переводы, которые были настроены, и любые динамические переводы, которые были созданы трафиком. Добавление ключевого слова verbose отображает дополнительную информацию о каждом переводе, включая то, как давно запись была создана и использовалась. По умолчанию данные о переводах истекают через 24 часа, если таймеры не были переконфигурированы с помощью команды ip nat translation timeout [время_в_секундах] в режиме глобальной конфигурации.
Чтобы очистить динамические записи до истечения времени ожидания, можно использовать команду clear ip nat translation. Полезно очищать динамические записи при тестировании конфигурации NAT. Эту команду можно использовать с ключевыми словами и переменными, чтобы контролировать, какие записи очищаются. Конкретные записи можно очистить, чтобы не прерывать активные сеансы. Только динамические переводы удаляются из таблицы. Статические переводы не могут быть удалены из таблицы.
Также можно использовать команду show ip nat statistics которая отображает информацию об общем количестве активных переводов, параметрах конфигурации NAT, количестве адресов в пуле и количестве переведенных адресов.
Поскольку у нас здесь используются листы контроля доступа ACL, то для их проверки можно использовать команду show access-lists.
Настройка Port Address Translation (PAT)
PAT (также называемый NAT overload) сохраняет адреса во внутреннем глобальном пуле адресов, позволяя маршрутизатору использовать один внутренний глобальный адрес для многих внутренних локальных адресов. Другими словами, один открытый IPv4-адрес может использоваться для сотен и даже тысяч внутренних частных IPv4-адресов. Когда несколько внутренних локальных адресов сопоставляются с одним внутренним глобальным адресом, номера портов TCP или UDP каждого внутреннего узла различают локальные адреса.
Общее количество внутренних адресов, которые могут быть переведены на один внешний адрес, теоретически может составлять 65 536 на каждый IP-адрес. Однако на практике число внутренних адресов, которым может быть назначен один IP-адрес, составляет около 4000.
Существует два способа настройки PAT, в зависимости от того, как провайдер выделяет общедоступные IPv4-адреса. В первом случае интернет-провайдер выделяет более одного публичного IPv4-адреса организации, а в другом он выделяет один общедоступный IPv4-адрес, который требуется для организации для подключения к интернет-провайдеру.
Настройка PAT для пула публичных IP-адресов
Если нам доступно более одного общедоступного IPv4-адреса, то эти адреса могут быть частью пула, который используется PAT. Это похоже на динамический NAT, за исключением того, что в этом случае недостаточно общих адресов для взаимного сопоставления внутренних адресов. Небольшой пул адресов распределяется между большим количеством устройств.
Основное различие между этой конфигурацией и конфигурацией для динамического NAT, заключается в том, что используется ключевое слово overload, которое включает PAT.
Рассмотрим настойку PAT для пула адресов по шагам:
Определить пул адресов глобальных адресов, которые будут использоваться для PAT трансляции, используя команду ip nat pool [имя начальный_ip конечный_ip] netmask [маска] | prefix-length [длина_префикса].
Создать стандартный access-list, разрешающий адреса, которые должны быть переведены. Используется команда access-list [номер_ACL] permit source [wildcard_маска].
Включим PAT, используя волшебное слово Overload. Вводим команду ip nat inside source list [номер_ACL] number pool [название_пула] overload.
Определяем, какие интерфейсы находятся внутри, по отношению к NAT, а какие снаружи. Используем команду ip nat inside и ip nat outside
Пример настройки для схемы, что использовалась ранее, только теперь мы будем использовать PAT:
Router(config)# ip nat pool MerionNetworksPool2 208.165.100.5 208.165.100.15 netmask 255.255.255.0
Router(config)# access-list 1 permit 192.168.0.0 0.0.255.255
Router(config)#ip nat inside source list 1 pool MerionNetworksPool2 overload
Router(config)# interface serial0/0/0
Router(config-if)#ip nat inside
Router(config-if)#exit
Router(config)# interface serial0/1/0
Router(config-if)#ip nat outside
Настройка PAT для одного публичного IPv4-адреса
На схеме показана топология реализации PAT для трансляции одного IP публичного адреса. В этом примере все хосты из сети 192.168.0.0/16 (соответствующие ACL), которые отправляют трафик через маршрутизатор, будут переведены на адрес IPv4 208.165.99.225 (адрес IPv4 интерфейса S0 /1/0). Трафик будет идентифицироваться по номерам портов в таблице NAT.
Настройка:
Создать лист access-list разрешающий адреса, которые нужно транслировать – access-list [номер_ACL] permit source [wildcard_маска].
Настроить преобразование адреса источника в адрес интерфейса, через команду ip nat inside source list [номер_ACL] interface [тип номер] overload
Определить внешние и внутренние интерфейсы через команды ip nat inside и ip nat outside.
Конфигурация похожа на динамический NAT, за исключением того, что вместо пула адресов мы используем адрес интерфейса с вешним IP адресом. NAT пул не определяется.
Пример:
Router(config)# access-list 1 permit 192.168.0.0 0.0.255.255
Router(config)# ip nat source list 1 interface serial0/1/0 overload
Router(config)# interface serial0/0/0
Router(config-if)#ip nat inside
Router(config-if)#exit
Router(config)# interface serial0/1/0
Router(config-if)#ip nat outside
Процесс PAT не изменятся при использовании одного адреса, или пула адресов.
Рассмотрим процесс PAT по шагам:
На схеме два разных ПК связываются с двумя разными веб-серверами. Первый ПК имеет адрес источника 192.168.1.10 и использует TCP порт 1444, а второй ПК имеет адрес источника 192.168.2.10 и по совпадению использует то же TCP порт 1444
Пакет с первого ПК сначала достигает роутера и он, используя PAT, изменяет исходный IPv4-адрес на 208.165.99.225 (inside global address). В таблице NAT нет других устройств с портом 1444, поэтому PAT использует тот же номер порта и пакет отправляется в направлении сервера по 208.165.101.20.
Далее пакет со второго компьютера поступает в маршрутизатор, где PAT настроен на использование одного глобального IPv4-адреса для всех переводов - 208.165.99.225. Подобно процессу перевода для первого ПК, PAT изменяет исходящий адрес второго ПК на внутренний глобальный адрес 208.165.99.225. Однако второй ПК имеет тот же номер порта источника, что и текущая запись PAT первого ПК, поэтому PAT увеличивает номер порта источника до тех пор, пока он не станет уникальным в своей таблице. В этом случае запись исходного порта в таблице NAT и пакет для второго ПК получает 1445 порт. Хотя оба ПК используют один и тот же внутренний глобальный адрес 208.165.99.225 и тот же номер порта источника – 1444, измененный номер порта для второго ПК (1445) делает каждую запись в таблице NAT уникальной. Это станет очевидным при отправке пакетов с серверов обратно клиентам.
Сервера отвечают на запросы от компьютеров, и используют исходный порт из принятого пакета в качестве порта назначения и исходный адрес как адрес назначения. Может казаться, что они общаются одним и тем же хостом по адресу 208.165.99.225, однако, это не так – они имеют разные порты.
Когда пакеты возвращаются на роутер, он находит уникальную запись в своей таблице NAT с использованием адреса назначения и порта назначения каждого пакета. В случае пакета от первого сервера адрес назначения 208.165.99.255 имеет несколько записей, но только одну с портом назначения 1444. Используя эту запись в своей таблице, роутер изменяет адрес IPv4 адресата пакета на 192.168.1.10, не меняя порт назначения. Затем пакет перенаправляется на первый ПК
Когда пакет от второго сервера прилетает на маршрутизатор, он выполняет аналогичный перевод. Адрес IPv4 назначения 208.165.99.225 имеет несколько записей, однако используя порт назначения 1445, роутер может однозначно идентифицировать запись трансляции. Адрес IPv4 назначения будет изменен на 192.168.2.10 и в этом случае порт назначения также должен быть изменен до исходного значения 1444, которое хранится в таблице NAT. После этого пакет высылается на второй ПК
Проверка Port Address Translation (PAT)
Для проверки PAT используются такие же команды, что и для обычного NAT. Команда show ip nat translations отображает переводы IP адресов вместе с портами и команда show ip nat statistics показывает информацию о количестве и типе активных переводов, параметрах конфигурации NAT, количестве адресов в пуле и количестве выделенных адресов.
Router#show ip nat statistics
Total active translations: 2 (0 static, 2 dynamic; 2 extended)
Peak translations: 2, occurred 00:00:07 ago
Outside interfaces:
Serial0/1/0
Inside interfaces:
Serial0/0/0
Hits:4 Misses:0
CEF Translated packets: 4, CEF Punted packets:0
Expired translations: 0
Dynamic mappings:
-- Inside Source
[Id: 3] access-list 1 pool MerionNetworksPool2 refcount 2
pool MerionNetworksPool2: netmask 255.255.255.0
start 208.165.100.5 end 208.165.100.15
type generic, total addressers 10, allocated 1(10%),
misses 0
Total doors: 0
Appl doors: 0
Normal doors: 0
Queued Packets: 0
Также для поиска проблем можно использовать дебаг, который запускается командой debug ip nat, который отображает информацию о каждом пакете, который транслируется маршрутизатором. Также можно использовать команду debug ip nat detailed, которая генерирует описание каждого пакета. Эта команда также предоставляет информацию о различных ошибках, например, таких как неспособность выделить глобальный адрес. Однако эта команда более требовательна к ресурсам устройства.
Router#debug ip nat
IP NAT debugging is on
Router#
*Aug 24 16:20:331:670: NAT*: s=192.168.1.10->208.165.99.225 d=208.165.101.20 [3730]
*Aug 24 16:20:331:682: NAT*: s=208.165.101.20 d=208.165.99.225 ->192.168.1.10 [4156]
*Aug 24 16:20:331:698: NAT*: s=192.168.1.10->208.165.99.225 d=208.165.101.20 [3731]
*Aug 24 16:20:331:702: NAT*: s=192.168.1.10->208.165.99.225 d=208.165.101.20 [3732]
*Aug 24 16:20:331:710: NAT*: s=208.165.101.20 d=208.165.99.225 ->192.168.1.10 [4157]
В выводе используются следующие символы и значения:
* (звездочка) – звездочка с NAT указывает, что перевод происходит по пути с быстрым переключением (fast-switched path). Первый пакет в разговоре всегда медленнее, остальные пакеты проходят путь с быстрым переключением.
s= - IP адрес источника
a.b.c.d ? w.x.y.z - это значение указывает, что адрес источника a.b.c.d переводится на w.x.y.z.
d= - IP адрес назначения
[xxxx] - значение в скобках - это идентификационный номер IP.