Май 20, 2011 - 0 Comments - Теория -

Что такое NAT?

NAT — Network Address Translation.

 

Истoрия NAT

Снaчaлa нeскoлькo слoв oб истoрии пoявлeния нeoбxoдимoсти в прoксирoвaнии / гeйтирoвaнии / туннeлирoвaнии в интeрнeтe, тoгдa яснee стaнут вoзмoжнoсти рaзныx пoдxoдoв и иx «иeрaрxия». Кaк извeстнo, нexвaткa IP-aдрeсoв в 4-бaйтoвoм aдрeснoм прoстрaнствe прoгнoзирoвaлaсь eщe в нaчaлe 90x гoдoв (плюс нexвaткa дeнeг нa aрeнду aдрeсныx блoкoв в нeкoтoрыx кoмпaнияx . Пoэтoму ужe в мaртe 1994 г дoгoвoрились oб aдрeснoм «сeгмeнтирoвaнии» oбщeгo прoстрaнствa — выдeлeнии для лoкaльныx сeтeй oтдeльныx диaпaзoнoв IP-aдрeсoв и исключeниe этиx IP-aдрeсoв из испoльзoвaния в интeрнeтe . Этo рeшeниe пoзвoлилo выдeлять кoмпaниям нeбoльшиe блoки IP-aдрeсoв — для иx интeрнeт-сeрвeрoв, a внутри ЛС IP-aдрeсa для сoбствeнныx нужд выдeлялись сaмими кoмпaниями из диaпaзoнoв для лoкaльныx сeтeй. В рeзультaтe интeрнeт-сeрвeры кoмпaний (пoчтoвыe и www/ftp) были лeгкo дoступны кaк из интeрнeтa, тaк и из ЛС, и внутри ЛС кoмпьютeры бeз прoблeм связывaлись пo тaким жe IP-прoтoкoлaм. Нo этo рeшeниe вoздвиглo бaрьeр мeжду лoкaльными сeтями и интeрнeтoм: т.к. oдин и тoт жe IP-aдрeс мoг испoльзoвaться в рaзныx ЛС, и т.к. пo этoй причинe в интeрнeтe пeрeстaли мaршрутизирoвaть пaкeты нa aдрeсныe блoки, выдeлeнныe для ЛС. Т.e. фaктичeски «физичeский бaрьeр» (бeз пeрeрубaний прoвoдoв, чeм рaзвлeкaлись в рoссийскиx бaнкax пoслe пeрвыx взлoмoв, и бeз устaнoвки FIREWALL, чeм увлeкaются сeйчaс). Сeти стaли изoлирoвaнными, кaк изoлирoвaны зaдaчи в сoврeмeнныx oпeрaциoнныx систeмax — у кaждoй свoё aдрeснoe прoстрaнствo. Этoт бaрьeр нe прeдстaвлял прoблeмы для пoчты, т.к. пoчтoвыe сeрвeры прeдприятий стaвились нa грaницe сeтeй и были видимы и из интeрнeтa, и из ЛС. A вoт с дoступoм из ЛС к внeшним рeсурсaм — к ftp и eщe тoлькo нaбирaющим в тe гoды пoпулярнoсть http-сeрвeрaм нaчaлись прoблeмы. Eсли рaньшe с любoгo кoмпьютeрa мoжнo былo нaпрямую взaимoдeйствoвaть с сeрвeрoм, тo тeпeрь этa вoзмoжнoсть осталась у компьютеров только с реальными интернет-адресами, т.к. в какую ЛС слать ответ на IP-пакет, у которого в обратном адресе стоит локальный IP — роутер определить не сможет.

Простейшее решение этой задачи — подмена обратного адреса на границе сетей — лежало на поверхности и не замедлило опубликоваться: в мае 1994 г., т.е. через два месяца после «раздела сетей» предложили спецификацию NAT: http://www.ietf.org/rfc/rfc1631.txt The IP Network Address Translator (NAT) May 1994 Авторы анонсировали это как «short-term solution», т.е.временное решение указанной проблемы, эдакий «хак», пока не получат распространение нормальные решения. Но, как известно, ничего не бывает столь постояным, как временное IPV6 вопреки ожиданиям быстро не прижился, и все прошедшие 10 лет мы были свидетелями все новых и новых боев на границах ЛС и интернета. NAT получил распространение, т.к. никакого другого приемлемого решения этой проблемы в те годы не было: FTP-клиенты и HTTP-клиенты (браузеры) не успели адаптироваться под под измененную картину мира, не могли работать из ЛС с внешними ресурсами, поэтому чтобы сделать для них границу прозрачной, их просто программно «обманывали» с помощью NAT — все IP-пакеты, адресованные из ЛС наружу, подвергались простейшей обработке на границе: замене обратного IP-адреса на реальный адрес «пограничного» компьютера, и обратной замене во входящих пакетах. Кроме того обычно заменялся и номер порта ЛС-источника, т.к. с разных машин в ЛС пакеты могут исходить с одними и теми же номерами портов. Т.е. транслируются не только IP-адреса, но и номера портов (иногда порт-трансляторы называют отдельной аббревиатурой PAT). В условной классификации NAT подразделяют на «статические, динамические и маскарадинг (masquerading)», но на практике применяется в основном третий тип, он позволяет через один реальный IP адрес обслуживать тысячи соединений из ЛС (в идеале), трансляция портов при этом используется всегда. На NAT-компьютере или роутере+NAT выделяется диапазон портов, используемых для трансляции, например с номерами больше 60000 (чтобы быстрее отличать эти порты от выделенных под собственные нужды этого компьютера) и динамическая таблица текущих сессий/отображений адресов. Каждый проходящий пакет сверяется с этой таблицей по IP и порту и производятся соответствующие подстановки. Технология настолько проста, что сейчас уже все реже можно встретить роутер или кабельный модем без встроенного NAT (и FIREWALL, столь же примитивного как NAT), причем NAT уже можно обнаружить даже в hub’ах c ценами от $40. Не говоря уж о «бесплатном» NAT, входящем в состав нескольких последних версий Windows под именем «connection sharing» и «совместное использование соединения«. Именно доступность, простота понимания/использования и нетребовательность к клиентскому софту, сделали NAT заслуженно популярным.

 

NAT

NAT

 

NAT «глазами» интернет-программ

Если бы на практике все было так просто, то было бы неинтересно Но, конечно, как бывает и с любым другим программным трюком, в NAT сразу же стали вылезать разнообразные неприятные побочные эффекты. На момент появления NAT одним из самых популярных протоколов был FTP, и именно этот протокол стал для NAT первым неперевариваемым протоколом. Это выявило проблему, которая так и не была хоть сколько нибудь успешно решена в NAT за эти 10 лет. И в общем случае она не может быть решена в рамках NAT, могут быть только подгонки под конкретные протоколы, но эти подгонки нельзя считать надежным решением. Проблема эта состоит в том, что в некоторых протоколах, среди которых старейшим является FTP, передается IP-адрес клиентской машины, и этот IP-адрес используется сервером для передачи данных клиенту. Поскольку в случае с NAT клиентская программа, работающая из ЛС «обманута» NAT’ом, она может передать серверу только свой собственный локальный IP-адрес, соединиться с которым внешний сервер не сможет из-за невидимости локальных сетей из интернета. Другими примерами могут служить протоколы ICQ, MSNetMeeting, RealAudio и многие другие протоколы, разработчики которых видимо сидели в сетях без
NAT может предложить только одно решение такой проблемы — основываясь на номерах портов угадать конкретный транслируемый протокол и начать следить за содержимым IP-пакетов. Когда в них встречается FTP-команда PORT, в которой указывается IP:порт локального клиента (текстовая команда в теле пакета, а не в заголовке IP-пакета), то заменять не только заголовки, но весь пакет, с пересчетом контрольной суммы и организацией прослушки еще одного входящего порта. К сожалению для NAT, TCP-протокол, в котором передаются команды FTP-протокола, является поточным протоколом, организованным над IP — команда PORT при попадании на IP-уровень может оказаться разбитой на 2 пакета (а то и более, в зависимости от FTP-клиента и буферизации в ОС). Поэтому для надежного обнаружения места подмены NAT’у придется реконструировать исходный TCP-поток, буферизировать и пересобирать пакеты. К «реконструкции протоколов» в NAT мы еще вернемся, а пока просто отметим многоярусный уровень потенциальных ошибок и ненадежностей в этом процессе. На практике это приводит к тому, что стандартный режим FTP с использованием команды PORT через NAT как правило НЕ работает.

Поэтому «проблему NAT» в FTP-протоколе приходится обходить особым образом в FTP-клиентах или в еще одном промежуточном специализированном FTP-прокси. В FTP-клиенте для этого нужно переключиться в т.н. «пассивный режим» — использовать вместо команды PORT команду PASV. PASV просит FTP-сервер открыть дополнительный порт у себя и сообщить клиенту его IP:порт. Клиент после этого соединяется с указанным IP (NAT его еще раз обманывает-транслирует) и сессия удается. Кроме необходимости поддержки PASV-режима в FTP-клиенте (в стандартном ftp.exe её нет), при этом требуются и некоторые усилия со стороны администратора FTP-сервера — особенно если он тоже частично загорожен Firewall’ами и NAT’ами (как разработчик FTP-сервера для Eserv знаю эти проблемы не по наслышке). В общем, здесь NAT не помогает соединяться, а мешает.

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

Намного проще эта задача решается, если вместо NAT или в дополнение к нему сразу использовать специализированный прокси (FTP gate) или универсальные TCP-прокси типа Socks или в крайнем случее httpS (этот крайний случай тем не менее сработает лучше чем NAT). Они изначально работают на TCP-уровне и не обманывают FTP-клиента, а сотрудничают с ним. Отпадают сразу три слоя проблем: FTP-клиент может использовать любой режим — активный или пассивный (в httpS только пассивный, как и в NAT), нет нужды угадывания протокола и двойной сборки TCP. Кроме того, у админа появляется больше возможностей влиять на процесс (об этом позже).

Если клиентская программа не умеет работать через спец-прокси (таких практически не осталось, но будем говорить о худших случаях), то при использовании Socks-прокси работу клиента также можно сделать прозрачной с помощью программ Socks Capture или отечественной FreeCap.Прозрачность границы — это всегда обман, но  SocksCapture ли  FreeCap  перехватывают не IP-пакеты, а обращения программы к ОС, поэтому они всегда точно знают, а не вычисляют по потоку пакетов, какое именно действие хочет совершить программа, и соответственно перенаправляют эти действия через Socks-прокси.


Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Человек ? *