ISP`s IT Аутсорсинг
Быстрый переход: Главная блога Главная сайта Форум
Если Вы чего то недопоняли или не нашли - задайте
вопрос на нашем форуме и мы попробуем Вам помочь.
Subnets.ru Регистрация IP и Автономных систем mega-net.ru

Метки статьи: ‘nat’

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.

Для работы этого примера необходимо иметь подгруженный ng_ipfw.ko

Убедиться в его наличии можно командой:

/sbin/kldstat

Id Refs Address    Size     Name
1   11 0xc0400000 4eddc0   kernel
..........................
7    1 0xc9e22000 2000     ng_ipfw.ko

Если у вас ng_ipfw.ko не загружен, то подгрузите его:

/sbin/kldload /boot/kernel/ng_ipfw.ko

После того как ng_ipfw.ko подгружен, в выводе команды:

/usr/sbin/ngctl list

появится строчка вида:

Name: ipfw Type: ipfw ID: 00000023 Num hooks: 2

Без загруженного ng_ipfw.ko при попытке выполнить команды ngctl`а вы будете получать сообщение:

ngctl: send msg: No such file or directory

а при попытке добавить правило в ipfw получите:

ipfw: getsockopt(IP_FW_ADD): Invalid argument

Настройка ng_nat проста и сводится к простенькому скрипту:

Для примера будем NAT`ить подсеть 172.16.5.96/27 через IP-адрес 192.168.20.8 на внешнем интерфейсе fxp0.

#!/usr/bin/perl

$ip='192.168.20.8';
$iface='fxp0';
$net='172.16.5.96/27';
$cmd=sprintf("/usr/sbin/ngctl -f - << -EOF
mkpeer ipfw: nat 60 out
name ipfw:60 nat
connect ipfw: nat: 61 in
msg nat: setaliasaddr %s
",$ip);
system($cmd);

###добавляем необходимые правила в firewall
$cmd=sprintf("/sbin/ipfw add 1000 netgraph 61 all from any to %s via %s in",$ip,$iface);
system($cmd);
$cmd=sprintf("/sbin/ipfw add 1010 netgraph 60 all from %s to any via %s out",$net,$iface);
system($cmd);

где:
$ip — IP адрес, через который будет работать нат (который смотрит в интернет)
$iface — ваш внешний интерфейс
$net — IP подсеть, которую мы собираемся NAT`ить
netgraph — правило в firewall, аналогично divert, только перенаправляет трафик не в socket, а в ноду netgraph, 60, 61 — адреса исходящего и входящего хуков.

Если делать руками в консоле, то команды выглядят следующим образом:

###создаем ноду nat и подключаем к ipfw
/usr/sbin/ngctl mkpeer ipfw: nat 60 out 
###даем ноде имя "natA" 
/usr/sbin/ngctl name ipfw:60 natA   
###соединяем входящие и исходящие хуки  для "natA"
/usr/sbin/ngctl connect ipfw: natA: 61 in 
###посылаем управляющее сообщение в виде IP адреса, через который будет работать нат.   
/usr/sbin/ngctl msg natA: setaliasaddr 192.168.20.8   

Если все работает, то мы можем посмотреть вывод следующей команды:

#test:~:ngctl show natA:
Name: nat             Type: nat             ID: 00000029   Num hooks: 2
Local hook      Peer name       Peer type    Peer ID         Peer hook
----------      ---------       ---------    -------         ---------
in                     ipfw            ipfw         00000001        61
out                   ipfw            ipfw         00000001        60

Также можно посмотреть все целиком:

#test:~:ngctl list

Как выключить этот NAT ?

Просто выполнить команду:

#test:~:ngctl shutdown natA:

Заметка:

Если вы хотите запустить NAT на нескольких внешних IP-адресах, но не забывайте изменять имена нод (в примере natA) и номера хуков (в примере 60,61) т.к. они должны быть уникальны для каждого из процессов.

Не путайте in и out в создаваемой ноде и правилах ipfw.

Чтиво:

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

