Subnets.ru blog

В этой статье мы рассмотрим концепцию статических маршрутов. Для этого мы будем использовать заведомо проблемный сценарий для демонстрации условий, при которых желательно указывать интерфейс через который достижим адрес следующего хопа (Next Hop Address), когда вы конфигурируете статический маршрут.

Введние в статичскую маршрутизацию

Статический маршруты используются по ряду причин и чаще всего, когда не существует динамического маршрута к определенному месту назначения или когда включение динамического протокола маршрутизации не выполнимо. По умолчанию статические маршруты имеют административную дистанцию равную 1, что дает им преимущество над маршрутами изученными из динамических протоколов маршрутизации. Что такое административная дистанция и как она влияет на выбор маршрута, читайте в статье “Административная Дистанция”, опубликованной ранее на CicsoLab.RU.

Когда вы увеличиваете административную дистанцию в значение большем чем значение динамического протокола маршрутизации, статический маршрут будет работать только в случае, когда пропадет динамическая маршрутизация. Например, маршруты изученные из динамического протокола IGRP имеют административную дистанцию по умолчанию 100. Для того, чтобы конфигурировать статический маршрут, который будет перекрыт IGRP маршрутом, укажите административную дистанцию больше 100. Такой вид статической маршрутизации называется “плавающей”. Такой маршрут инсталлируется в таблицу маршрутизации только, когда более предпочтительный маршрут исчезнет оттуда. Например,

ip route 172.31.10.0 255.255.255.0 10.10.10.2 101

Обратите внимание, что административная дистанция 255, рассматривается как недостижимая и статический маршрут с административной дистанцией 255 никогда не будет введен в таблицу маршрутизации.

Если вы указали статический маршрут на броадкастовый интерфейс, маршрут вставляется в таблицу маршрутизации только когда этот броадкастовый интерфейс поднят. Такая конфигурация не рекомендуется потому что следующий хоп статического маршрута указывает на интерфейс, маршрутизатор думает, что каждый из хостов в диапазоне данного маршрута напрямую подсоединены к этому интерфейсу. Например,

ip route 0.0.0.0 0.0.0.0 Ethernet0

В такой конфигурации маршрутизатор выполняет ARP запросы на интерфейсе Ethernet0 для каждого узла, который попадает в маршрут по умолчанию, потому что маршрутизатор рассматривает все эти узлы как напрямую подсоединенные к этому интерфейсу.

Такой вид маршрута по умолчанию, особенное если он используется большим количеством пакетов ко многим разным сетям может привести к большой нагрузке на CPU и огромному ARP кэшу и даже к исчерпании свободной памяти на этот самый кэш.

Указание числового следующего хопа (next hop) для маршрута, предотвратит выполнение ARP запросов на каждый адрес. Однако, если интерфейс за которым лежит next hop упадет, а числовое значение следующего хопа достижимо через рекурсивный маршрут, вы должный указать и IP адрес следующего хопа и интерфейс через который данный next hop может быть найден. Например,

ip route 0.0.0.0 0.0.0.0 Serial 3/3 192.168.20.1

Проблема

Теперь рассмотрим небольшой проблемный сценарий. В данной сетевой диаграмме, существует два статических маршрута к одному и тому же месту назначения (172.31.10.0/24). Один маршрут является “плавающим” маршрутом. Это резервный путь к целевой сети. Проблема в данном сценарии в том, что плавающий маршрут никогда не инсталлируется не таблицу маршрутизации, когда основной канал падает.

Рис.1

Большинство протоколов маршрутизации имеют структуры метрик и алгоритмы, которые не совместимы с другими протоколами. В сетях с множеством протоколов маршрутизации, обмен маршрутной информацией и способностью выбрать наилучший путь для пакетов данных является критически важным моментом.

Для того чтобы выбрать наилучший путь, когда существует два или более различных маршрутов к одной и той же конечной точке от двух различных протоколов маршрутизации, роутеры используют функцию, которая называется административной дистанцией

Выбираем наилучший путь

Административная дистанция это первый критерий который использует маршрутизатор, чтобы определить какой протокол маршрутизации использовать если два протокола предоставляют маршрутную информацию к одному и тому же месту назначения. Административная дистанция это мера доверия или надежности к источнику маршрутной информации. Административная дистанция имеет только местное значение и не вещается в маршрутных обновлениях (routing updates).

Чем меньше численное значение административной дистанции, тем более надежен протокол. Например, если роутер принимает маршрут к определенной сети и через OSPF и через IGRP, маршрутизатор выберет протокол IGRP, поскольку IGRP более надежен. Это значит, что маршрутизатор добавит в свою роутинговую таблицу маршрут от протокола IGRP.

Если вдруг, вы потеряли источник IGRP информации (например, выключили питание на нем), роутер будет использовать информацию поставляемую протоколом OSPF, до тех пор пока источник IGRP маршрутов не возобновит свою работу.

Таблица значений административной дистанции

Ниже представлена таблица, где показаны численные значения административной дистанции для различных протоколов маршрутизации, используемые по умолчанию.

Если административная дистанция равна 255, роутер не доверяет источнику маршрута и никогда не инсталлирует такой маршрут в таблицу маршрутизации.

