69581

Удаленный доступ

Практическая работа

Информатика, кибернетика и программирование

Пример: пусть некоторый удаленный пользователь хочет подключиться к своей корпоративной сети будучи в командировке. Для этого в его корпоративной сети должен быть компьютер готовый принимать входящие подключения по телефонной сети общего пользования или по сети ISDN.

Русский

2014-10-07

4.83 MB

2 чел.

Урок 11

Удаленный доступ

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

Пример: пусть некоторый удаленный пользователь хочет подключиться к своей корпоративной сети, будучи в командировке. Для этого в его корпоративной сети должен быть компьютер, готовый принимать входящие подключения по телефонной сети общего пользования или по сети ISDN. При осуществлении звонка будет сформирована глобальная сеть типа точка-точка с двумя узлами: компьютером пользователя и сервером удаленного доступа. Разумеется, в этой сети должны быть присвоены IP адреса, и, так как в этой сети два узла, то вполне логично ожидать, что узлам этой сети будут присвоены адреса с маской /30, которая как раз ограничивает IP сеть двумя узлами. Рассмотрим схему сети доступа:

 

Схема 1 при единственном подключении

Получается вполне привычная схема адресации - в полученной сети ровно два узла: 210.1.1.1 и 210.1.1.2, следовательно, длина сетевого префикса 30 бит. И таким образом достигается вроде бы как экономное использование адресного пространства. Предположим, что таких клиентов, позвонивших на сервер удаленного доступа много, тогда для каждого из клиентов должна быть выделена сеть с маской /30.

Схема 1 при множественных подключениях

Но такой способ назначения IP адресов является крайне расточительным – на каждого клиента расходуется сеть размером два узла, но эта сеть использует 4 IP адреса: помимо двух адресов, назначенных клиенту и серверу, это еще адрес, являющийся номером сети и широковещательный адрес. Для случая, когда создается схема подключение клиентов к провайдеру услуг Интернет все адреса, назначенные клиентам должны быть «честными», а не автономными, и это значит, что для обслуживания каждого позвонившего провайдеру клиента расходуется 4 IP адреса. В условиях глобального дефицита IP адресов такое решение проблемы адресации крайне неэффективно.

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

Узел получает от сервера удаленного доступа совокупность IP адреса и маски следующего вида: 210.1.1.2 /32 (или 255.255.255.255). При этом узел обычно сконфигурирован таким образом, чтобы использовать свой собственный адрес в качестве шлюза по умолчанию. Таким образом, типовые настройки узла, подключившегося к серверу удаленного доступа, имеют вид:

IP адрес: 210.1.1.2

Маска: 255.255.255.255

Шлюз: 210.1.1.2

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

Схема 2 при множественных подключениях

Видно, что глобальные сети точка-точка, соединяющие клиентов удаленного доступа и сервер удаленного доступа в явном виде адресов сетей не имеют, у сервера удаленного доступа вместо интерфейса в сети с каждым клиентом появляется один единственный интерфейс, который в терминологии Windows называется «Внутренний» («Internal»). Видно, так же, что на каждого клиента расходуется ровно 1 IP адрес.

Почему сконфигурированные таким образом клиенты и сервер удаленного доступа могут нормально обмениваться пакетами?

Пусть станция 210.1.1.2 хочет отправить пакет для станции 1.1.1.1. Для начала рассмотрим, как производилась бы маршрутизация этого пакета в случае, если бы была реализована классическая схема адресации, приведенная на первой схеме. В таком случае адрес клиента удаленного доступа был бы 210.1.1.2, маска 255.255.255.252, шлюз по умолчанию – 210.1.1.1.

Если станция 210.1.1.2 отправляет пакет для 1.1.1.1, то как она его обрабатывает? Применим известную нам логику работы узлов: станция накладывает на адрес получателя собственную маску подсети и получает 1.1.1.0, ее собственный номер сети очевидно равен 210.1.1.0. Следовательно, получатель принадлежит иной канальной сети, и пакет должен быть перенаправлен на маршрутизатор (роль которого, разумеется, играет в данном случае сервер удаленного доступа). 

Станция 210.1.1.2 должна передать пакет шлюзу 210.1.1.1, для этого ей не нужно слать ARP запрос. Интерфейс станции в сети 210.1.1.0 является не Ethernet, а PPP интерфейсом. Протокол PPP не поддерживает использования адресации канального уровня, так как сеть на базе протокола PPP содержит по определению два узла.  Так что, когда узлу становится ясно, что пакет нужно отправить на 210.1.1.1, он просто передает кадр PPP с соответствующим IP пакетом через свой интерфейс в сети точка-точка.

Таким образом, задача о маршрутизации, которую решает узел, крайне проста – ВСЕ пакеты необходимо отправлять в свой PPP интерфейс и они попадут на маршрутизатор – сервер удаленного доступа. И эту задачу можно решить гораздо более экономичным способом, нежели расходовать на организацию глобальной сети точка-точка 4 IP адреса, а именно – с помощью той схемы адресации, которая была предложена под номером 2.

Рассмотрим, как ведет себя узел, настроенный по схеме номер 2.

Адрес узла 210.1.1.2, маска 255.255.255.255, шлюз 210.1.1.2. Пусть станция 210.1.1.2 хочет отправить пакет для станции 1.1.1.1. Как она его обрабатывает при новых настройках? Применим логику работы узлов. Для начала станция накладывает на адрес 1.1.1.1 свою маску, состоящую из всех единиц. Совершенно очевидно, что на какой адрес не накладывай маску 255.255.255.255, в ответе всегда получится тот же самый адрес. Фактически такая маска говорит станции о том, что ни один IP адрес кроме её собственного т.е. НИКТО не находится в одной сети - и это, правда. Следовательно, пакет для любого получателя будет перенаправлен с помощью шлюза по умолчанию. А шлюзом по умолчанию является свой собственный адрес, а это значит, что в таблице маршрутизации узла 210.1.1.2 присутствует следующая запись:

Сеть получателя  Маска   Шлюз

0.0.0.0    0.0.0.0   210.1.1.2

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

Если бы сеть между клиентом и сервером удаленного доступа была бы не сетью точка-точка, а сетью с множественным доступом (например, Ethernet), то на это бы все закончилось: станция 210.1.1.2 отправила бы ARP запрос станции 1.1.1.1  и конечно же не получила бы ответа. НО, так как эта сеть все же PPP, то потребности в отправке ARP запроса НЕТ, станция 210.1.1.2 ПРОСТО отправляет в кадре PPP пакет для 1.1.1.1 на сервер удаленного доступа. При этом станция 210.1.1.2 думает (на основании своих настроек), что получатель расположен в той же PPP сети, но это уже ничему не мешает, как и действия которые станция совершит в связи с этим выводом.

Что требуется от станции-клиента? Отправить пакет серверу удаленного доступа для дальнейшей маршрутизации. Именно это и произошло! Таким образом, рассмотренная конфигурация IP протокола на станции является решением задачи о маршрутизации пакетов – все пакеты отправляются на сервер удаленного доступа, и при этом не расходуется большого количества IP адресов и НЕ требуется изменения стека TCP/IP на конфигурируемой станции.

Настройки станции, возможно, кажутся противоречивыми – маска показывает, что со станцией в одной сети нет ни одной станции, а адрес шлюза по умолчанию показывает, что ВСЕ станции составной сети достижимы на канальном уровне, т.е. в одной сети со станцией, выполняющей удаленный доступ. Но на самом деле никакого противоречия нет, есть только одно – давно известная логика, которую выполняет любой узел, на котором работает стек TCP/IP. Зная эту логику, можно создавать любые комбинации настроек маски и шлюза так, что бы при обработке пакетов, в соответствии с существующей логикой поведения узла, достигались интересующие нас цели.

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

Еще один важный вопрос – как сервер удаленного доступа (маршрутизатор) возвращает пакеты станции, ведь он не имеет адреса В КАЖДОЙ сети с каждым клиентом удаленного доступа? Сервер удаленного доступа имеет, как уже говорилось, один IP адрес, связанный с удаленным доступом. При этом сервер знает, какому из своих клиентов он выдал какой IP адрес, т.е. знает номер того порта (имеется в виду аппаратного порта, не по IP адресу или МАС адресу ), в который необходимо передать кадр PPP для данного IP адреса. Таким образом, сервер удаленного доступа тоже достаточно легко решает задачу о передаче пакетов для своих клиентов.

