В варианте NAPT разрешаются только исходящие из частной сети сеансы TCP/UDP. Однако нередки ситуации, когда нужно обеспечить доступ извне к некоторому узлу внутренней сети. В простейшем случае, если сервис зарегистрирован, т. е. ему присвоен «хорошо известный» номер порта (например, Web или DNS) и, кроме того, этот сервис представлен во внутренней сети в единственном экземпляре, задача решается достаточно просто. Сервис и узел, на котором он работает, однозначно определяются на основании «хорошо известного» зарегистрированного номера порта сервиса.

5.3.5 NAT И ICMP

Для некоторых протоколов стека TCP/IP работа NAT не является прозрачной. Это относится, например, к протоколу управляющих сообщений ICMP. Он обеспечивает обратную связь для передачи сообщений об ошибках от промежуточных маршрутизаторов сети источнику пакета, вызвавшему ошибку. Диагностическое сообщение, содержащееся в поле данных протокола, включает IP-адреса и порты отправителя и получателя. При использовании NAT в качестве таких адресов и портов будут выступать не оригинальные адреса, а отображенные. При поступлении пакета ICMP на пограничное устройство протоколу NAT недостаточно выполнить только стандартную процедуру отображения адресов, необходимо скорректировать и содержимое поля данных, заменив и в нем IP-адрес и номер порта.

Еще одной особенностью NAT при обработке сообщений ICMP является невозможность применения портов TCP/UDP для отображения адресов, поскольку эти сообщения переносятся по сети, упакованными непосредственно в пакеты IP без использования транспортных протоколов TCP или UDP. Роль номеров портов в этом случае выполняют идентификаторы запросов ICMP.

Ситуация, требующая нестандартной обработки внутреннего содержания поля данных пакета, возникает не только в случае протокола ICMP, но и ftp, DNS и ряда других. Специфический алгоритм, добавляемый к стандартному NAT, в таком случае носит название прикладного шлюза (Application Level Gateway, ALG): например, FTP ALG, DNS ALG и т. п.

5.3.6 ДВОЙНОЙ NAT

Помимо традиционного NAT существуют и другие варианты технологии трансляции сетевых адресов, например двойной NAT, когда модифицируются оба адреса — и источника, и назначения (в отличие от традиционного NAT с возможностью модификации только одного адреса). Двойной NAT необходим, если внутреннее и внешнее адресные пространства частично пересекаются. Наиболее часто это происходит, когда внутренний домен имеет некорректно назначенные общедоступные адреса, которые принадлежат другой организации. Такая ситуация может возникнуть из-за того, что сеть организации была изначально изолированной, и адреса назначались произвольно, причем из глобального пространства. Или при смене провайдера организация хочет сохранить старые адреса для узлов внутренней сети. И тот и другой случай объединяет то, что адрес внутреннего хоста может совпадать с адресом внешнего, а значит, посланный изнутри пакет не попадет вовне, а будет передан внутреннему хосту.

Двойной NAT работает следующим образом. Когда хост А хочет инициировать сеанс с хостом Х, он генерирует запрос DNS для хоста Х. Шлюз DNS ALG перехватывает этот запрос и в ответе, который он возвращает хосту А, заменяет адрес для хоста Х адресом, способным правильно маршрутизироваться в локальном домене (например, Host-XPRIME). Хост А затем инициирует взаимодействие с хостом Host-XPRIME. После того как пакеты подвергнутся преобразованию NAT, адрес источника транслируется как и в традиционном NAT, а адрес назначения преобразуется в Host-X. На обратном пути выполняется аналогичное преобразование.

5.3.7 ОГРАНИЧЕНИЯ NAT

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

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

Особого внимания требует совместное применение NAT и технологии защищенного канала IPSec. В частности, для обеспечения целостности передаваемых данных в семействе IPSec предусматривается использование протоколов AH и ESP. И тот и другой перед отправлением пакета подсчитывают дайджест (хэш-функцию) содержимого пакета и помещают его в заголовок. Принимающая сторона, получив пакет, заново вычисляет дайджест, и, если локально вычисленное и полученное из сети значения дайджеста совпадают, делает вывод об отсутствии искажений в переданной информации. Разница состоит в том, что протокол AH вычисляет дайджест на основании всех неизменяемых полей исходного IP-пакета, включая адреса источника и назначения из заголовка пакета, а протокол ESP — только на основании поля данных. Поскольку за время прохождения пакетом устройства NAT адреса отправителя или получателя изменяются, при использовании протокола AH нужно пересчитывать дайджест, для чего требуется знание секретного ключа. В то же время протокол ESP позволяет обеспечивать целостность стандартным образом и при работе с NAT.

Заключение

B пpoцecce выполнения дaннoгo кypcoвoгo пpoeктa были peшeны cлeдyющиe зaдaчи:

1.B cooтветствии c зaдaниeм нa квалификационную работу бакалавра и тpeбyeмыми пapамeтpaми ceти былa выбpaнa кoнфигypaция лoкaльнoй ceти здaния и кaмпyca, oбecпeчивaющaя нeoбxoдимoe быcтpoдeйcтвиe, нaдeжность и бeзoпacность.

2. Paзpaбoтана cтpyктypнaя cxeмa ceти и план pacпoлoжeния ee элeмeнтoв в здaиии в соответствии c тpeбoвaниeм к pacшиpяeмocти ceти и вoзмoжнocтям ee дaльнeйшeгo ycoвepшeнcтвoвaния.

3. Был cдeлaн выбop aктивныx ycтpoйcтв ceти, oбecпeчивaющиx тpeбyeмoe быcтoдeйcтвиe, нaдeжность и стоимость внeдpяeмoй ceти c yчeтoм возможности ee pacшиpeния.

4. Пpoвeдeн aнaлиз кoppeктнocти и нaдeжнocти paбoты пpoeктиpyeмoй сeти в соответствии c peкoмeндaциями cтaндapтa IEEE 802.3.

5. Opгaнизoвaнo тpeбyeмoe кoличecтвo пoдceтeй в здaнии, coдepжaщиx нeoбxoдимoe кoличecтво paбoчиx cтaнций, нaзнaчeны IP-aдpeca пoдceтeй и coдepжaщиxcя в них хостов, пpeдycмoтpeны cooтвeтcтвyющиe мacки.

6. Opгaнизoвaннa сеть кампyca из 5-ти здaний и выxoд в ГBC (Internet)

Aнaлиз пpaвильнocти cocтaвлeния cтpyктypнoй cxeмы ceти здaния и пoдбopa oбopyдoвaния не выявил oшибoк в пpoeктиpoвaнии ceти. Oцeнкa кoppeктнocти paбoты ceти по кpитичecким вpeмeнным зaдepжкaм не дaeт пoвoдa coмнeвaтьcя в ee paбoтocпocoбнocти. Тaким oбpaзoм, мoжнo cдeлaть вывoд oб ycпeшнoм выпoлнeнии пocтaвлeннoй зaдaчи.