Вы можете изменить административную дистанцию для определенных маршрутов. Например, вы хотите использовать статические маршруты как резервные к динамическому протоколу маршрутизации. Это обычно используется для поднятия резервного канала, когда основной канал падает. Это называется плавающая статическая маршрутизация.

ip route 10.0.0.0 255.0.0.0 Dialer 1 250

Здесь административная дистанция для маршурута 10.0.0.0/8 установлена в значение 250.

Таблица маршрутизации может выглядеть следующий образом

R1#show ip route

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 1 subnets
C 172.16.1.0 is directly connected, Ethernet0
R 10.0.0.0/8 [120/1] via 172.16.1.200, 00:00:16, Ethernet0
C 192.168.1.0/24 is directly connected, Loopback0

Если интерфейс Ethernet0 упадет, то в таблицу маршрутизации инсталлируется плавающий статический маршрут и весь трафик предназначенный для сети 10.0.0.0/8 будет маршрутизироваться через интерфейс Dialer 1 и по резервному каналу.

R1#show ip route
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.1.0 is directly connected, Ethernet0
S 10.0.0.0/8 is directly connected, Dialer1
C 192.168.1.0/24 is directly connected, Loopback0

Как только Ethernet интерфейс подниматься обратно, то в таблицу сразу же инсталлируется маршрут от динамического протокола RIP и трафик снова пойдет через Ethernet 0.

По материалам: cisco.com

Оригинал статьи тут

Натолкнулся на просторах интернета, хорошая статья, решил скопировать.

Автор: Ильяс Кулиев

NAT, поистине, спасение для системного администратора, когда нужно быстро подключить к Интернету локальную сеть. Но все ли вы о нём знаете?

NAT и его реализации

Используя терминологию Cisco, в контексте NAT есть четыре основных определения для IP-адресов. Рассмотрим их на примере, показанном на рис. 1. На обоих маршрутизаторах делается NAT (network address translation).

Рисунок 1. Определение IP-адресов в контексте NAT

При этом:

• Inside Local (IL). Это адрес, присвоенный хосту, находящемуся в локальной сети. В данном случае адреса 10.0.0.100 и 172.16.0.100 – адреса IL.
• Inside Global (IG). Это внешний адрес, при отправлении пакетов на который они будут доставлены на хост с адресом IL. В данном случае для хоста 10.0.0.100 адресом IG является 111.222.0.1.
• Outside Global (OG). Внешний адрес хоста, доступ к которому мы хотим получить из нашей локальной сети. В данном случае, если мы отправляем пакет от 10.0.0.100 для 172.16.0.100, адресом OG будет 111.222.0.2.
• Outside Local (OL). Это адрес, под которым адреса внешних хостов видны внутри локальной сети. В данном случае, если мы отправляем пакет от 10.0.0.100 для 172.16.0.100, для хоста 172.16.0.100 это будет выглядеть так, будто пакет пришёл от 172.16.0.1 (адрес OL).

Простейший случай NAT – это трансляция адресов IL в IG и наоборот. При этом маршрутизатор, выполняющий NAT, модифицирует поле адреса в заголовке IP следующим образом:

• в исходящих пакетах адрес источника IL заменяется на IG, и пакет отправляется дальше по роутингу к хосту с адресом OG;
• во входящих пакетах адрес приемника IG заменяется на IL и отправляется в локальную сеть для хоста с адресом IL.

Таким образом, в таблице сопоставлений NAT каждая запись состоит из двух значений – IL и IG.

Эта или подобная схема иногда применяется для обеспечения доступа снаружи к хостам, находящимся в локальной сети (например, к веб-серверу или FTP-серверу). Она может также применяться для балансировки нагрузки путем динамического распределения пакетов, приходящих на публичный адрес маршрутизатора, между несколькими серверами, находящимися в локальной сети, и еще в некоторых случаях.

Более распространённый случай – это NPAT, network and port address translation. При использовании NPAT в таблице сопоставлений каждая запись имеет не два (как в простом NAT), а пять значений:

1. транспортный протокол;
2. локальный адрес (IL);
3. локальный порт;
4. глобальный адрес (IG);
5. глобальный порт.

Это позволяет использовать единственный публичный адрес для предоставления доступа в Интернет компьютерам, находящимся в локальной сети. В документации Cisco такая схема обычно называется «NAT with port overload» или короче – «NAT overload».

Исторически сложилось так, что именно его, как правило, имеют в виду, когда употребляют термин «NAT», и о нём мы и будем говорить в дальнейшем, ввиду его распространённости.

До сих пор речь шла о вещах общеизвестных. Однако, если посмотреть на NAT поближе, возникают новые вопросы. Возьмём простейшую сеть, с одним компьютером и одним маршрутизатором, выполняющим NAT. Модель маршрутизатора в данном случае не слишком важна – допустим, что это давно устаревшая, но все еще популярная Cisco 1601R (см. рис. 2).

Рисунок 2. Пример сети с NAT

В конфигурации маршрутизатора указано, что он должен выполнять NAT для всех пакетов, с адресами источника 192.168.0.0/24, пришедших через интерфейс Ethernet0 и отправляемых далее через интерфейс Serial0, а также для ответных пакетов, пришедших через Serial0, для которых есть соответствующая запись в таблице трансляций:

!
! Last configuration change at 09:29:45 UTC someday by TheAllmightyMaster
! NVRAM config last updated at 19:27:46 UTC some other day by TheAllmightyMaster
!
version 12.2
…
interface Serial0
ip address 11.22.33.44 255.255.255.252
ip nat outside
…
interface Ethernet0
ip address 192.168.0.1 255.255.255.0
ip nat inside
…
ip nat inside source list MyNetwork interface Serial0 overload
…
ip access-list extended MyNetwork
permit ip 192.168.0.0 0.0.0.255 any

Предположим, компьютер с адресом IL 192.168.0.141 отправляет DNS-запрос на внешний хост 1.2.3.4 (порт 53, протокол UDP). Как следует из конфигурации, наш внешний адрес IG – 11.22.33.44.

В результате этого в таблице NAT появится примерно такая запись:

Proto Inside global Inside local Outside local Outside global
UDP 11.22.33.44:1053 192.168.0.141:1053 1.2.3.4:53 1.2.3.4:53

Допустим, после появления такой записи в таблице, другой хост, 1.2.3.5, отправляет пакет UDP с адресом назначения 11.22.33.44 и портом назначения 1053. Вопрос – получит ли наш хост 192.168.0.141 этот пакет?

Здравый смысл подсказывает, что вроде бы не должен. С другой стороны, налицо факт: в нашей таблице NAT черным по белому записано, что пакет с адресом назначения 11.22.33.44 и портом назначения 1053 нужно принять и транслировать в локальную сеть для хоста 192.168.0.141 (который его примет и молча уничтожит, поскольку на этом компьютере не запущено сетевого приложения, которому был бы предназначен этот пакет.)

Кстати говоря – ну хорошо, допустим такого приложения нет, а если бы оно было? Как хорошо известно пользователям таких программ, как eMule и eDonkey, они требуют, чтобы им была предоставлена возможность беспрепятственно получать UDP пакеты с портом назначения 4661, или 4242, или 4321 – точный номер порта зависит от настроек. И, что также хорошо известно их пользователям, эти программы плохо работают, будучи запущены из локальной сети, находящейся за NAT. Так вот, это может происходить, в том числе и потому, что несмотря на успешное установление локальным клиентом соединения с сервером, из-за специфики данной конкретной реализации NAT другие клиенты, находящиеся во внешнем мире, не могут устанавливать соединение с локальным клиентом.

По этой же причине может не работать DCC chat в клиентах IRC, передача файлов в ICQ и тому подобные вещи, для которых требуется обеспечение беспрепятственного прохождения пакетов непосредственно между пользовательскими компьютерами.

Итак, отвечая на вопрос, «получит ли наш хост 192.168.0.141 пакет, направленный на 11.22.33.44 от постороннего хоста», – может быть, получит, а может быть, и нет; ответ на этот вопрос зависит от реализации NAT на пограничном маршрутизаторе.

Реализаций же насчитывается четыре:

1. Symmetric NAT. До недавнего времени это была наиболее распространённая реализация. Его характерная особенность – в таблице NAT маппинг адреса IL на адрес IG жёстко привязан к адресу OG, то есть к адресу назначения, который был указан в исходящем пакете, инициировавшем этот маппинг. При указанной реализации NAT в нашем примере хост 192.168.0.141 получит оттранслированные входящие UDP-пакеты только от хоста 1.2.3.4 и строго с портом источника 53 и портом назначения 1053 – ни от кого более. Пакеты от других хостов, даже если указанные в пакете адрес назначения и порт назначения присутствуют в таблице NAT, будут уничтожаться маршрутизатором. Это наиболее параноидальная реализация NAT, обеспечивающая более высокую безопасность для хостов локальной сети, но в некоторых случаях сильно усложняющая жизнь системных администраторов. Да и пользователей тоже.
2. Full Cone NAT. Эта реализация NAT – полная противоположность предыдущей. При Full Cone NAT входящие пакеты от любого внешнего хоста будут оттранслированы и переправлены соответствующему хосту в локальной сети, если в таблице NAT присутствует соответствующая запись. Более того, номер порта источника в этом случае тоже не имеет значения – он может быть и 53, и 54, и вообще каким угодно. Например, если некое приложение, запущенное на компьютере в локальной сети, инициировало получение пакетов UDP от внешнего хоста 1.2.3.4 на локальный порт 4444, то пакеты UDP для этого приложения смогут слать также и 1.2.3.5, и 1.2.3.6, и вообще все до тех пор, пока запись в таблице NAT не будет по какой-либо причине удалена. Ещё раз: в этой реализации NAT во входящих пакетах проверяется только транспортный протокол, адрес назначения и порт назначения, адрес и порт источника значения не имеют.
3. Address Restricted Cone NAT (он же Restricted NAT). Эта реализация занимает промежуточное положение между Symmetric и Full Cone реализациями NAT – маршрутизатор будет транслировать входящие пакеты только с определенного адреса источника (в нашем случае 1.2.3.4), но номер порта источника при этом может быть любым.
4. Port Restricted Cone NAT (или Port Restricted NAT). То же, что и Address Restricted Cone NAT, но в этом случае маршрутизатор обращает внимание на соответствие номера порта источника и не обращает внимания на адрес источника. В нашем примере маршрутизатор будет транслировать входящие пакеты с любым адресом источника, но порт источника при этом обязан быть 53, в противном случае пакет будет уничтожен маршрутизатором.