Теперь, когда принципы адресации при удаленном доступе изучены перейдем к изучению конфигурирования сервера удаленного доступа под управлением Windows Server.

Служба удаленного доступа встроена даже в клиентские операционные системы, а не только в серверные, т.е. в Windows 2000/XP Professional. Это сделано для того, чтобы, например, два пользователя, имеющих домашние компьютеры и доступ к PSTN или ISDN могли установить между собой коммутируемое соединение и организовать полноценную сеть друг с другом. Как это сделать? Рассмотрим чисто клиентскую технологию – создание нового подключения в папке «Сеть и удаленный доступ к сети». Мастер создания нового подключения несколько отличается в Windows 2000 и Windows Server 2003/Windows XP Professional, но идея от этого не меняется. Рассмотрим процесс создания нового подключения на примере Windows XP Professional.

Итак, запуск мастера создания нового подключения

Шаг 1

Шаг 2

Шаг 3

Для подключения применяется сценарий «Установить прямое подключение к другому компьютеру». Дальнейшая настройка зависит от того, в какой роли выступает настраиваемая станция – клиент или сервер.

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

Если был подключен модем, то далее выбирается сценарий «Принимать входящие подключения»

 Шаг 4

 

затем указываем, что для входящих подключений используется модем

Шаг 5

разрешаем виртуальные подключения

Шаг 6

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

Шаг 7

конфигурируем стек TCP/IP, используя кнопку «Свойства»

Шаг 8

Подключение «Входящие подключения» НЕ имеет собственного IP адреса, маски и шлюза по умолчанию, вместо этого ему ставится в соответствие диапазон IP адресов, из которого данный сервер удаленного доступа будет раздавать IP адреса позвонившим клиентам. При этом, обычно сервер получает первый IP адрес из этого списка (независимо от количества подключившихся, у сервера будет только один IP адрес) с маской /32. Клиенты будут получать адреса последовательно, начиная со второго с маской /32, если только клиент не захочет указать свой собственный IP адрес, что можно запретить или разрешить соответствующим Check Box.

Указываем, что в создаваемом подключении будут доступны для назначения клиентам, например 10 IP адресов. Причем, клиент имеет право назначать себе IP адрес из описанного диапазона самостоятельно

Шаг 9

Шаг 10

После чего в окне «Сетевые подключения» появляется раздел «Входящие», содержащий значок «Входящие подключения». В случае необходимости изменения конфигурации созданного подключения используется стандартная комбинация Меню «Файл» - «Свойства».

Если же для подключения клиентского компьютера используется нуль-модемный кабель, то в Шаге 4 указывается сценарий «Подключится напрямую к другому компьютеру»

Шаг 4*

Если настраивается станция, выступающая в роли сервера, значит это Ведомый компьютер. Если станция выступает в роли клиента, значит это Ведущий компьютер.

Шаг 5*

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

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

Рассмотрим настройку клиента использующего модем

Шаг 3 Клиент

Шаг 4 Клиент

Шаг 5 Клиент

Шаг 6 Клиент

Шаг 7 Клиент

В Шаге 7 Клиента указывается телефонный номер линии к которой подключен модем станции выбранной сервером удаленного доступа.

Шаг 8 Клиент

Указывается учетная запись для подключения к серверу.

Шаг 9 Клиент

После окончания работы Мастера в окне «Сетевые подключения» появляется значок, подписанный именем поставщика услуг указанным при работе Мастера.

Подключение выполняется кнопкой «Вызов»

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

Шаг 4 Клиент *

Шаг 5 Клиент *

Шаг 6 Клиент *

Шаг 7 Клиент *

После чего в окне сетевые подключения появляется значок с именем соответствующим созданному подключению, причем имя можно выбирать произвольно, главное, что бы было понятно, что это за подключение – к какому серверу.

 После ввода пароля и установки соединения, независимо от способа подключения (модемом или нуль-модемным кабелем). Со стороны клиента подключение имеет следующие параметры

Из приведенной выше информации следует, что в систем существует сетевое подключение. Канальный уровень представлен интерфейсом PPP, для идентификации внутри системы используется аппаратный адрес 00-53-45-00-00-00.

Сетевой адрес интерфейса 10.0.0.2, маска 255.255.255.255 – т.е. используется наиболее рациональный метод выдачи IP адресов со стороны сервера. Адрес шлюза – 10.0.0.2, т.о. анализируя маску и шлюз, приходим к выводу, что обращение к любому сетевому адресу происходит через канальный уровень PPP интерфейса.

Из таблицы маршрутизации можно узнать IP адрес интерфейса «с той стороны» соединения, в нашем случае это 10.0.0.1.

В результате сеть работает в штатном режиме (только медленно)

Со стороны сервера соединение выглядит следующим образом

Созданное соединение осуществляется через PPP адаптер RAS (Remote Access Server) – или сервера удаленного доступа. Которому присваивается первый номер пула адресов выбранных при настройке для назначения при удаленном подключении (10.0.0.1 – 10.0.0.10).

Из приведенной таблицы маршрутизации следует, что сервер использует интерфейс сетевой карты для обслуживания направления Default. Так же в таблице указывается маршрут к подключенному клиенту – станции 10.0.0.2, реализация маршрута происходит через PPP инетрфейс сервера.

Для анализа трафика созданной сети подходят не все рассмотренные ранее анализаторы. Например, Sniffer Pro не видит созданный интерфейс, для подобного рода соединений рекомендуется использовать MS Network Monitor, Commit View или Ethereal. Все эти анализаторы нормально декодирует фазу установления соединения PPP, но впоследствии показывают все кадры как кадры Ethernet II. (ppp.cap)

Фрагмент захвата Ethereal

Фрагмент захвата Commit View

Далее рассмотрим настройку серверной части службы удаленного доступа для Windows Server 2003. В данном семействе операционных систем Служба маршрутизации объединена со службой удаленного доступа и носит название RRAS (Routing & Remote Access Service). Запуск службы маршрутизации подробно рассматривался в предыдущих уроках, рассмотрим особенности запуска связанные с удаленным доступом.

Для включения удаленного доступа активируем соответствующий Checkbox в окне Свойства: Маршрутизация и удаленный доступ. Существует возможность независимо назначить RRAS сервер как маршрутизатором, так и сервером удаленного доступа, причем любое изменение роли сервера может произойти только после рестарта службы RRAS, но при этом все сделанные ранее настройки службы RRAS не теряются, в отличие от остановки сервера с помощью оснастки «Маршрутизация и удаленный доступ к сети».

Далее указываем пул адресов назначаемых при входящих подключениях.

Если нет подключения – порты неактивны.

Порты настраиваются через меню Свойства

В свойствах учетных записей разрешаем входящие соединения используя соответствующую закладку.

После подключения клиента, активируется соответствующий порт

Интерфейс «Внутренний» или Internal маршрутизатора это именно тот интерфейс, который и получил IP адрес 192.168.0.1

В закладке Клиенты удаленного доступа появляется информация об учетной записи, зарегистрировавшейся в системе, длительности подключения и количестве портов используемых для этого подключения т.к. протокол PPP допускает организацию одного логического канала связи состоящего из нескольких физических линий (Multi Link PPPMLPPP).

В таблице маршрутизации появляются записи, соответствующие подключению «точка-точка». Адрес серверного интерфейса 192.168.0.1, клиентского – 192.168.0.2 

 

Информация о сетевых интерфейсах сервера удаленного доступа:

Папка «Ведение журнала удаленного доступа», используется для ведения логов службы RAS.

 

       