Автор: Folio
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 8, среднее: 3,50 из 5)
Loading...Loading...
Отправить на почту Отправить на почту

В помощь новичкам.

Итак, перед вами встала задача раздать Инет на компы за сервером FreeBSD.

Как и множество других вещей во FreeBSD эту задачу можно решить несколькими способами.

Кратко покажу как это можно сделать используя в кач-ве NAT`а процесс natd.

Запускать natd можно несколькими способами, я покажу тот который обычно использую я сам.

Для работы нам потребуются 2 вещи:

  1. firewall ipfw с его возможностью divert
  2. natd

Для того, чтобы приступить необходимо пересобрать ядро с опциями:

options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPDIVERT

Так же можно добавить опции:

options IPFIREWALL_FORWARD
options IPFIREWALL_VERBOSE_LIMIT=1000
options IPFIREWALL_DEFAULT_TO_ACCEPT

Либо подгрузить ipfw как модуль:
/sbin/kldload /boot/kernel/ipfw.ko

Скажем что:

  • сетевая карта в сторону провайдера em0 c IP 10.10.1.2/30
  • сетевая карта в сторону локалки em1 с IP 192.168.1.1/24

Запустим процесс natd:

/sbin/natd -s -m -a 10.10.1.2

Процесс natd должен «висеть» на внешнем интерфейсе ВСЕГДА !

Добавим необходимые правила в ipfw, для того, чтобы трафик попадал в natd:

/sbin/ipfw add 300 divert 8668 ip from any to 10.10.1.2
/sbin/ipfw add 310 divert 8668 ip from 192.168.1.0/24 to any
/sbin/ipfw add 350 allow ip from any to 192.168.1.0/24
/sbin/ipfw add 360 allow ip from 192.168.1.0/24 to any

Этих 4-х правил достаточно, чтобы дать доступ в интернет подсети 192.168.1.0/24.

Для того, что бы после ребута, все это поднялось, можно сделать следущее.

1. отредактировать файл /etc/rc.conf добавив:

firewall_enable=»YES»
firewall_script=»/etc/rc.firewall»
firewall_type=»/usr/local/etc/firewall.conf»
firewall_quiet=»YES»
firewall_logging=»YES»
firewall_flags=»»

2. написать наши правила в /usr/local/etc/firewall.conf:

add 100 allow ip from me to me via lo0
add 105 deny ip from any to any via lo0
add 300 divert 8668 ip from any to 10.10.1.2
add 310 divert 8668 ip from 192.168.1.0/24 to any
add 350 allow ip from any to 192.168.1.0/24
add 360 allow ip from 192.168.1.0/24 to any
add 65000 allow ip from any to any

3. создать файл /usr/local/etc/rc.d/natd.sh:

#!/bin/sh
/sbin/natd -s -m -a 10.10.1.2

4. сделать файл /usr/local/etc/rc.d/natd.sh исполняемым:

/bin/chmod a+x /usr/local/etc/rc.d/natd.sh

Можно поступить и немного по другому, запустив natd на интерфейсе, а не на IP-адресе:

отредактировать файл /etc/rc.conf добавить:

natd_program=»/sbin/natd» # path to natd, if you want a different one.
natd_enable=»YES» # Enable natd (if firewall_enable == YES).
natd_interface=»em0″ # Public interface or IPaddress to use.
natd_flags=»» # Additional flags for natd.

изменить правило номер 300 на:

add 300 divert 8668 ip from any to any via em0

Для полного понимания загляните в мануалы:

man natd
man ipfw
Там есть подробное описание и примеры.

З.Ы. В FreeBSD 7.x можно использовать kernel nat, но лб этом как нить потом или кратко если в разделе "Советы" на сайте.
З.З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 4, среднее: 4,25 из 5)
Loading...Loading...
Отправить на почту Отправить на почту

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

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

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

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

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

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

Рисунок 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

Рисунок 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

Рисунок 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-сессии

Рисунок 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, если, конечно, оно существует, или заменить сам маршрутизатор).

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

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 7, среднее: 4,43 из 5)
Loading...Loading...
Отправить на почту Отправить на почту