Как видим, реализации NAT – это настоящий зоопарк, в котором каждой твари по паре. Положение смягчается тем, что для большинства сетевых приложений подробности реализации NAT большого значения не имеют (в особенности для приложений, использующих транспорт TCP, как известно, это протокол, использующий сессии, поэтому сказанное выше для TCP неактуально. Тем не менее с развитием приложений Peer-to-Peer (eDonkey, eMule, Skype), IPтелефонии и разнообразной сетевой мультимедии (зачастую использующих транспорт на основе UDP) различия в реализациях NAT постепенно начинают играть заметную роль. Поэтому для разработчиков таких приложений пришла пора задуматься над тем, как их детище будет работать, находясь в локальной сети за NATом. Одним из плодов таких раздумий стал протокол STUN (Simple Traversal of UDP through NAT), описанный в RFC 3489.

STUN

Некоторым приложениям, особенно предназначенным для IP-телефонии (поскольку там это наиболее актуально), важно знать, находится ли компьютер, на котором они запущены, в локальной сети за NAT или на компьютере с публичным IP адресом, и в случае NAT – определить, какого он типа. Для этого в настоящее время широко используется протокол STUN, который позволяет также определить наличие блокирующего firewall на пограничном маршрутизаторе или самом компьютере.

Идея STUN несложна – клиент отправляет на находящийся снаружи сервер зондирующие сообщения, используя транспорт UDP. В теле этих сообщений содержатся IPадреса и номера портов источника и приемника. Непременным условием работы сервера является использование им двух IP-адресов – дальше станет понятно, для чего.

Процесс определения типа NAT с использованием STUN протекает следующим образом. Допустим, наш клиент находится за NAT, его локальный адрес 192.168.0.111, публичный адрес NAT – 1.2.3.4, адреса сервера STUN – 11.22.33.1 и 11.22.33.2, номера портов 3478.

Происходит следующее:

1. Клиент отправляет запрос на основной адрес сервера (11.22.33.1), при этом в теле отправленного запроса указаны адреса и порты: 192.168.0.111:1055 -> 11.22.33.1:3478. Эти же адреса и порты фигурируют в заголовке IP-пакета, содержащего запрос, но после прохождения NAT адрес источника изменится на 1.2.3.4, а номер порта в зависимости от реализации NAT может измениться или остаться неизменным. Если клиент не получает никакого ответа в течение тайм-аута, он делает вывод, что находится за блокирующим firewall, и завершает работу.
2. Сервер отвечает клиенту со своего адреса 11.22.33.1 сообщением, в теле которого также указаны адреса и порты: 11.22.33.1:3478 -> 1.2.3.4:1055. Если бы адрес, с которого клиент отправлял своё первое сообщение (192.168.0.111), и адрес в полученном от сервера сообщении (1.2.3.4) совпали, клиент сделал бы вывод, что на пути пакетов NAT отсутствует. В этом случае клиент и сервер обменялись бы еще парой запросов-ответов, на основании которых можно было бы определить, не находится ли по пути между ними firewall, блокирующий входящие пакеты UDP. Поскольку они не совпадают, очевидно, что на пути между клиентом и сервером находится NAT. В этом же сообщении сервер информирует клиента о своем альтернативном IP-адресе (11.22.33.2) и номере порта (3478).
3. После этого клиент отправляет второе зондирующее сообщение, в котором установлен специальный флажок, указывающий серверу, что клиент ожидает ответа с альтернативного IP-адреса сервера (11.22.33.2), и с другим номером порта источника. Если клиент получает ответ на этот запрос, делается вывод, что находящийся по пути между ними NAT относится к Full Cone типу.
4. Если ответ на предыдущий запрос не был получен, клиент повторяет свое первое зондирующее сообщение на альтернативный адрес STUN сервера. Если в полученном ответе адрес и номер порта отличаются от указанных в первом ответе, это означает, что этот запрос инициировал появление в таблице NAT новой записи. Такое поведение характерно исключительно для Symmetric NAT.
5. Если адрес и номер порта в полученном ответе остались такими же, какими они были в первом ответе, то NAT относится к типу Restricted Cone. Осталось установить, является ли он Address Restricted или Port Restricted. Для этого клиент отсылает четвертое сообщение, в котором установлен флажок, указывающий серверу, что он должен ответить, используя порт источника с другим номером. Если ответ был получен, NAT относится к Address Restricted Cone, если нет – то к Port Restricted Cone.

Для иллюстрации работы STUN см. рис. 3 (взят из статьи «Anatomy: A Look Inside Network Address Translators» в «The IP Journal» Vol.7 Num. 2 за сентябрь 2004 г.).

Рисунок 3. Алгоритм работы STUN

Клиент STUN встроен в некоторые приложения IP-телефонии, например, X-Pro и X-Lite от компании CounterPath, и в некоторые другие. Консольный клиент STUN под ОС Windows может быть загружен отсюда: http://prdownloads.sourceforge.net/stun/client.exe?download.

Запустив его и указав в качестве параметра командной строки один из публичных STUN-серверов, вы узнаете тип вашего NAT:

C:\>client.exe stun.xten.com
STUN client version 0.94
…
Primary: Full Cone Nat, random port, no hairpin
Return value is 0x9

Приведённый выше результат получен на компьютере, находящемся за маршрутизатором ZyXEL Prestige 645R.

Результат для маршрутизатора Cisco 1721 с IOS версии 12.2 в свою очередь выглядит так:

C:\>client.exe stun.xten.net
STUN client version 0.94
…
Primary: Port Restricted Nat, preserves ports, no hairpin
Return value is 0x1b

Такой же результат получен для маршрутизатора, построенного на основе FreeBSD 4.9, на которой NAT выполнялась демоном natd.

Осталось объяснить, что такое «random port», «preserves ports» и «no hairpin» в приведенных выше результатах.

Посмотрим еще раз на строчку из таблицы NAT в нашем примере:

Proto Inside global Inside local Outside local Outside global
UDP 11.22.33.44:1053 192.168.0.141:1053 1.2.3.4:53 1.2.3.4:53

«Random port» означает, что данная реализация NAT не заботится о том, чтобы номер порта источника в исходящем наружу пакете оставался таким же, каким он был получен от хоста локальной сети, и заменяет его на случайное значение в диапазоне от 1024 до 65535. Можно предположить, что по замыслу автора идеи «random ports» такая замена уменьшает вероятность конфликта между записями, если несколько хостов локальной сети одновременно попытаются отправить наружу пакеты с совпадающим номером порта источника. Поскольку номер порта источника в исходящих пакетах формируется хостами локальной сети также случайным образом, преимущества такой замены сомнительны, из недостатков же можно назвать хотя бы потенциальную проблему с протоколом RPC, да и не только.

Как видно из примера, наш маршрутизатор старается сохранять номер порта неизменным (11.22.33.44:1053 и 192.168.0.141:1053), из чего следует, что запущенный в его локальной сети STUN-клиент сообщил бы о нем «preserves ports». К слову, на FreeBSD этот результат достигается ключом «-same_ports» или «-s» в строчке запуска или конфигурационном файле демона natd.

«Hairpin» же означает следующее. Допустим, при наличии в таблице NAT приведенной выше строчки другой хост нашей локальной сети (например, 192.168.0.241) отправляет UDP-пакет с адресом назначения 11.22.33.44, портом назначения 1053 и портом источника 53. Что произойдет в результате?

Ответ на этот вопрос зависит от того, поддерживает маршрутизатор функцию «hairpin» или не поддерживает. Если он ее поддерживает, пакет будет обычным образом обработан и (если на маршрутизаторе используется реализация NAT Full Cone или Port Restricted) попадет по назначению – на хост 192.168.0.141. Если же нет («no hairpin»), пакет будет уничтожен маршрутизатором. Название функции «hairpin» (шпилька для волос) произошло от того, что, если изобразить прохождение такого пакета на рисунке, форма его траектории будет похожа на U-образную шпильку. Другое объяснение – слово «hairpin» переводится так же, как «разворот на 180 градусов». При поддержке маршрутизатором функции «hairpin» подпадающие под ее действие пакеты, действительно, будут развернуты на 180 градусов и отправлены обратно в локальную сеть.

NAT и шлюзы приложений

К сожалению, не у всех сетевых протоколов взаимодействие с NAT протекает безболезненно. Наиболее часто встречающийся пример – это FTP. Здесь возможны два случая.

Первый случай. Пользователь, находящийся в локальной сети за NAT, использует FTP-клиент для того, чтобы получить доступ к FTP-серверу с публичным IP-адресом (см. рис. 4).

Рисунок 4. Пример FTP-сессии

Проблема здесь возникает, когда клиент пытается использовать активный режим FTP. Сессия протекает при этом следующим образом. В некоторый момент по управляющему соединению серверу передается команда FTP-клиента: PORT 192,16,0,101,4,211.

Дальнейший диалог выглядит примерно так:

Server: 200 PORT command successful. Consider using PASV.
Client: RETR file.zip
Server: 150 Opening BINARY mode data connection for file.zip (1334109 bytes).

Наибольший интерес здесь представляет первая команда от клиента, которая информирует сервер о том, что хост с адресом 192.168.0.101 открыл для приема соединения данных порт номер (4*256) + 211 = 1235. В ответ на это сервер должен установить соединение данных со своего порта номер 20 на указанный порт хоста 192.168.0.101. Поскольку этот адрес является приватным, такое соединение не может быть установлено. В результате наблюдается знакомый многим системным администраторам эффект, когда клиент вроде бы успешно подключается к FTP-серверу, но не может скачивать с него файлы или даже просматривать содержимое текущего каталога (это происходит потому, что передача листинга файлов с сервера на клиент также осуществляется по соединению данных).

Для борьбы с описанной проблемой может использоваться переключение сервера в так называемый пассивный режим. Поскольку в этом режиме инициатором соединения данных выступает клиент, проблема исчезает. Именно поэтому в Microsoft Internet Explorer, как и консольный FTP-клиент, встроенный в Windows, используют по умолчанию пассивный режим (они автоматически вставляют перед командами RETR и NLST команду PASV, переключающую сервер в пассивный режим).

Второй случай. Пользователь, находящийся в локальной сети за NAT, использует FTP-клиент для того, чтобы получить доступ к FTP-серверу, который также находится за NAT. В этом случае, очевидно, не поможет и пассивный режим, так как в команде PORT независимо от того, клиент или сервер ее отдает, всегда будет указан приватный IP-адрес, и соединение данных никогда не будет установлено.

Для разрешения этой проблемы в некоторых реализациях NAT существует специальная функция – трансляция адресов на уровне приложений, называемая также NAT ALG (Application Level Gateways). При задействованной функции ALG маршрутизатор отслеживает и модифицирует данные уровня приложений некоторых сетевых протоколов.

Так, в приведенном выше примере, если предположить, что публичный IP-адрес маршрутизатора с NAT 1.2.3.4 и что он сохраняет номер порта источника неизменным, команда PORT 192,16,0,101,4,211 была бы изменена маршрутизатором на PORT 1,2,3,4,4,211. Благодаря этому в обоих указанных выше случаях соединение данных будет успешно установлено.

Функция ALG в маршрутизаторах Cisco позволяет осуществлять трансляцию адресов уровня приложений не только для протокола FTP, но также и для протоколов SIP, H.323, Skinny и некоторых других (благодаря этому можно, например, размещать в локальной сети серверы DNS). Для большего удобства функция ALG в маршрутизаторах Cisco включена по умолчанию.

Аналогичную ALG функциональность в маршрутизаторах на основе ОС Linux обеспечивают дополнительные загружаемые модули и патчи к ядру (такие, как ip_masq_ftp, ip_masq_irc и т. п.).

Заключение

Понимание принципов работы различных реализаций NAT может оказаться полезным при поиске причины неудовлетворительной работы некоторых приложений, использующих транспортный протокол UDP. Так, например, сочетание ALG и Symmetric или Port Restricted NAT и IP-телефонов, использующих протокол установки соедиенения SIP, может порой давать самые причудливые результаты (спорадические отказы в регистрации на сервере, односторонняя слышимость между абонентами и т. п.), причем это зависит не только от настроек IP-телефона, но и от настроек сервера. Другой пример: компания Microsoft сообщает в своей статье KB817778, что их реализация туннеля IPv6 over UDP не будет работать через Symmetric NAT (адрес статьи в Интернете: http://support.microsoft.com/kb/817778/EN-US). Таких примеров можно найти ещё много, и во всех случаях понимание различий в реализациях NAT если и не поможет немедленно устранить проблему, то хотя бы укажет на возможные пути решения (например, заменить firmware маршрутизатора на такое, где NAT реализован в виде Full Cone, если, конечно, оно существует, или заменить сам маршрутизатор).

Оригинал статьи

Описание задачи

Снимать статистику с интерфейсов посредством netflow и отправлять на биллинговый сервер.

Решение

На IOS 12.3 и выше ( в моем случае это был 12.4Т) по рекомендации cisco, ip flow настраивается следующим образом:

1. Включаем cef (Cisco Express Forwarding)

configure terminal
ip cef

2. описываем кол-во записей

ip flow-cache entries 40960

3. выставляем тайм ауты

ip flow-cache timeout inactive 130
ip flow-cache timeout active 20

4. указываем интерфейс

ip flow-export source INTERFACE

где INTERFACE это интерфейс с которого будет отправляться flow

5. версия

ip flow-export version 5

6. куда отправляем

ip flow-export destination IP-адрес Порт

собственно на этом «описательная» часть закончилась …

теперь настраиваем сами интерфейсы …

на физических интерфейсах обязательно включаем (fa 0/1 например):

configure terminal
interface fa 0/1
ip route-cache flow

и все больше на них ничего быть не должно (если на них нет ip-адресов)

все остальный телодвижения проделываем только на subinterfaces

включаем на сабах (fa 0/1.1 например):

configure terminal
interface fa 0/1.1
ip flow ingress
ip flow egress

ingress — для входящего трафика
egress — для исходящего трафика

Собственно все. Только заработает все выше описанное после ребута cisco.

ЗЫ: Не наступите на мои грабли и сразу продумайте откуда Вы хотите снимать статистику. В моем случае я не снимаю статистику с uplink , только с саб интерфейсов, на/через которые подключены абоненты. Иначе трафик будет считаться несколько раз.

Что можно посмотреть:

show ip cache flow — показывает записи флоу на cisco
show ip cache ver flow — тоже самое расширено
show ip flow int — показывает интерфейсы, на которых настроено флоу
show ip flow export — показывает, откуда и куда настроен экспорт флоу, сколько отправлено датаграмм и сколько ошибок

Прием netflow

Обычно биллинговый сервер идет уже в комплекте с коллектором для netflow.

Можно как вариант использовать пакет flow-tools ( для FreeBSD — в портах: net-mgmt/flow-tools ). Настройка этого пакета подробно рассмотрена на http://opennet.ru, поэтому здесь он будет описан бегло.

Для flow-tools особых настроек я не делал просто прописал стартовый скрипт типа:

/usr/local/bin/flow-capture -p /var/run/flow-capture.pid -n 0 -N 2 -w /var/netflow -S 60 localip/rempteip/port

Рассмотрим опции:

-p pid файл (можно не писать)

-n кол-во ротаций файла с флоу в день я поставил 0 чтобы за сутки был один файл (просто мне так удобнее)

-N формат имени файла с флоу, где далее указывается:

• -3 YYYY/YYYY-MM/YYYY-MM-DD/flow-file
• -2 YYYY-MM/YYYY-MM-DD/flow-file
• -1 YYYY-MM-DD/flow-file
• 0 flow-file
• 1 YYYY/flow-file
• 2 YYYY/YYYY-MM/flow-file
• 3 YYYY/YYYY-MM/YYYY-MM-DD/flow-file

я выбрал 2 (просто привычка)

-w рабочая директория, то, куда будут ложиться файлы со статистикой в выбранном ранее формате

-S этот параметр больше нужен для самоуспокоения и мониторинга. Это кол-во минут, через которое в лог файл будет сыпаться информация о принятых записях флоу. Я использую ее как мониторинг.

localip/remoteip/port — тут, я думаю, все и так понятно:

— localip — ip машины, на которой запущен коллектор flow-tools;

— remoteip — ip машины, с которой мы принимаем флоу (это может быть как cisco так и другая машина, которая отправляет флоу), в моем случае это ip cisco;

— port — порт коллектора, на котором flow-tools слушает и получает данные.

Пример с IP-адресами:

/usr/local/bin/flow-capture -p /var/run/flow-capture.pid -n 0 -N 2 -w /var/netflow -S 60 192.168.1.1/192.168.1.2/5555

В свое время у меня возникла необходимость иметь два коллектора. Flow-tools прекрасно справляется и с этой задачей: я просто запустил еще один flow-capture, но на другом порту и с другой рабочей директорией.

Посмотреть статистику можно утилитой из того же flow-tools:

/usr/local/bin/flow-cat <путь к файлу с флоу> | /usr/local/bin/flow-print

Удачи.

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Green

Начинающие часто спрашивают:

Как поднять vlan на FreeBSD ?

Как сделать trunk на FreeBSD ?

Отвечаем:

Это не просто, а очень просто.

Теория:

Что такое vlan ?
Что такое trunk ?

VLAN (от англ. Virtual Local Area Network), VLAN могут являться частью большего LAN, имея определенные правила взаимодействия с другими VLAN, либо быть полностью изолированными от них. Простейший механизм изоляции различных подсетей, работающих через общие свичи и роутеры, известен как 802.1Q.

Преимущества VLAN

• увеличивает число широковещательных доменов, но уменьшает размер каждого широковещательного домена, которые в свою очередь уменьшают сетевой трафик и увеличивают безопасность сети (оба следствия связаны вместе из-за единого большого широковещательного домена);
• уменьшает усилия администраторов на создание подсетей;
• уменьшает количество оборудования, так как сети могут быть разделены логически, а не физически;
• улучшает управление различными типами трафика.

Транк VLAN — это физический канал, по которому передается несколько VLAN каналов, которые различаются тегами (метками, добавляемыми в пакеты). Транки обычно создаются между «тегированными портами» VLAN-устройств: свитч-свитч или свитч-маршрутизатор. (В документах Cisco термином «транк» также называют объединение нескольких физических каналов в один логический: Link Aggregation, Port Trunking). Маршрутизатор (свитч третьего уровня) выступает в роли магистрального ядра сети (backbone) для сетевого трафика разных VLAN.

На устройствах Cisco, протокол VTP (VLAN Trunking Protocol) предусматривает VLAN-домены для упрощения администрирования. VTP также выполняет «чистку» трафика, направляя VLAN трафик только на те коммутаторы, которые имеют целевые VLAN-порты.
Native VLAN — каждый порт имеет параметр, названный постоянный виртуальный идентификацией (Native VLAN), который определяет VLAN, назначенный получить нетеговые кадры.

Сказав проще, vlan — это логический канал внутри физического канала (кабеля), а trunk это множество логических каналов (vlan`ов) внутри одного физического канала (кабеля).

Итак более-менее с теорией разобрались, теперь подумаем зачем нам это может понадобиться.

Данная технология может пригодиться например если на сервер нужно «подать» несколько физических линков, а сетевая карта всего одна и вставить ещё одну нет возможности.

Возьмем подобную ситуацию как пример и попробуем настроить следущее:

• У нас сервер только с одной сетевой картой, а
• необходимо подключить два канала от двух провайдеров
• Провайдер А выдал IP-адрес 192.168.1.15 маска 255.255.255.0
• Провайдер Б выдал IP-адрес 172.16.10.48 маска 255.255.255.192

Для того чтобы разрулить данную ситуацию нам понадобится switch который понимает Vlan (802.1Q), уже почти все управляемые свичи идут с этой функцией. В нашем примере рассмотрим два типа свичей:

1. cisco catalyst (например 2950 или 3560)
2. dlink DES-3526

Два провайдера и сервер FreeBSD с одной сет.картой

Начинаем

Воткнем физические связи в наш свич, получим три кабеля и три занятых порта

1. порт 1 — Провайдер А
2. порт 2 — Провайдер Б
3. порт 3 — наш сервер

Настроим cisco catalyst:

configure terminal
vlan 100
name provider_a
vlan 101
name provider_b
int gi0/1
switchport access vlan 100
int gi0/2
switchport access vlan 101
exit
exit

Этими командами мы создали два vlan с номерами 100 и 101 для линков от двух провайдеров и назначили два порта каталиста в эти vlan.

по команде show vlan вы должны видеть созданные vlan`ы

Теперь перейдем к конфигурированию 3-го порта каталиста куда воткнут наш сервер. Т.к. нам придется в этот порт посылать оба vlan (100,101) нам необходимо сделать trunk на этом порту:

configure terminal
int gi 0/3
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan 100,101
exit
exit

Этими командами мы на третьем порту каталиста подняли trunk и разрешили в этом trunk`е два vlan 100,101

В терминах Cisco:

• порт в аксес/аксес порт (access port) — порт принимающий не тегированные пакеты (пакеты в которых нет тега (номера) vlan которому они принадлежат)
• порт в транке/транк порт (trunk port) — порт принимающий тегированные пакеты в которых указан тег (номер) vlan

Сделаем тоже самое, но для Dlink:

create vlan provider_a tag 100
create vlan provider_b tag 101
config vlan provider_a add untagged 1
config vlan provider_b add untagged 2
config vlan provider_a add tagged 3
config vlan provider_b add tagged 3

Так же по команде show vlan убеждаемся что все на месте.

В терминах Dlink:

• антагет порт (untagged port) — порт в аксес режиме принимающий не тегированные пакеты
• тагет порт (tagged port) — порт в транке принимающий тегерованные пакеты

Переходим к FreeBSD. В качестве примера используется сет. карта 82545EM Gigabit Ethernet Controller интерфейс em0

Для начала удалим все IP-адреса с интерфейса em0 (если они есть):

/sbin/ifconfig em0 delete

Создадим vlan для провайдера А:

/sbin/ifconfig vlan100 create
/sbin/ifconfig vlan100 vlan 100 vlandev em0

Вот и все, vlan создан, проверяем есть ли он в списке интерфейсов:

запускаем команду /sbin/ifconfig vlan100

vlan100: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=3<RXCSUM,TXCSUM>
ether 00:02:a5:4e:92:48
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
vlan: 100 parent interface: em0
Итерфейс на месте.

Создадим vlan для провайдера Б:

/sbin/ifconfig vlan101 create
/sbin/ifconfig vlan101 vlan 101 vlandev em0

Проверяем есть ли он в списке интерфейсов:

запускаем команду /sbin/ifconfig vlan101

vlan101: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=3<RXCSUM,TXCSUM>
ether 00:02:a5:4e:92:48
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
vlan: 101 parent interface: em0
Итерфейс на месте.

После того как интерфейсы vlan`ов созданы мы обращаемся с ними как с обычными интерфейсами обычных сетевых карт.

Добавим IP-адреса на созданные vlan`ы:

/sbin/ifconfig vlan100 add 192.168.1.15/24
/sbin/ifconfig vlan101 add 172.16.10.48/26

Вот и все, если вы все сделали правильно, то при выводе команды ifconfig получите:

vlan100: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=3<RXCSUM,TXCSUM>
ether 00:02:a5:4e:92:48
inet 192.168.1.15 netmask 0xffffff00 broadcast 192.168.1.255
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
vlan: 100 parent interface: em0


vlan101: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=3<RXCSUM,TXCSUM>
ether 00:02:a5:4e:92:48
inet 172.16.10.48 netmask 0xffffffc0 broadcast 172.16.10.63
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
vlan: 101 parent interface: em0

Можете проверять наличие связи с двумя провайдерами 🙂

Уничтожить/удалить vlan можно командой (например удалим vlan100):

/sbin/ifconfig vlan100 destroy

Осталось последнее дело, чтобы после reboot конфигурация vlan`ов сохранялась.

Для этого добавим в файл /etc/rc.conf следующие строчки:

ifconfig_vlan100=»inet 192.168.1.15 netmask 255.255.255.0 vlan 100 vlandev em0″
ifconfig_vlan101=»inet 172.16.10.48 netmask 255.255.255.192 vlan 101 vlandev em0″
cloned_interfaces=»vlan100 vlan101″

Есть и второй способ сделать тоже самое. Создайте файл /etc/rc.local и в него вставте все команды которые вы вводили для создания vlan`ов и присваевание им IP-адресов. Файл /etc/rc.local так же отрабатывается при загрузке сервера и будут исполнены все команды в нем перечисленные.

Ссылки:

• Настраиваем 802.1Q trunk между свичами Cisco Catalyst 3560G и сервером FreeBSD

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Николаев Дмитрий (virus (at) subnets.ru)