Файл журнала, по умолчанию сохраняется в папке c:\windows\system32\LogFiles с именем iaslog.log. Ниже приведен фрагмент файла, содержащего запись об удаленном входе пользователя Administrator в систему (Вход произведен с компьютера Clientcomp в 17:43:20

192.168.12.5,administrator,02/16/2006,17:43:20,RAS,SERVER121,44,13,4,192.168.12.5,6,2,7,1,5,12,61,0,4108,192.168.12.5,4147,311,4148,MSRASV5.20,4160,MSRASV5.10,4159,MSRAS-1-CLIENTCOMP,4155,1,25,311 1 10.1.12.1 02/16/2006 14:10:13 3,4129, SERVER121\administrator, 4130, SERVER121\administrator, 4127, 4,4136,1,4142,0

А так выглядит фал при просмотре в Notepad.exe

Далее рассмотрим конфигурирование в роли клиента удаленного доступа самой службы RRAS. Это применяется, например, для маршрутизатора небольшой офисной сети. Маршрутизатор должен позвонить ISP и через этот маршрутизатор компьютеры из офисной сети будут получать доступ к Интернет, очевидно, в этом случае роль клиента удаленного доступа достается службе маршрутизации. В начале включаем возможность вызова по требованию.

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

Указываем имя создаваемого интерфейса

Выбираем тип создаваемого интерфейса PPTP

Указываем IP удаленного маршрутизатора

Выбираем перенаправление пакетов на данный интерфейс

Добавляем маршрут, который будет соответствовать создаваемому интерфейсу. Т.е. при обращении к данному маршруту, интерфейс будет автоматически активироваться. В нашем случае – это маршрут Default.

Таблица имеет вид

Далее указываем учетную запись для подключения к удаленному маршрутизатору

Интерфейс создан.

К сетевым интерфейсам добавляется вновь созданный интерфейс вызова по требованию, но пока он отключен.

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

Поведение Интерфейса вызова по требованию в зависимости от реакции сети определяется следующими параметрами

В данном случае, если сеть не проявляет активность в течение 5 минут (нет ни одного пакета по маршруту), то соединение разрывается. Время может быть изменено, либо выбрано постоянное подключение.

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

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

Сравним таблицы маршрутизации до- и после- установления соединения по Интерфейсу удаленного доступа.

До установления соединения

И после подключения Интерфейса вызова по требованию

Маршрут «по умолчанию» - на адрес удаленного сервера через IP адрес PPP интерфейса удаленного доступа.

Задание 1

Пусть есть некоторая корпоративная сеть из двух локальных сетей и пользователи, находящиеся в командировке должны получать доступ к ее ресурсам по PSTN или ISDN.

Положим, что есть некоторая корпоративная сеть, с двумя удаленными подразделениями, соединенными с помощью двух маршрутизаторов на базе Windows 2000/2003. С целью упрощения, примем, что эта сеть Ethernet. Компании необходимо обеспечить удаленный доступ некоторых сотрудников в эту сеть, причем подключающиеся должны иметь доступ ко всем узлам корпоративной сети, как в первой подсети, та и во второй. Данная сеть не подключена к Интернет, и проблем, связанных с маршрутизацией пакетов в Интернет не существует. Следовательно, в сети может быть произвольная адресация, но предпочтительным, разумеется, является использование автономных адресов.

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

Задание 2

Есть некоторый ISP, с помощью услуг которого, компьютеры небольшой сети подключаются к Интернет. Компания клиент имеет приобретенный набор допустимых в Интернет адресов.

Требуется описать настройку RRAS сервера, моделирующую

а) маршрутизатор провайдера,

б) маршрутизатор клиента с интерфейсом вызова по требованию

Построить таблицу маршрутизации для случая а) и б) после подключения интерфейса вызова по требованию с учетом возможности обмена пакетами между узлами в Интернет и узлами в сети компании.

Network Address Translation.

Трансляция сетевых адресов.

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

Если компания приобрела,  в соответствии с классовой техникой выделения IP адресов, или в соответствии с техникой CIDR, свой собственный блок IP адресов, то задача решается очевидным образом. В этом случае, компания подключается к сети Интернет через местного провайдера, с помощью некоторой глобальной сетевой технологии (xDSL, коммутируемый канал PSTN или ISDN, выделенная линия связи семейства PDH), а может и локальной сетевой технологии (Ethernet, HomePNA, IEEE 802.11). Каждый узел в сети компании снабжается допустимым в Интернет IP адресом, на границе сетей устанавливается маршрутизатор и после этого любая станция сети компании может обмениваться пакетами с любой станцией в Интернет.

А что, если компания НЕ имеет в своем распоряжении необходимого блока адресов, допустимых в Интернет? В таком случае решение кажется очевидным – этот блок адресов необходимо приобрести. Если бы адресация протокола IPv4 позволяла иметь большое (достаточное) количество адресов, никаких проблем бы не возникало, такие блоки адресов можно было без проблем получить и это ничего бы не стоило или стоимость была бы чисто символической. Но, как известно, адресное пространство IPv4 содержит недостаточное количество адресов, которые могут быть назначены узлам (около 232 – 229 – 225), кроме того, серьезнейшие проблемы породила прежняя, классовая техника назначения адресов, которая, как известно, привела к крайне неэкономичному расходованию адресного пространства. Сегодня ощущается острая нехватка IP адресов, которая приводит к тому, что НЕ желательно предоставлять адреса каждому желающему, кроме того, так как имеется дефицит адресов, то и стоимость получения блока адресов и владения им оказывается заметной с экономической точки зрения. Указанные ссылки, позволяют провести краткий анализ стоимости приобретения и владения адресами для LIR (Local Internet Registry – местных регистраторов адресов), которые предлагает RIR RIPE (http://www.ripe.net/ripe/docs/billing2004.html#3 - полное описание ценовой политики на 2004 год, http://www.ripe.net/ripe/docs/billing2005.html#fee2005 - полное описание ценовой политики на 2005 год).

Ориентировочная стоимость для LIR вступления в партнерство с RIPE - 2500€, ориентировочная стоимость блока адресов /19 – 2000€ в год, при этом цена с каждым годом растет. Таким образом, для LIR адрес стоит в год сегодня порядка ¼ €. При этом такая цена не является ценой для конечного потребителя, эта цена определяется политикой соответствующего LIR. Рассмотрим для примера цены для конечного потребителя, предлагаемые крупным одесским ISP «Фарлеп» (http://www.farlep.net/services/internet/price/price_add.phtml). Стоимость в год блоков адресов:

  •  /24 - 500€, один адрес – 1,95€
  •  /26 - 400€, один адрес – 6,25€
  •  /27 - 300€, один адрес – 9,38€
  •  /28 - 200€, один адрес – 12,50€
  •  /29 - 150€, один адрес – 18,75€

Согласитесь, что для небольшой компании, в которой используется около десятка компьютеров, приобретение блока адресов размером /28 за сумму порядка 200€ в год является, по крайней мере, нежелательным.

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

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

Пусть есть некоторая компания, использующая в своем офисе локальную сеть. Пусть в этой сети применяется автономная адресация. Положим, что компания подключила свой маршрутизатор к местному провайдеру при помощи какой либо глобальной сетевой технологией. Разумеется, внешний интерфейс этого маршрутизатора получит от провайдера некоторый реальный IP адрес (предположим 210.1.2.2) и будет использовать простейшую таблицу маршрутизации, в которой будет только одна строка о том, что все пакеты необходимо перенаправлять на маршрутизатор ISP (предположим 210.1.2.1). При этом в зависимости от того, как сконфигурировал провайдер свой маршрутизатор, интерфейс 210.1.2.2 может иметь маску либо /30 либо /32 (для подключений «точка-точка»), а в таблице маршрутизации может быть одна из двух строк:

 

Сеть получателя   Маска   Шлюз

0.0.0.0    0.0.0.0   210.1.2.1

или

Сеть получателя   Маска   Шлюз

0.0.0.0    0.0.0.0   210.1.2.2

В любом случае это ничего не меняет – маршрутизатор компании должен все пакеты во все сети (кроме подключенной) отправлять на маршрутизатор ISP.

Рассмотрим, что же мешает узлам автономной сети отправлять пакеты в Интернет и получать пакеты в ответ. Положим, что узел 192.168.0.2 хочет отправить пакет для узла 66.7.8.9. Узел 192.168.0.2 может передать данный пакет на маршрутизатор 192.168.0.1, который, вообще говоря, без всяких проблем передаст его маршрутизатору 210.1.2.1. Что произойдет с этим пакетом далее? Для начала зададимся вопросом – может ли этот пакет быть доставлен получателю, т.е. узлу 66.7.8.9? Так как маршрутизация в IP сети происходит лишь на основании адреса получателя пакета, то совершенно очевидно, что данный пакет мог бы легко быть доставлен получателю. А вот может ли быть доставлен пакет в ответ от станции 66.7.8.9 к станции 192.168.0.2? Нет, так как, нам известно, что автономные адреса, к числу которых принадлежит 192.168.0.2, не допустимы к применению в Интернет. Это значит, что магистральные маршрутизаторы Интернет не имеют маршрутов в сети, называемые автономными и как следствие пакеты от 66.7.8.9 к 192.168.0.2 доставлены быть не могут. А так как пакеты к станции с автономным адресом в любом случае доставлены быть не могут, то маршрутизаторы Интернет не обслуживают пакеты и с адресами отправителей, принадлежащими автономным сетям, так как обслуживание таких пакетов есть просто заполнение Интернет лишним трафиком, которые дополнительно нагружает линии связи и маршрутизаторы. Поэтому маршрутизаторы провайдеров обычно фильтруют трафик, адрес отправителя которого принадлежит автономным диапазонам. Поэтому обычно и пакет от 192.168.0.2 к 66.7.8.9 не будет доставлен. При этом разные провайдеры поступают по-разному – некоторые проводят такую фильтрацию уже на первом маршрутизаторе, некоторые – на выходе из своей сети – это зависит от того, как сконфигурировал свою систему ISP.

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

Обратите внимание, что у компании все же есть один реальный адрес в Интернет, это адрес, полученный внешним интерфейсом маршрутизатора компании от провайдера: 210.1.2.2. Нельзя ли воспользоваться этим адресом, для того, чтобы обеспечить взаимодействие узлов автономной сети с узлами Интернет? Известно, что маршрутизатор, перенаправляя пакеты, не меняет в них адреса отправителя и получателя (за исключением обработки пакетов с опциями SSRR/LSRR). А что, если наш офисный маршрутизатор будет перенаправлять пакеты маршрутизатору ISP, заменяя адрес отправителя, который является автономным и недопустимым для применения в Интернет на свой реальный адрес 210.1.2.2? Очевидно, это не сложно для программного обеспечения маршрутизатора, он все равно меняет поле TTL IP заголовка и пересчитывает контрольную сумму заголовка. Решит ли это нашу проблему? Итак, станция 192.168.0.2 формирует IP пакет для станции 66.7.8.9, а маршрутизатор компании, получая такой пакет, перенаправляет его, установив в качестве адреса отправителя адрес 210.1.2.2. Сможет ли такой пакет пересечь Интернет и достичь узла 66.7.8.9? Безусловно, сможет. Сможет ли приложение на узле 66.7.8.9 сформировать ответ на этот пакет? Да, конечно. Сможет ли такой пакет пересечь Интернет и достичь своего получателя? Это и есть самый главный вопрос! Кто, по мнению станции 66.7.8.9 является отправителем исходного пакета? Станция 210.1.2.2. Именно для 210.1.2.2 будет сформирован пакет с ответом от приложения станции 66.7.8.9 и, разумеется, такой пакет достигнет сквозь Интернет своего получателя, но при этом– получателем пакета является интерфейс 210.1.2.2. Итак, из автономной сети можно передать пакет станции в Интернет, но ответ на него получит станция 210.1.2.2, а не та станция, которая на самом деле должна получить пакет. Может показаться, что в этом нет никакой проблемы – маршрутизатор компании может передать пакет истинному получателю в автономной сети – во внутренней сети нет запрета на использование автономных адресов. Но проблема все же есть: ОТКУДА маршрутизатор компании ЗНАЕТ, КОМУ в своей сети необходимо передать данный пакет??? Именно это и есть главная проблема при осуществлении данного взаимодействия. Вообще, проблемы почти нет, если в автономной сети всего один узел, но это противоречит условиям нашей задачи.

Итак, вопросом: на основании чего маршрутизатор компании может принять решение о том, кому передать пришедший IP пакет (какому из узлов в своей автономной сети). При этом, не стоит забывать, что интерфейс маршрутизатора 210.1.2.2 САМ может выступать в роли получателя IP пакетов. Т.е., когда на маршрутизатор, работающий по рассматриваемой нами схеме поступает пакет, адресованный на сетевом уровне ему, он должен сначала принять решение, не ему ли на самом деле предназначен данный пакет, а затем при необходимости принять решение о том, кому в автономной сети передать данный пакет.

Очевидно, что когда маршрутизатор переправляет пакет из автономной сети в Интернет с подстановкой своего адреса в качестве адреса отправителя, из пакета ПОЛНОСТЬЮ теряется информация о том, кто его на самом деле послал. А когда на этот пакет приходит ответ, то в нем и подавно нет информации о том, кому в автономной сети его необходимо передать. Следовательно, маршрутизатору необходимо, отправляя  пакет в Интернет с заменой адреса отправителя, запоминать об этом пакете ЧТО-ТО, что впоследствии, когда придет «пакет – ответ» позволит маршрутизатору понять, кому его перенаправить в автономной сети. Что маршрутизатор может запомнить из перенаправляемого в Интернет пакета ТАКОГО, что позволит перенаправить потом пакет с ответом? Очевидно, первое, что приходит в голову – это адрес получателя. Положим, что станция 192.168.0.2 отправила через наш маршрутизатор пакет для  станции 1.1.1.1, а станция 192.168.0.3 – для станции 2.2.2.2. Маршрутизатор перенаправил оба пакета в Интернет, подставив в качестве адреса отправителя, пакета свой адрес 210.1.2.2 и создал в своей памяти следующую таблицу:

192.168.0.2  -> 1.1.1.1

192.168.0.3 -> 2.2.2.2

Теперь, если из Интернета придет пакет ОТ станции 1.1.1.1 он будет перенаправлен к станции 192.168.0.2, а если придет пакет от 2.2.2.2 – его нужно перенаправить станции 192.168.0.3, изменив адрес получателя в пришедшем пакете. Такая схема кажется функциональной только на первый взгляд: а что, если две станции, 192.168.0.2 и 192.168.0.3 отправят пакеты одной и той же станции в Интернет, например 1.1.1.1? Тогда у маршрутизатора будет следующая таблица соответствий:

192.168.0.2  -> 1.1.1.1

192.168.0.3 -> 1.1.1.1

И если приходит пакет от станции 1.1.1.1, то совершенно не понятно, кому же его передать. Это значит, что при таком стиле работы к одному узлу в Интернет сможет обратиться только один узел автономной сети, а пакеты остальных узлов не имеет смысла перенаправлять в Интернет, так как после этого даже один узел автономной сети не сможет обмениваться пакетами с данным узлом в Интернет. Разумеется, взаимодействие, функционирующее таким образом, не является приемлемым решением. Что же еще можно такого добавить в эту таблицу соответствий, которую будет вести маршрутизатор, что помогло бы маршрутизатору понять, кому в автономной сети передавать поступившие на маршрутизатор пакеты?

Проанализируем остальные поля IP заголовка, которые можно было бы использовать для этой цели. Очевидно, что значение ни одного из полей IP заголовка (VER, IHL, TOS, Total Length, ID, Flags, Offset, TTL, Protocol, Checksum) НЕ может служить тем индикатором, который можно использовать для запоминания маршрутизатором, перенаправляющим пакет в Интернет с заменой адреса отправителя, с целью анализа поступивших пакетов на предмет выявления их истинных адресатов.

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

Однако, не все так печально. На самом деле, обращение к ресурсам в Интернет для пользователей и не нуждается в маршрутизации ПРОИЗВОЛЬНОГО IP трафика. Известно, что приложения, которые обмениваются по сети данными, никогда не инкапсулируют свои данные непосредственно в IP пакеты. Поле Protocol заголовка IP столь невелико (1 байт), что адресовать с помощью этого поля приложения не возможно. Кроме того, протокол IP выполняет лишь сетевые функции, но не гарантирует доставку пакетов, а при изучении модель OSI, говорилось о том, что приложениям, передающим значительные потоки данных не выгодно самим заниматься вопросами квитирования данных, для решения этой задачи в модели OSI есть транспортный уровень. Хотя протоколы уровня выше, чем третий не являются предметом данного курса, сейчас исключительный случай – рассмотрим материал следующего курса, а именно - как происходит адресация приложений на узлах.

Все прикладные протоколы, которые существуют в стеке TCP/IP, можно условно разделить на два класса – те, которые не нуждаются в гарантиях доставки данных, и те, которые, напротив, в этом нуждаются.

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

Напротив, если приложение в силу своей специфики, отправляет значительные объемы данных, на которые не получает прикладных ответов (например, приложение передает файл размером 10 Мбайт, пока файл передается, никакие прикладные данные в обратном направлении не отправляются), оно нуждается в том, чтобы некоторый сетевой компонент (выполняющий функции транспортного уровня) гарантировал доставку пакетов путем отправки квитанций.

Функциями гарантирования доставки пакетов описывались в Курск Локальные сети (протокол LLC, например). В этом протоколе реализованы функции, позволяющие работать как с приложениями, как нуждающимися в гарантиях доставки, так и с приложениями, в этих функциях не нуждающимися. В отличие от одного протокола LLC, умеющего работать в двух режимах в стеке TCP/IP используется два различных протокола: TCP и UDP. Первый обеспечивает приложениям гарантии доставки пакетов, второй – работает без гарантий доставки. Если в IP пакете находится пакет UDP, поле протокол IP заголовка принимает значение 17, если  в IP пакете находится пакет TCP, поле протокол IP заголовка принимает значение 6. ВСЕ приложения стека TCP/IP кладут свои данные либо поверх TCP, либо поверх UDP заголовка, но никогда не поверх IP заголовка. Следовательно, нет необходимости обеспечивать передачу из автономной сети и назад ПРОИЗВОЛЬНЫХ IP пакетов, достаточно обеспечить передачу UDP и TCP пакетов. Разумеется, кроме этого необходимо обеспечить также и обмен ICMP пакетами (поле Protocol = 1). Так что если невозможно реализовать обмен произвольными IP пакетами через маршрутизатор, подменяющий в отправляемых IP пакетах адрес отправителя (из-за отсутствия в IP заголовке необходимых полей), то можно попытаться обеспечить, по крайней мере, обмен IP пакетами, содержащими в себе ICMP, TCP и UDP. Таким образом, для каждого из этих протоколов, необходимо произвести анализ его собственного заголовка в поисках таких полей, запоминание значения которых в отправляемых пакетах помогло бы маршрутизатору правильно возвращать пакеты с ответами истинным получателям. 

Начнем с протоколов TCP и UDP, затем перейдем к ICMP. Оба эти протокола должны иметь в себе функции для адресации приложений, вложивших в них свои данные. У обоих протоколов первое четырехбайтовое слово заголовка совпадает и содержит в себе два двухбайтовых поля: Source Port и Destination Port. Эти поля и есть адреса приложений, обменивающихся данными, как следует из названия Source Port – это адрес приложения, пославшего пакет (на компьютере отправителе), а Destination Port – адрес приложения, которое должно получить данные (на компьютере получателе). Так как поля Port двухбайтовые, то с их помощью можно адресовать до 65536 различных приложений, что является приемлемым количеством, в отличие от 256 протоколов адресуемых полем протокол IP пакета.

Рассмотрим, каким образом приложения получают номера портов. Предположим, что пользователь хочет обратиться к файловому серверу, расположенному на некотором узле. Для этого пользователю необходимо знать IP адрес узла, чтобы сформировать для него пакеты с запросами прикладного протокола (или его имя, которое перед началом взаимодействия будет просто преобразовано в IP адрес, пока на этом останавливаться нет смысла). Как мы уже говорили ранее, для обращения пользователя к некоторой службе выполняемой на удаленном компьютере, необходимо знать адрес (например IP) этого компьютера. Но знания адреса узла недостаточно: на этом узле может быть запущено множество приложений, например: WEB сервер, файловый сервер, почтовый сервер и т.д. Для того, чтобы передать запрос нужной службе, отправителю необходимо знать номер порта, который занимает та или иная служба на сервере, IP адрес которого пользователю известен. Но с другой стороны было бы неудобно нагружать пользователя необходимостью запоминания некоторого, совершенно абстрактного для пользователя числа. Например, для того, чтобы не заставлять пользователя запоминать IP адреса существует несколько служб имен, которые позволяют пользователю запоминать понятные для него имена узлов, а для того, чтобы не заставлять пользователя запоминать номера портов служб, к которым он хочет обратиться применяется следующая техника, называемая «Хорошо известные порты». За каждой службой или серверным приложением стека TCP/IP закрепляется ОДИН единственный порт, например, файловая служба TCP/IP (FTP) использует порт TCP 21. Пользователю не нужно помнить это значение, когда пользователь запускает программу FTP клиент (пользователь же не руками генерирует пакеты протокола FTP), эта программа УЖЕ знает (это сделал программист, создавший данную программу), что служба FTP занимает на сервере именно 21 порт. Следовательно, пользователю остается только знать имя узла и использовать соответствующую программу клиент (снова таки, пользователь не станет пытаться скачивать файлы почтовой программой ). Такая схема, казалось бы, накладывает ограничение на количество служб одного типа, работающих на одном компьютере – так как, на данном узле, существует только один порт TCP 21 (а иначе в чем ценность адреса, отделяющего одно приложение от другого, если он не уникален в пределах одного узла) и, следовательно, только один файловый сервер. На самом деле это не совсем так: никто не мешает установить на одном узле много FTP серверов, но только один, разумеется, сможет занимать порт TCP 21, а остальные FTP сервера на данном узле могут занимать другие порты. Но, при обращении к данному компьютеру, с помощью стандартного FTP клиента, пользователи получат доступ только к той службе, которая расположена на 21 порту. Для доступа к остальным FTP серверам на узле пользователю необходимо точно знать номер порта, который они занимают, кроме того, клиентская программа должна позволять пользователю явно указывать номер порта, к которому следует обратиться. В этом смысле, техника «Хорошо известных портов» позволяет иметь на одном компьютере (точнее, интерфейсе) одну «упрощенно адресуемую» службу каждого типа и произвольное количество служб данного типа, адресуемых явно по номеру порта, указываемого пользователем. Обычно, хорошо известные порты занимают номера с 0 до 1023. Но более детально речь об этом пойдет в следующем курсе.

Итак, представление о том, каким образом, адресуются серверные приложения - существует. Теперь несколько слов об адресации клиентские приложения. За клиентским приложением нет необходимости резервировать какой-то порт . Так же, как станция из полученного запроса узнает IP адрес того, кто к ней обратился, так же она может узнать и номер порта того приложения, которое обратилось к серверному приложению (т.е. из заголовка полученного пакета четвертого уровня). Поэтому, клиентские приложения выбирают себе произвольные незанятые номера портов, используя для этого номера портов, начиная с 1024, называемые «динамическими».

Итак, типовое взаимодействие любого приложения, независимо от того, использует ли оно TCP или UDP происходит следующим образом: клиентское приложение с некоторого динамического порта отправляет пакет на известный IP адрес сервера на хорошо известный (клиентскому приложению) порт на сервере. Серверное приложение будет отправлять пакеты с ответами на тот IP адрес, который был адресом отправителя в исходном IP пакете, на тот порт, который был Source Port в исходном IP пакете.

Далее рассмотрим, как все это можно применить для решения задачи: как маршрутизатор, отправляя пакет с заменой адреса на свой собственный адрес, сможет впоследствии возвращать «пакеты – ответы» истинному получателю на основании запоминания каких-то полей в отправляемых пакетах.

Если использовать для этой цели заголовок IP пакета, создавая таблицу вида:

192.168.0.2  -> 1.1.1.1

192.168.0.3 -> 2.2.2.2

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

Для начал рассмотрим использование поля заголовка TCP/UDP Destination Port. Пусть станция 192.168.0.2 обратилась к узлу 1.1.1.1, точнее к WEB серверу на этом узле, а станция 192.168.0.3 – к тому же узлу 1.1.1.1, но к почтовому серверу. Тогда станция 192.168.0.2 отправляет пакет с адресом получателя 1.1.1.1 и портом получателя 80, а станция 192.168.0.3 – с адресом получателя 1.1.1.1 и портом получателя 25. Таблица, которую запомнил маршрутизатор на основании анализа данных пакетов, будет иметь вид:

192.168.0.2  -> 1.1.1.1 TCP 80

192.168.0.3 -> 1.1.1.1 TCP 25

Если на маршрутизатор поступит пакет от станции 1.1.1.1 с портом отправителя 80, то такой пакет нужно передать станции 192.168.0.2, а если порт отправителя будет равен 25, то пакет нужно передать станции 192.168.0.3. Уже лучше, но что если обе станции из автономной сети обратятся к WEB серверу на станции 1.1.1.1? Тогда таблица будет иметь вид:

192.168.0.2  -> 1.1.1.1 TCP 80

192.168.0.3 -> 1.1.1.1 TCP 80

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

Пусть маршрутизатор так же заносит в таблицу и сведения о том, С КАКИХ  портов обращались приложения на станциях 192.168.0.2 и 192.168.0.3.

Пусть приложение на станции 192.168.0.2 обратилось к WEB серверу на узле 1.1.1.1 с порта 1078, а приложение на станции 192.168.0.3 – к WEB серверу на узле 1.1.1.1 с порта 1099. Тогда, станция 192.168.0.2 отправляет пакет с адресом получателя 1.1.1.1, портом отправителя 1078 и портом получателя 80, а станция 192.168.0.3 – с адресом получателя 1.1.1.1, портом отправителя 1099 и портом получателя 80 (порты отправителей выбираются «почти» случайным образом на данном узле). Тогда,  таблица, которую запомнил маршрутизатор на основании анализа данных пакетов, будет иметь вид:

192.168.0.2  -> 1.1.1.1 TCP 80 1078

192.168.0.3 -> 1.1.1.1 TCP 80 1099

Если на маршрутизатор поступит пакет от станции 1.1.1.1 с портом отправителя 80 и портом получателя 1078, то такой пакет нужно передать станции 192.168.0.2, а если порт отправителя будет равен 80, но порт получателя 1099, то в этом случае пакет нужно передать станции 192.168.0.3. Таким образом, то, что получилось уже можно считать эффективным результатом. Но что если обе станции из автономной сети обратятся к WEB серверу на станции 1.1.1.1, СЛУЧАЙНО выбрав себе в качестве портов отправителей ОДИНАКОВЫЕ динамические порты? Как ясно из вышесказанного, номер порта является уникальным на данной станции для каждого приложения, но не между всеми приложениями составной сети. Тогда таблица будет иметь вид:

192.168.0.2  -> 1.1.1.1 TCP 80 1056

192.168.0.3 -> 1.1.1.1 TCP 80 1056

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

Как быть?

Для того, чтобы избежать возможности появления такой ситуации, маршрутизатор может поступать следующим образом: если на маршрутизатор из автономной сети поступает пакет в Интернет, такой, что строка в таблице соответствий, которую придется дописать для правильной пересылки ответа на данный пакет полностью совпадает (с точностью до IP адреса из автономной сети) с уже существующей в таблице записью, то маршрутизатор перенаправляет этот пакет ИЗМЕНИВ порт отправителя таким образом, чтобы совпадения не было. При этом станция в Интернет, разумеется, пришлет свой ответ на этот новый порт и перед отправкой такого пакета истинному получателю маршрутизатору необходимо обратно изменить номер порта на тот, на котором ожидает ответа станция в автономной сети. Для этого в таблицу соответствий необходимо внести еще один столбец (помимо порта получателя и порта отправителя, взятых из пакета, поступившего из автономной сети) – порт, от имени которого маршрутизатор послал пакет узлу в Интернет.

Рассмотрим это на примере:

Пусть приложение на станции 192.168.0.2 обратилось к WEB серверу на узле 1.1.1.1 с порта 1044, и приложение на станции 192.168.0.3 тоже обратилось к WEB серверу на узле 1.1.1.1 и так получилось, что тоже с порта 1044. Т.е.  станция 192.168.0.2 отправляет пакет с адресом получателя 1.1.1.1, портом отправителя 1044 и портом получателя 80,  станция 192.168.0.3 – с адресом получателя 1.1.1.1, портом отправителя 1044 и портом получателя 80. Маршрутизатор отправляет пакет станции 192.168.0.2, заменив в этом пакете IP адрес отправителя на свой, от имени порта 1044, а пакет станции 192.168.0.3, заменив в этом пакете IP адрес отправителя на свой, от имени порта 1045. Таблица, которую запомнил маршрутизатор на основании анализа данных пакетов, будет иметь вид:

192.168.0.2  -> 1.1.1.1 TCP 80 1044   1044

192.168.0.3 -> 1.1.1.1 TCP 80 1044   1045

Теперь, если на маршрутизатор поступит пакет от станции 1.1.1.1, от 80 порта на порт 1044, маршрутизатор перенаправит это пакет в автономную сеть с IP адресом получателя 192.168.0.2 и номером порта получателя 1044. А если на маршрутизатор поступит пакет от станции 1.1.1.1, от 80 порта на порт 1045, маршрутизатор перенаправит это пакет в автономную сеть с IP адресом получателя 192.168.0.3 и номером порта получателя 1044.

Какие недостатки еще можно отметить, которые потенциально могут снова привести к неработоспособности данной схемы?

Как было сказано выше, на каждом узле может работать не более 65536 приложений, не требующих гарантий доставки и не более 65536 приложений, нуждающихся в гарантиях доставки, это связано с количеством различных значений, которые могут принимать двухбайтовые поля «Port». Но теперь все приложения ВСЕЙ автономной сети получают различные номера портов на интерфейсе маршрутизатора, т.е. ВО ВСЕЙ автономной сети, а не на каждом узле может работать не более 65536/65536 различных приложений обоих типов, по крайней мере, с одной внешней службой на одном определенном удаленном узле. Хоть это число достаточно велико не только для отдельно взятого узла, но и для всей сети в целом, тем не менее, в крупных сетях это теоретически может стать узким местом сети. Эта проблема решается, тем не менее, достаточно просто – внешнему интерфейсу маршрутизатора можно присвоить не один, а несколько «честных» адресов, и, соответственно, с каждым из этих адресов можно использовать соответствующее количество портов.

Из вышесказанного следует, что  при любом раскладе маршрутизатор сможет вернуть истинному получателю пакеты, которые он должен получить от узлов Интернет, при условии, что маршрутизатор работает в соответствии с рассмотренной выше логикой. При этом, речь не идет о возможности обмена IP пакетами произвольного содержания для взаимодействий, инициированных из автономной сети, а лишь об обмене такими IP пакетами, которые содержат в себе TCP/UDP пакет. Концепция портов в протоколах TCP и UDP полностью идентична, так что все, что было сказано выше о TCP, можно идентично реализовать и для UDP. Тем более что в таблице соответствия существует столбец о протоколе. Для взаимодействий по протоколу UDP  в этом столбце будет указан протокол UDP и маршрутизатор не запутается при передаче в автономную сеть пакетов, поступивших из Интернета.

Однако задача еще не полностью решена – также необходимо обеспечить работу протокола ICMP через такой маршрутизатор. По крайней мере, работу сообщений некоторых важных типов.

Разделим ICMP сообщения на три категории:

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

 

Выделим обязательные для реализации ICMP сообщения:

  •  Сообщения типа 0 и 8  – без этого диагностика сетевых проблем будет невозможна
  •  Сообщения типа 3 со всеми кодами – это очень полезно и важно для эффективной работы приложений
  •  Сообщения типа 11 со всеми кодами – без этого диагностика сетевых проблем будет невозможна
  •  Сообщения типа 12 со всеми кодами – тоже весьма желательно

Не обязательные, но желательные для реализации ICMP сообщения:

  •  Сообщения типа 4, так как такой способ управления потоком сегодня обычно не используется
  •  Сообщения типа 13 и 14  
  •  Сообщения типа 17 и 18, эти сообщения практически не используются

Не нужные к реализации сообщения:

  •  Сообщения типа 5, они никогда не пересекают маршрутизаторы
  •  Сообщения типа 9 и 10, та же причина  
  •  Сообщения типа 15 и 16, та же причина

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

  •  те сообщения, которые посылаются в ответ на некоторый IP пакет произвольного содержания (например, сообщения типа 3, 4, 11, 12), т.е. в основном сообщения об ошибках.
  •  те сообщения, которые используют посылку запросов и получение на них ответов с применением полей ID и Sequence Number для идентификации полученных ответов (например, сообщения типа 0/8, 13/14, 17/18).

Сообщения первого вида приходят из Интернета в ответ на некоторые пакеты, посланные нашими узлами из автономной сети. При этом в пакете, напомним, цитируется IP заголовок того пакета, в ответ на который посылается данный ICMP пакет и 8 байт данных.  А поля Source Port и Destination Port расположены в первых четырех байтах пакета, следовательно, маршрутизатор, получив ICMP сообщение об ошибке, из тела данных принятого ICMP пакета получает все ключевые атрибуты, по которым сможет в рассмотренной выше хранимой таблице для перенаправления TCP/UDP пакетов найти соответствующую информацию о том, кому в автономной сети перенаправить данное ICMP сообщение.

Рассмотрим пример, пусть у маршрутизатора есть созданная таблица перенаправлений:

192.168.0.2  -> 1.1.1.1 TCP 80 1044   1044

192.168.0.3 -> 1.1.1.1 TCP 80 1044   1045

На маршрутизатор поступает ICMP сообщение от некоторого произвольного транзитного маршрутизатора, которое содержит в себе пакет типа 3 с кодом 1 (сеть недостижима). В этом пакете частично цитируется уничтоженный исходный IP пакет, из его IP заголовка видно, что это был пакет от 210.1.2.2 к 1.1.1.1, а из первых восьми байт данных, которые на самом деле являются  заголовком TCP, видны порты отправителя и получателя: 1045 и 80. Очевидно, что ICMP пакет с цитируемым IP сообщением от 210.1.2.2:1045 к 1.1.1.1:80 необходимо перенаправить станции 192.168.0.3, причем заменить в цитируемом заголовке IP пакета адрес отправителя обратно на 192.168.0.3, а порт отправителя на 1044. Таким образом, хранимая таблица для перенаправлений TCP и UDP полностью пригодна и для возвращения в автономную сеть ICMP сообщений об ошибках, сгенерированных маршрутизаторами и узлами в Интернет.

Сообщения второго вида так же легко маршрутизировать с помощью рассматриваемой нами техники. В этих сообщениях присутствуют два двухбайтовых поля ID и Sequence Number, которые маршрутизатор может запоминать в отправляемых пакетах, а, так как они цитируются в получаемых пакетах, то на основании пары ID/Sequence Number, можно организовать возврат пакета истинному получателю. И при случайном совпадении пары ID/Sequence Number маршрутизатор может поступать с этими полями так же, как и с портом отправителя TCP/UDP, т.е. заменять в отправляемых пакета и возвращать исходные значения в получаемых ответах.

Рассмотрим примеры.

Пример № 1. Пусть нет необходимости замены номеров. Станция 192.168.0.2 послала Echo запрос станции 1.1.1.1, ID=512, Sequence Number=3445, станция 192.168.0.3 тоже послала пакет для 1.1.1.1, ID=256, Sequence Number=7898. Тогда таблица перенаправлений для маршрутизатора примет вид:

192.168.0.2  -> 1.1.1.1 ICMP 512 3445   3445

192.168.0.3 -> 1.1.1.1 ICMP 256 7898   7898

Если теперь на порт маршрутизатора 210.1.2.2 поступит Echo ответ от станции 1.1.1.1 с ID=512 и Sequence Number=3445, то такой пакет нужно перенаправить станции 192.168.0.2 с такими же значениями полей ID/Sequence Number. А если на порт маршрутизатора 210.1.2.2 поступит Echo ответ от станции 1.1.1.1 с ID=256 и Sequence Number=7898, то такой пакет нужно перенаправить станции 192.168.0.3, так же, не изменяя значения полей ID/Sequence Number.

Пример № 2. Пусть станция 192.168.0.2 послала Echo запрос станции 1.1.1.1, ID=1024, Sequence Number=5445, и станция 192.168.0.3 послала Echo запрос станции 1.1.1.1, причем так случай но совпало, что поля ID/Sequence Number приняли те же значения, что и в пакете от станции 192.168.0.2, т.е. ID=1024, Sequence Number=5445. Тогда маршрутизатор пересылает эхо запрос станции 192.168.0.2 в Интернет, заменяя лишь обратный IP адрес, а пакет от 192.168.0.3 пересылается с заменой не только IP адреса получателя, но и с заменой, например Sequence Number на 5446.

Тогда таблица перенаправлений для маршрутизатора примет вид:

192.168.0.2  -> 1.1.1.1 ICMP 1024 5445   5445

192.168.0.3 -> 1.1.1.1 ICMP 1024 5445   5446

Если теперь на порт маршрутизатора 210.1.2.2 поступит Echo ответ от станции 1.1.1.1 с ID=1024 и Sequence Number=5445, то такой пакет нужно перенаправить станции 192.168.0.2 с такими же значениями полей ID/Sequence Number. А если на порт маршрутизатора 210.1.2.2 поступит Echo ответ от станции 1.1.1.1 с ID=1024 и Sequence Number=5446, то такой пакет нужно перенаправить станции 192.168.0.3, при этом в поле Sequence Number установить значение 5445.

Итак, для взаимодействий, инициированных из автономной сети, наш маршрутизатор позволяет обеспечить прозрачный обмен TCP/UDP/ICMP трафиком.

Рассмотренная нами технология, называемая «Трансляция сетевых адресов» или NAT (Network Address Translation), а маршрутизатор, поддерживающий данную технологию, называют маршрутизатором с поддержкой NAT или просто NAT маршрутизатором.

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

Очевидно, что пользователи из Интернет смогут обратиться только к реальному IP адресу, т.е. 210.1.2.2 в нашем примере. И, как известно, на этом интерфейсе WEB сервера нет и порт 80 свободен. При этом, возможно внести в таблицу перенаправлений маршрутизатора что вроде «статической записи», примерно следующего смысла: все пакеты, поступающие на 210.1.2.2 на порт 80 перенаправлять на 192.168.0.4 на порт 80:

192.168.0.4  -> any TCP any 80 80  

Тогда, все пакеты, поступающие с любого адреса с любого порта на адрес 210.1.2.2 на порт 80, перенаправляются на 192.168.0.4 на порт 80, и таким образом любое обращение к WEB серверу на порту 80 интерфейса 210.1.2.2 приведет к пересылке пакета на 80 порт узла 192.168.0.4. Такая технология создания статического перенаправления для взаимодействий, инициированных из Интернет в автономную сеть, является второй половинкой технологии NAT, ее называют мэппинг портов (port mapping), кроме того, иногда ее еще называют технологией трансляции портов, или PAT (Port Address Translation).

Существуют ли ограничения данной технологии? Так как у внешнего интерфейса нашего маршрутизатора может быть только один порт с одним номером, это означает, возможность объявления в автономной сети только одной, доступной из Интернета, службы одного типа на хорошо известном порту. Например, если все пакеты, поступающие на 80 TCP порт нашего маршрутизатора перенаправляются на 80 TCP порт станции 192.168.0.4. Это значит, что в автономной сети не может существовать еще один WEB сервер на 80 порту с возможностью доступа к нему из Интернет. При этом, возможно иметь в автономной  сети доступными из Интернет множество WEB серверов, делая мэппинг различных портов интерфейса 210.1.2.2, но тогда эти WEB сервера будут доступны из Интернет на различных портах, например:

192.168.0.4  -> any TCP any 80 80  

192.168.0.5  -> any TCP any 81 80  

192.168.0.6  -> any TCP any 82 80  

192.168.0.7  -> any TCP any 83 80  

Является ли данная проблема неразрешимой? Суть проблемы в том, что с одним IP адресом может быть связан только один порт с одним номером. Следовательно, если присвоить внешнему интерфейсу маршрутизатора несколько IP адресов, то, с каждым из них, станет возможно связать 80 порт. И тогда, так же станет возможно, предоставить в автономной сети, доступными из Интернет, столько служб одного типа, работающих на хорошо известных портах, сколько реальных IP адресов будет иметь внешний интерфейс NAT маршрутизатора.

192.168.0.4  -> 210.1.2.2 any TCP any 80 80  

192.168.0.5  -> 210.1.2.3 any TCP any 80 80

192.168.0.6  -> 210.1.2.4 any TCP any 80 80

192.168.0.7  -> 210.1.2.5 any TCP any 80 80

Таки образом, рассмотренная технология «Трансляции сетевых адресов» NAT, позволяет решить следующие задачи:

  •  Обеспечить прозрачный обмен ICMP, TCP и UDP трафиком для взаимодействий, инициированных из автономной сети в Интернет.
  •  Обеспечить возможность доступа из Интернет к ресурсам внутри автономной сети, но при этом количество служб одного типа, работающих на хорошо известных портах не может превысить количества «честных» IP адресов, которыми располагает внешний интерфейс NAT маршрутизатора.

Помимо решения данных важнейших задач технология NAT позволяет получить дополнительные преимущества:

  •  Применение NAT позволяет отчасти снять проблему нехватки IP адресов, так как теперь для подключения к Интернет сеть может задействовать только один или несколько честных IP адресов.
  •  Применение NAT скрывает внутреннюю структуру частной сети, затрудняет доступ к ее ресурсам извне и поэтому может использоваться для повышения безопасности сети предприятия, подключенной к Интернет через NAT маршрутизатор.

Есть ли недостатки у технологии NAT или все так хорошо, как кажется на первый взгляд? Есть - и очень серьезные.

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

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

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

Далее рассмотрим конфигурирование поддержки NAT в маршрутизаторе на базе Windows 2003 Server на примере:

Сконфигурируем маршрутизатор таким образом, чтобы пакеты из сети с автономными адресами поступали на станцию с честными адресами таким образом, чтобы станция 1.1.1.2 не знала, что обменивается пакетами со станцией с автономным адресом. Для этого необходимо добавить поддержку протокола NAT в маршрутизатор, добавить оба интерфейса в папку NAT,  сконфигурировать интерфейс 192.168.0.1 как внутренний, а интерфейс 1.1.1.1 как внешний.

Шаг 1

Добавляем новый протокол маршрутизации – NAT.

Шаг 2

Добавляем и конфигурируем интерфейсы

Шаг 3

Выбираем первый интерфейс, подключенный во внутреннюю (частную) сети, и производим соответствующую настройку.

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

Для внешнего интерфейса необходимо так же настроить Пул адресов. Т.е. диапазон IP адресов, от имени которых, будет производиться передача пакетов во внешнюю сеть. В рассматриваемом примере это один IP адрес 1.1.1.1. Для этого используется соответствующая закладка в Свойствах NAT интерфейса:

После добавления интерфейсов консоль управления NAT имеет вид

В случае если частной сетью NAT является сеть, подключенная через интерфейс удаленного доступа, тогда используется следующая настройка

И тогда после добавления интерфейсов консоль управления NAT имеет вид

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

Тот же трафик, но со стороны станции 1.1.1.2

При взаимодействии станции 192.168.0.2 со станцией 1.1.1.2 образуется следующая таблица сопоставлений

Таблица содержит информацию о каждом сеансе и его длительности.

Теперь перейдем к конфигурации трансляции портов. Пусть в частной сети 192.168.0.0 находится WEB сервер на станции 192.168.0.2. Необходимо предоставить доступ к WEB серверу из внешней сети.

Выбираем трансляцию портов для службы WEB во внутренней сети

Поле «Общий адрес» указывает IP адрес внешнего интерфейса, который используется для прослушивания запросов из внешней сети.

Поле «Входящий порт» указывает номер порта  внешнего интерфейса, на который ожидается получение запроса из внешней сети. В рассматриваемом примере это порт WEB – т.е. TCP номер 80.

Поле «Адрес в частной сети» указывает IP адрес интерфейса в частной сети, на который перенаправится пакет, пришедший из внешней сети на 80-й порт внешнего интерфейса. В рассматриваемом примере это адрес WEB сервера 192.168.0.2.

Поле «Исходящий порт» указывает номер порта  интерфейса во внутренней сети, на который перенаправится пакет, полученный из внешней сети на порт внешнего интерфейса. В рассматриваемом примере это порт WEB – т.е. TCP номер 80.

Рассмотрим поэтапно взаимодействие станции во внешней сети и WEB сервера в частной сети.

1. Станция 1.1.1.2 со своего порта 1051 посылает запрос на 1.1.1.1 порт 80 (http)

2. Маршрутизатор транслирует запрос во внутреннюю сеть запрос от имени станции 1.1.1.2 и от имени её же порта 1051 т.к. такая возможность существует – порт не занят. Запрос отправляется в соответствии с настройками на 192.168.0.2 порт 80.

3. Станция 192.168.0.2 отвечает со своего порта 80 на адрес 1.1.1.2 порт 1051 и отправляет пакет на шлюз (маршрутизатор NAT/PAT)

4. Маршрутизатор транслирует пакет во внешнюю сеть от своего имени ( IP адреса) с порта 80 TCP на порт 1051 TCP станции 1.1.1.2 в соответствии с виртуальной таблицей PAT хранящейся в памяти маршрутизатора.

Таким образом, взаимодействие состоялось.

Задание 1

В соответствии со схемой смоделировать подключение небольшого офиса к провайдеру, предоставляющему доступ к ресурсам Интернет, при чем в сети компании используются автономные адреса.  Обеспечить узлам из автономной сети доступ к узлам, расположенным в Интернет, при этом в той части сети, которая имитирует Интернет не должно быть трафика с автономными адресами. Так же необходимо обеспечить доступ из Интернет к WEB серверу, расположенному на узле автономной сети (WEB сервер использует порт – TCP 80). В сети, которая имитирует Интернет  не должно быть трафика с автономными адресами.

Указать компьютеры, на которых предполагается настройка NAT и/или PAT. Привести примерные конфигурации.

Задание 2

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

Указать компьютеры, на которых предполагается настройка RAS, NAT и/или PAT. Привести примерные конфигурации.


 

А также другие работы, которые могут Вас заинтересовать

36574. Структурный тип массив. Обработка массивов 31 KB
  Такие операторы присваивания могут использоваться для копирования одного массива в другой. Однако над массивами не определены отношения. Кроме того, в Турбо Паскале нельзя использовать выражения над массивами.
36575. Структурный тип маcсив. Описание мас и доступ к эл мас 33 KB
  Идея массива состоит в том чтобы объединить в одно целое фиксированное количество элементов одного и того же типа. Общая форма описания массива имеет вид: type имя типамассива = rry [ тип индекса ] of тип элементов ; где: имя типамассива имя выбираемое программистом. тип индекса любой порядковый тип кроме longint или типдиапазон.
36576. Оператор выбора CASE OF 31 KB
  Оператор выбора является обобщением оператора ifthenelse на случай выбора одного из нескольких возможных продолжений выполнения программы. Выбор осуществляется по ключу выбора селектору. Синтаксическая структура этого оператора такова: cse ключ выбора of константа выбора 1 : оператор 1 ; .
36577. Концепция типа данных. простой тип данных 38 KB
  К любому порядковому типу применимы следующие функции: OrdX порядковый номер значения выражения Х этого типа; PredX предыдущее значение выражения Х этого типа; SuccX следующее значение выражения Х этого типа; HighX наибольшее значение диапазона аргумента Х; LowX наименьшее значение диапазона аргумента Х; Функция Ord определена для любого значения порядкового типа причём нумерация значений начинается от номера 0 номера наименьшего значения типа. Функции Pred и Succ не определены соответственно для левой и правой границы...
36578. Концепция типа данных. Тип данных в ТР 29.5 KB
  Тип данных в ТР. Ранее мы познакомились с некоторыми стандартными типами данных: числовыми символьным строковым и булевским. Стандартные типы данных это лишь частный случай общей концепции типа данных Паскаля.
36579. Оператор итерационного цикла ( repeat , while ) 31 KB
  В каждом операторе итерационного цикла будем различать условие и тело цикла повторяющееся действие. Тело цикла whiledo это один оператор записанный после do а для цикла repetuntil тело цикла может быть и последовательностью операторов записанных между repet и until. Если условие есть true выполняется тело цикла и повторно вычисляется значение условия.
36580. Композиция условий и операторов. Оператор условного перехода 32.5 KB
  Оператор условного перехода. Композиция условий и операторов. Простые операторы несмотря на свою важность недостаточны для того чтобы представлять любые алгоритмы задач.
36581. Простые операторы ввода-вывода 33.5 KB
  Эти операторы Турбо Паскаля обеспечивают простейшие формы ввода с клавиатуры и вывода на экран дисплея в текстовом режиме. К простым операторам ввода и вывода относятся операторы red redln write writeln реализующие так называемый потоковый вводвывод при котором ввод и вывод рассматриваются как непрерывный поток символов и строк протекающий через экран дисплея. На экране отображается последняя порция этого потока так что нижняя строка экрана всегда остается свободной для отображения очередной строки вывода вывод идёт в нижнюю строку...
36582. Простые операторы управления вводом-выводом в текстовом режиме 32 KB
  Кроме ввода и вывода потока символов более удобный пользовательский интерфейс может быть обеспечен при использовании вводавывода в текстовом режиме экрана. В Турбо Паскале имеются средства управления вводом с клавиатуры управления курсором вывода на экран управления цветом фона экрана и выводимых символов яркостью символов и ряд других функций в том числе управления звуковым генератором. Установка цвета фона цвета символов и очистка экрана. Модуль CRT допускает использовать в текстовом режиме экрана 16 цветов задаваемых стандартными...