69568

IP-туннели

Лекция

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

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

Русский

2014-10-06

2.31 MB

4 чел.

Урок 12

IP туннели

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

  •  Заголовок IP пакета не содержит в себе совокупности полей, которых было бы достаточно для того, чтобы идентифицировать пакеты, являющиеся ответами на конкретные IP пакеты (так как IP изначально дейтаграммный протокол, рассматривающий каждый IP пакет как ни с чем не связанный блок данных) и как следствие - для того, чтобы правильно возвращать IP пакеты узлам автономной сети (для взаимодействий, инициированных из автономной сети) необходимо привлечение средств заголовков протоколов верхних уровней. Но такими наборами полей обладают важнейшие протоколы, работающие поверх IP, такие как TCP, UDP, ICMP.
  •  Взаимодействия, инициированные из Интернета в принципе не могут быть прозрачными, так как отправитель пакетов из Интернет не может напрямую обращаться к узлам автономной сети, а может обращаться лишь к IP адресу (или нескольким IP адресам) внешнего интерфейса NAT маршрутизатора. Применяемая при этом технология трансляции портов может обеспечить внутри автономной сети лишь такое количество служб одного типа (работающих на хорошо известных портах), сколько IP адресов присвоено внешнему интерфейсу NAT маршрутизатора. А, так как количество таких адресов по определению меньше, чем число узлов с автономными адресами внутри автономной сети (а иначе эти адреса можно было бы просто присвоить узлам автономной сети и не морочить себе голову использованием трансляций), то говорить о прозрачной работе из Интернет с ресурсами автономной сети не приходится.

Таким образом, технология NAT хоть и не обеспечивает полнофункциональный обмен произвольными IP пакетами для взаимодействий, инициированных из автономной сети, но, тем не менее, дает возможность организовывать такие взаимодействия для IP пакетов, несущих данные TCP, UDP и ICMP.  Такое положение вполне удовлетворительно для решения задачи о подключении сети с автономной адресацией к Интернет, с целью организации доступа к ресурсам Интернет из автономной сети. Что же касается организации доступа из Интернет к ресурсам, расположенным в  самой автономной сети, то решение, предлагаемое в рамках технологии PAT  является, конечно же, весьма ограниченно функциональным. При этом, если необходимо предоставить для  использования в Интернет корпоративный WEB сервер, файловый сервер и почтовый сервер, т.е. решить ограниченную задачу о предоставлении в совместное использование в Интернет некоторого количества ограниченных ресурсов, то технология PAT для этого вполне пригодна. А что, если необходимо обеспечить полнофункциональный, прозрачный доступ к ресурсам локальной сети  из Интернет? Тогда, конечно, технология PAT мало поможет.

С какой целью может понадобиться предоставление прозрачного доступа из Интернет к ресурсам  автономной сети?

Пусть есть компания, имеющая два (может и более) удаленных друг от друга офиса. В каждом офисе у компании есть локальная сеть, и каждый офис подключен к Интернет через собственного провайдера. Предположим, что компания имеет потребность связать свои офисы с помощью некоторой глобальной сетевой технологии с целью построения единой корпоративной сети для решения произвольных производственных задач. В предыдущих курсах были описаны технологии, которые для этого могут быть использованы – арендованные каналы PDH, территориальные сети с коммутацией пакетов, например Frame Relay. При этом, отмечалось, что цены на подобные услуги могут быть весьма высокими. Предположим, что компания пока не имеет финансовых возможностей вкладывать средства в организацию глобальной сети для решения задачи о связывании свои офисов и рассматривает вопрос об использовании Интернет для решения поставленной задачи.

Проанализируем, как компания может использовать для достижения своих целей сеть Интернет.

Предположим, что компания владеет диапазоном адресов, разрешенных для применения в Интернет. Т.е., каждый узел в каждой из двух (или более) территориально разнесенных сетей компании имеет Интернет адрес. Кроме того, каждая сеть, подключена к Интернет с помощью местного провайдера. Так  ЧТО же мешает с произвольного узла, расположенного в одной сетей компании, обращаться прозрачно к произвольным службам, расположенным на любом узле. Например, с узлом, расположенным в другой сети той же компании? Если каждый из этих узлов имеет разрешенный IP адрес, то каждый из узлов сети этой компании ЯВЛЯЕТСЯ полноценным узлом Интернет и вышеописанному взаимодействию НИЧТО не мешает. Таким образом,  Интернет тоже может выступить в качестве глобальной сети с коммутацией пакетов, используемой для связывания удаленных локальных сетей.

Ранее отмечалось, что когда об Интернете говорят «Глобальная сеть» - это просто принятая в обществе фраза, вообще говоря, не верная с точки зрения сетевых технологий.  Интернет – составная сеть, содержащая в себе множество локальных и глобальных сетей, взаимодействующих друг с другом с помощью протокола третьего уровня, в то время как классическая глобальная сеть (Frame Relay, например) – в чистом виде технология канального уровня. Однако в данном примере Интернет МОЖНО ИСПОЛЬЗОВАТЬ как глобальную сеть, хотя от этого Интернет все же не становиться глобальной сетевой технологией в принятом понимании этого термина. Если классические глобальные сети с коммутацией пакетов, работают на физическом и канальном уровне и применяют коммутацию пакетов, с использованием техники виртуальных каналов, то Интернет базируется на объединяющих (многие физические/канальные сети) средствах сетевого уровня и использует независимую маршрутизацию каждого пакета.

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

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

Изменим условия задачи: пусть компания не имеет адресов, разрешенных для применения в Интернет для каждого своего узла и использует в своих сетях автономные адреса. Разумеется, для организации доступа к ресурсам Интернет, внешние интерфейсы маршрутизаторов обоих (всех) сетей компании должны реализовывать технологию NAT. Как в таком случае обеспечить доступ к ресурсам внутри одной сети компании с узла, расположенного в другой сети компании? Понятно, что технология NAT обеспечивает трансляцию адреса отправителя пакета, но посылать в Интернет пакеты с автономными адресами получателей не имеет смысла. Некоторую помощь в этом случае может оказать технология Port Mapping (PAT) – на внешнем интерфейсе маршрутизатора компании можно определить некоторые переадресации (mapping) в автономную сеть. Но это, разумеется, не даст желаемого прозрачного доступа ко всем ресурсам частной сети, расположенной за NAT/PAT маршрутизатором. Задача кажется неразрешимой. Попробуем подойти к ней с другой стороны.

В чем состоит задача? Передать через Интернет пакет, адрес отправителя и получателя которого не допустим для использования в Интернет. Фактически существует порция данных, которая сама по себе не может быть передана через Интернет. Как передать через IP сеть произвольную порцию данных? Ответ прост и очевиден: произвольные данные можно передать через IP сеть, ПОМЕСТИВ В IP ПАКЕТ. Необходимо. НИЧТО не мешает рассматривать пакет с неподходящими адресами отправителя и получателя просто как порцию данных и поступить с этим «неправильным» пакетом как поступают с любой порцией данных для передачи по IP сети – помесить в IP пакет.

Рассмотрим, как это будет выглядеть на примере:

Пусть станция 10.0.0.2 отправляет IP пакет для станции 192.168.0.2. При этом станция 10.0.0.2 ничего не знает о том, что ни ее адрес, ни адрес получателя не допустимы в Интернет, будем полагать, что станция 10.0.0.2 обращается к 192.168.0.2 абсолютно прозрачно. Этот пакет поступает на маршрутизатор 10.0.0.1 и не может быть просто переправлен на маршрутизатор ISP, так же он не может быть переправлен с трансляцией NAT, так как адрес получателя в Интернет не допустим. В этом случае маршрутизатор первого офиса может вложить данный IP пакет с адресом отправителя 10.0.0.2 и адресом получателя 192.168.0.2 в другой IP пакет, с адресом отправителя 68.1.2.3 и адресом получателя 144.7.8.9, при этом поле протокол формируемого IP заголовка принимает значение 04, показывающее, что внутри данного IP пакета находится IP пакет. В итоге в сеть отправляется IP пакет от 68.1.2.3 к 144.7.8.9 и этот пакет без проблем пересекает Интернет, так как маршрутизаторы Интернет не анализирует содержимого перенаправляемых IP пакетов. В итоге этот пакет поступает на маршрутизатор 144.7.8.9, принадлежащий второму офису компании. Если на маршрутизатор поступает кадр канального уровня с МАС адресом порта маршрутизатора в качестве адреса получателя, то это не значит, что маршрутизатор – истинный получатель информации, просто маршрутизатор должен перенаправить данный пакет. Но если уже на маршрутизатор поступил IP пакет с IP адресом порта маршрутизатора в качестве адреса получателя IP пакета, то обычно это означает, что именно порт маршрутизатора является истинным получателем информации. Пока известно только одно исключение из данного правила: если полученный портом маршрутизатора IP пакет содержит в себе опцию LSRR/SSRR и поле Pointer в опции имеет значение, большее, чем поле Length, то это означает, что на самом деле данный маршрутизатор не является истинным получателем данных пакета. Но существует и второе исключение из этого правила: если поле Protocol полученного IP пакета = 04 (а маршрутизатор имеет право анализировать содержимое данного поля, так как пока думает, что он получатель данных), то это означает, что внутри данного пакета содержится другой IP пакет и обрабатывать его нужно следующим образом - необходимо извлечь этот вложенный IP пакет и маршрутизировать его в соответствии с имеющейся в распоряжении маршрутизатора таблицей маршрутизации. Таким образом, маршрутизатор 144.7.8.9 извлекает из принятого IP пакета вложенный IP пакет, и анализирует адрес получателя данного пакета. Адрес получателя в нашем примере – 192.168.0.2, сеть 192.168.0.0/24 является подключенной для данного маршрутизатора, и пакет доставляется получателю! Разумеется, аналогично передаются и пакеты из сети 192.168.0.0/24 в сеть 10.0.0.0/8.

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

Что необходимо для того, чтобы данная технология функционировала? Необходима небольшая доработка (но не полное переделывание) логики работы маршрутизаторов. Необходимо иметь возможность создать на маршрутизаторе логический интерфейс нового типа, называемого в Windows 2000 «Туннель IP-IP». Если какой то маршрут пролегает через этот интерфейс, необходимо поступивший на маршрутизатор IP пакет укладывать в новый IP пакет, с адресами отправителя и получателя, указанными в свойствах нового интерфейса и маршрутизировать этот вновь созданный пакет обычным способом. При получении пакетов, предназначенных маршрутизатору, в случае если поле Protocol = 04, необходимо извлекать из полученного IP пакета IP пакет и маршрутизировать его обычным способом. При этом никаких принципиальных изменений в маршрутизатор не вносится, необходимо просто снабдить маршрутизатор новыми функциями, причем их реализация достаточно проста. Самое главное, что данная техника маршрутизации остается  прозрачной для конечных узлов, которые работают в этой сети.

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

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

Необходимо передать через транзитную сеть между маршрутизаторами пакет от 10.0.0.2 для 192.168.0.2, причем в транзитной сети не допустимо передавать трафик с автономными адресами. Для этого на маршрутизаторах создается интерфейс «Туннель IP-IP».

Название выбирается произвольно, например по создаваемому направлению

Туннель создан

Добавим  туннель к интерфейсам маршрутизации

Опишем свойства созданного туннеля

«Локальный адрес» - адрес интерфейса маршрутизатора подключенного в Интернет.

«Удаленный адрес» - адрес интерфейса маршрутизатора с противоположной стороны туннеля, так же подключенный в Интернет.

«Срок жизни» - поле TTL внешнего заголовка IP для пакетов, отправляемых через данный туннель.

Дополнительно указывается проверка фрагментации, на случай если MTU частной сети с той стороны туннеля отличается от MTU своей частной сети

Интерфейс подключен

Создадим статический маршрут в частную сеть с той стороны туннеля, указав в качестве шлюза – интерфейс, принадлежащий туннелю

В результате, таблица маршрутизации шлюза имеет вид

Обратите внимание, IP туннель в системе имеет собственный идентификатор как интерфейс (в данном случае 0х1000005) и как устройство (в данном случае 00-53-45-00-00-00)

Но IP-туннель не имеет собственного  IP адреса

Фактически, в настройках этого интерфейса администратор задает IP адрес отправителя и получателя внешнего IP пакета, который будет сформирован при маршрутизации. Само по себе наличие нового интерфейса у маршрутизатора еще ничего не означает, еще необходимо, чтобы через этот интерфейс передавались какие то пакеты, то есть необходимо создать маршруты, пролегающие через этот интерфейс. Если предположить, что два маршрутизатора имитируют маршрутизаторы компании, подключенные в Интернет, то вполне логично, что на этих маршрутизаторах будет записан маршрут по умолчанию на адрес следующего интерфейса. Рассматриваемая модель очень проста, в ней нет места маршрутизаторам провайдера, поэтому просто запишем в таблице маршрутизации у каждого маршрутизатора маршрут по умолчанию на другой маршрутизатор. После этого напишем в таблице маршрутизации у левого маршрутизатора маршрут в сеть 10.0.0.0/8 через интерфейс Туннель, а у правого маршрутизатора маршрут в сеть 192.168.0.0/24 через интерфейс Туннель.

Настройка IP туннеля производится с каждой стороны взаимодействия т.е. на обоих маршрутизаторах удаленных филиалов. При этом настройки туннеля на маршрутизаторах с каждой стороны взаимно обратны. Например, на первом маршрутизаторе:

Локальный адрес 210.1.1.1 Удаленный адрес 210.1.1.2

Тогда на втором маршрутизаторе:

Локальный адрес 210.1.1.2 Удаленный адрес 210.1.1.1

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

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

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

Захват трафика в сети отправителя эхо-запросов (left_net.cap):

Захват трафика в транзитной сети  (Center_net.cap):

Захват трафика в сети получателя эхо-запросов (right_net.cap):

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

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

Задание для самостоятельной работы.

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

Требуется, разработать модель данной сети состоящей из 8-ми компьютеров, 5 из них выполняют функции маршрутизаторов. Присвоить IP адреса всем участникам взаимодействий, выбирая для сетей компании автономные адреса, а для узлов Интернет – «честные» адреса.  Указать компьютеры, на которых предполагается настройка туннелей IP-IP и/или NAT. Привести примерные конфигурации.

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

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

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

Виртуальные частные сети

(VPN Virtual private network)

Метод туннелирование используется для передачи посредством IP сети, трафика, который эта IP сеть «просто так» передавать не может.  Например, IP пакеты с автономными адресами отправителей и получателей инкапсулируются в IP пакеты с допустимыми адресами после чего передаются сквозь Интернет, формируя трафик корпоративной сети. Ключевой недостаток такого решения - отсутствие защищенности корпоративного трафика, пересекающего Интернет.

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

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

На каком уровне сетевой модели начнется поиск решения? Так как требуется продолжать использовать все существующие сетевые приложения, то, очевидно, решение необходимо искать ниже прикладных уровней, а именно, на третьем уровне. В первом приближении решение должно быт похоже на решение предыдущей задачи о туннелях - необходимо снабдить два обменивающихся данными через Интернет узла (маршрутизатора) некоторыми новыми виртуальными интерфейсами, передающими трафик в некотором туннеле друг другу, но при этом СОДЕРЖИМОЕ туннеля, то, что находится над НЕСУЩИМ IP заголовком, необходимо зашифровать. Технологию, которая решает поставленную задачу, принято называть VPN – виртуальная частная сеть. Термин «виртуальная» означает, что никаких реальных (аппаратных) новых интерфейсов наш узел (маршрутизатор) не получает. Никакой новой реальной (физической) сети между участниками взаимодействия нет, узлы (маршрутизаторы) связаны публичной сетью Интернет. Но при этом узлы снабжаются новыми виртуальными интерфейсами в виртуальной сети типа точка-точка с канальным протоколом PPP, интерфейсы получают адреса в этой сети и обмениваются кадрами PPP в рамках этой сети. Разумеется, так как сеть виртуальная, то кадры PPP необходимо каким то образом переносить через транспортную сеть Интернет, и для этого кадры PPP инкапсулирует в несущие IP пакеты (как IP пакеты инкапсулировали в IP пакеты в случае туннелей IP-IP), при этом кадры PPP предварительно тем или иным способом шифруются.

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

После того, как идея технологии сформулирована, рассмотрим, какие протоколы для выполнения данного шифрования поддерживаются программными и аппаратными продуктами для организации VPN.

На сегодняшний день существует несколько протоколов для организации таких виртуальных  шифрованных PPP каналов связи. Это такие протоколы как: PPTP (Point-to-Point Tunneling Protocol, RFC2637, статус – информационный), протокол L2F (Layer 2 Forwarding), разработанный компанией Cisco Systems (RFC2341, статус historic) и протокол L2TP (Layer 2 Tunneling Protocol), являющийся открытой разработкой и опубликованный в RFC2661 (Предлагаемый стандарт). Детальное рассмотрение заголовков этих и связанных с ними протоколов будет проведено в курсе, посвященном сетевой безопасности. 

Из трех перечисленных протоколов L2F считается устаревшим, а PPTP и L2TP используются сегодня и поддерживаются маршрутизатором Windows 2000. Рассмотрим конфигурирование VPN в Windows на базе протокола PPTP, так как его конфигурирование в Windows максимально упрощено (т.к. в данном случае требуется просто организация защищенного канала данных на третьем уровне).

Итак, у двух участников взаимодействия (узлов или маршрутизаторов), желающих передавать приватные данные через Интернет создается виртуальный интерфейс точка-точка, этот интерфейс снабжается IP адресом и маской подсети (как и любой точка-точка интерфейс), этот интерфейс может служить для маршрутизации пакетов как и обычный интерфейс. При необходимости передать (в соответствии с таблицей маршрутизации) пакеты через данный интерфейс, формируется (как и в случае, если бы это был обычный PPP интерфейс) IP пакет с адресами отправителя и получателя в рамках данной точка-точка сети и инкапсулируется в кадр PPP. До этого момента, происходит самое обычное PPP взаимодействие. Если бы данный PPP интерфейс был «обычным», то кадр PPP отправлялся бы в линию связи, но так как данный интерфейс – виртуальный и никакой линии связи (в которой реализован PPP) на самом деле нет.  Далее происходит следующее: данный кадр PPP шифруется с помощью того или иного метода шифрования и инкапсулируется с помощью того или иного дополнительного протокола (детали зависят от того, применяется ли L2F, PPTP или L2TP), после чего, эта порция данных передается с помощью обычного IP пакета через Интернет с использованием IP адресов обычных, «настоящих» интерфейсов подключенных в Интернет. Т.е. это самый «обычный» PPP интерфейс, но не имеющий своей линии связи, и поэтому его кадры отправляются не в провод, а обрабатываются специальным образом – инкапсулируются в IP пакеты (с предварительным шифрованием кадра PPP) и отправляются в реальные линии связи в несущих IP пакетах.

Рассмотрим, как это реализовано в Windows. Если необходимо установить между двумя участниками взаимодействия PPP соединение, в Windows используется служба удаленного доступа. Сервер удаленного доступа принимает соединения, используя, подходящие для этого, аппаратные порты (COM, LPT, другие) и предоставляет подключившемуся клиенту IP адрес из заранее настроенного диапазона адресов и маску /32. Клиент удаленного доступа, напротив, вызывает сервер с помощью доступных ему аппаратных портов, получает от сервера IP адрес и маску /32, в итоге между клиентом и сервером устанавливается PPP соединение. Таки образом, установка VPN соединения производится в Windows аналогично установке обычного PPP соединения, т.е. сервер удаленного доступа может принимать входящие PPP подключения не только на аппаратных портах, но и на виртуальных портах PPTP и L2TP, а для создания клиентского подключения используется мастер, практически аналогичный мастеру создания подключения удаленного доступа. Одно из немногих отличий состоит в том, что при создании подключения удаленного доступа с помощью PSTN и ISDN модема пользователь должен указать номер телефона для указания того, с кем необходимо установить PPP соединение, а в случае создания VPN соединения пользователь должен указать IP сервера.

Для создания PPP канала поверх PSTN или ISDN стороны должны иметь подключение к транспортной сети (PSTN или ISDN) и установить между собой соединение, указав адресата с помощью его уникального идентификатора в транспортной сети (по номеру телефона). При этом кадры PPP передаются по транспортной сети (PSTN или ISDN) непосредственно поверх этой транспортной сети. А для создания виртуального PPP канала поверх транспортной сети Интернет узлам необходимо установить между собой логическое соединение, указав адресата с помощью его уникального идентификатора в транспортной сети Интернет (по IP адресу). При этом кадры PPP передаются по транспортной сети Интернет непосредственно поверх этой транспортной сети, т.е. поверх IP пакетов, предварительно кадры PPP шифруются. Таким образом, с точки зрения идеологии организации PPP соединения, в Windows не имеет принципиального значения,  поверх телефонных сетей или поверх Интернет организуется PPP соединение, отличия только в том, каким образом кадры PPP передаются по транспортной сети. Все пользовательские интерфейсы идентичны для организации PPP соединений обоих типов.

Рассмотрим типовые применения технологии VPN. Можно выделить три типовых способа применения данной технологии:

  •  Клиент – клиент
  •  Клиент – шлюз
  •  Шлюз – шлюз

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

Пример создания VPN соединения на стороне клиента Windows 2000 Pro.

Указываем адрес компьютера, к которому будет осуществляться VPN соединение

Указываем кто имеет право использовать данное соединение

Присваиваем создаваемому соединению интуитивно-понятное имя

Созданное соединение имеет вид

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

Конфигурация VPN на вызываемом компьютере под управлением Windows 2000 Pro осуществляется следующим образом:

В случае если для входящего VPN соединения используется аппаратный порт – то необходимо отметить, какой именно – например COM1. В случае если входящий VPN принимается через сетевой адаптер, то ни однин аппаратный порт не отмечается.

Разрешаем входящие VPN

Назначаем учетные записи для входящего подключения по VPN

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

Входящему подключению присваивается имя

Созданное входящее подключение имеет вид

Рассмотрим передачу текстового файла по сети, не использующей технологию VPN. Обратите внимание, что передаваемый текст (т.е., потенциально конфиденциальные данные) можно без проблем прочитать в окне анализатора протоколов:

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

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

Существует особенность настройки VPN соединения на стороне клиента. Дело в том, что клиент удаленного доступа VPN должен очистить CheckBox  «Использовать как шлюз в удаленные сети» у данного подключения. Так как при создании подключения удаленного доступа, в таблицу маршрутизации узла добавляется запись о маршруте по умолчанию через данный интерфейс удаленного доступа. Это связано с тем, что «обычно» подключения удаленного доступа применяются для организации доступа узла в составную сеть через маршрутизатор. Например, узел получил IP адрес 150.12.2.5/32 от сервера удаленного доступа, в его маршрутной таблице появилась запись:

0.0.0.0  0.0.0.0   150.12.2.5

Это полезно, например, для домашнего пользователя, для которого интерфейс PPP, связывающий его с провайдером действительно необходимо использовать как маршрут во все сети. А что если у узла уже есть маршрут во все сети, полученный, например, тем же способом – от сервера удаленного доступа провайдера, и после этого узел устанавливает VPN соединение с другим узлом Интернет для безопасной передачи данных? В таком случае ДО установки VPN соединения узел отправлял все пакеты маршрутизатору своего провайдера в соответствии с вышеприведенной таблицей маршрутизации. Положим, что после этого узел установил VPN соединения с другим узлом Интернет и получил в рамках этого соединения адрес 10.0.0.2/32. Тогда в таблицу маршрутизации по умолчанию добавиться еще одна запись:

0.0.0.0  0.0.0.0   150.12.2.5

0.0.0.0  0.0.0.0   10.0.0.2

Как теперь будет осуществляться маршрутизация? Это зависит, как известно, от метрик, присвоенных маршрутам. По умолчанию, до установки VPN соединения метрика маршрута default, ведущего к маршрутизатору провайдера была равна 1, но после появления нового маршрута по умолчанию, его метрика станет равна 1, а метрика старого маршрута по умолчанию станет равна 2.

0.0.0.0  0.0.0.0   150.12.2.5 2

0.0.0.0  0.0.0.0   10.0.0.2  1

Следовательно, теперь ВСЕ пакеты будут передаваться через VPN: и те, которые должны передаваться в частную сеть, и те, которые следовало бы передавать маршрутизатору провайдера обычным способом. Т.е., пока существует VPN соединение, тот, кто выступил в роли клиента удаленного доступа, не сможет обмениваться пакетами с узлами в Интернет (при настройках по умолчанию, разумеется). В этом случае рекомендуется не ассоциировать с VPN подключением маршрута по умолчанию.

Рассмотрим второй типовой сценарий использования VPN: соединения типа клиент – шлюз. Пусть некоторый пользователь компании находится в командировке и ему необходимо получить удаленный доступ к ресурсам корпоративной сети. Очевидно решение: пользователь совершает удаленный доступ к соответствующему серверу удаленного доступа, расположенному в своей корпоративной сети через PSTN или ISDN. Однако, если пользователь находится в заграничной командировке, такой способ уделенного доступа сопряжен с большими финансовыми затратами, а если подобная задача стоит перед компанией часто, то такое решение не может быть приемлемым. Положим, что удаленный пользователь вместо того, чтобы подключиться к серверу удаленного доступа своей компании, подключается к серверу удаленного доступа местного ISP. При этом пользователь получает от ISP допустимый в Интернет IP адрес и может обмениваться пакетами с узлами своей корпоративной сети, при условии, что у всех них тоже есть «честные» Интернет адреса. Если честных адресов у всех узлов компании нет, то можно воспользоваться технологией мэппинга портов, но при этом доступ возможен лишь с ограничениями, рассмотренными ранее. Но в обоих случаях, имеют ли узлы в корпоративной сети честные адреса в Интернет или не имеют, возникает одна и та же проблема: незащищенность в Интернет корпоративного трафика.

Рассмотрим решение проблемы с использованием уже рассмотренного инструмента: VPN соединения по схеме «узел-узел» (клиент-клиент). Удаленный пользователь подключается к местному ISP с помощью PSTN или ISDN, после чего устанавливает VPN соединение с нужным узлом своей сети. Это возможно только тогда, когда все узлы корпоративной сети имеют четные  адреса в Интернет и мэппинг портов уже не поможет, так как VPN сервер занимает строго определенный TCP порт 1723. При этом придется поддерживать VPN сервер на каждом узле в корпоративной сети, что крайне не эффективно. В этом случае данные оказываются защищенными не только в Интернет, но и в корпоративной сети, что в целом, избыточно. Такое решение крайне не выгодно.

Вместо этого, было бы правильнее, что бы удаленный пользователь установил VPN соединение с внешним маршрутизатором корпоративной сети и перенаправлял ему все пакеты в корпоративную сеть. При этом, достаточно установить одно VPN соединение для доступа ко всем узлам корпоративной сети, кроме того, при таком подходе нет потребности всем узлам корпоративной сети иметь честные IP адреса, так как пакеты для этих узлов с автономными адресами получателей будут переданы через Интернет в IP пакетах от удаленного узла к внешнему интерфейсу маршрутизатора, который, безусловно, имеет честный IP адрес в Интернет. Данное решение похоже на попытку позвонить по PSTN или ISDN каждому узлу в корпоративной сети, вместо того, чтобы установить соединение по телефонным линиям с маршрутизатором.

Итак, эффективное решение – установка VPN соединения между удаленным пользователем и маршрутизатором корпоративной сети. Клиентские настройки при этом не меняются: пользователь как в предыдущем примере вызывал на сервер удаленного доступа, так и вызывает его в этом примере. Но теперь в роли сервера VPN доступа должен выступить маршрутизатор Windows.

Конфигурации сервера RAS для Windows Server имеет вид

Т.е.  настройка службы RRAS для выполнения роли VPN сервера заключается во включении поддержки удаленного доступа в службе RRAS, и конфигурировании соответствующих L2TP и PPTP портов.

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

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

- адрес PC1 10.0.0.2/8, шлюз 10.0.0.1

- адрес внутреннего интерфейса корпоративного маршрутизатора R1 10.0.0.1/8

Пусть, корпоративный маршрутизатор R1 работает под управлением Windows Server. Тогда для предоставления доступа клиентам корпоративной сети в Интернет, на данном маршрутизаторе используется технология NAT, а для предоставления доступа в корпоративную сеть из Интернет используется RAS VPN сервер. Исходя из вышеизложенного, интерфейсы R1 могут иметь следующие адреса:

- интерфейс, подключенный в локальную сеть 10.0.0.1/8

- интерфейс, подключенный в Интернет 11.0.0.1/8

Конфигурация NAT  на R1 содержит 10.0.0.1/8 как Частный интерфейс, и пул, состоящий из одного IP адреса 11.0.0.1/8 - 11.0.0.1/8, как  Общий интерфейс использующий NAT. Так же на R1 активирована служба Удаленного доступа (checkbox «Сервер удаленного доступа»). Клиентам подключающимся через VPN выдаются адреса из диапазона принадлежащего корпоративной (локальной) сети, например 10.1.0.1 – 10.1.0.255.

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

Конфигурация R2 представляет собой стандартный сервер удаленного доступа без поддержки VPN.

В соответствии со схемой R2 может использовать следующие IP адреса

-   интерфейс для подключения R1: 11.0.0.2/8

- интерфейс для подключения удаленных пользователей (например COM1): диапазон автономных адресов 192.168.0.1 – 192.168.0.10

Клиент PC2, использует для подключения к провайдеру (R2) модем

Кроме этого необходимо создать еще одно соединение – VPN. Это подключение будет активироваться пользователем после того, как произойдет соединение по модему с провайдером (R2). В адресе вызываемого сервера этого соединения указывается внешний IP адрес корпоративного маршрутизатора – 11.0.0.1

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

В результате произведенных настроек, удаленный пользователь работает в Интернет используя обычное модемное соединение, но как только происходит обращение в сеть корпорации 10.0.0.0/8 трафик автоматически направляется в VPN туннель на сервер удаленного доступа корпорации, а  от туда – непосредственно в корпоративную сеть. Причем, с точки зрения хостов корпоративной сети, обмен данными с удаленным клиентом ни чем не отличается от взаимодействия с узлами корпоративной сети. При передаче данных по VPN туннелю трафик шифруется, что отвечает требованию конфиденциальности корпоративных данных.

Рассмотрим еще один пример использования VPN типа клиент-шлюз. На этот раз задача прямо противоположна: защита публичного трафика, направленного к узлам Интернет от несанкционированного доступа из локальной сети. Типовой пример: провайдер услуг Интернет предлагает доступ посредством локальной («районной») сети своим пользователям. Обычно такие сети строятся на дешевом оборудовании, о применении управляемых коммутаторов часто речи не идет, так что данные, передаваемые пользователями такой сети узлам Интернет ОЧЕНЬ часто подвергаются перехвату соседями, часто из любопытства, но часто и с целью перехвата, к примеру, паролей. Такая сеть очень удобна, с точки зрения  анализа трафика, и, разумеется, провайдеру хотелось бы защитить своих пользователей от злоумышленных действий соседей. Возможное решение: пользователи сначала устанавливают с VPN сервером провайдера VPN соединение, а затем в рамках этого соединения передают провайдеру данные для отправки их в Интернет. При этом к узлам Интернет, разумеется, попадают данные в обычных IP пакетах, но в локальной районной сети, которая «небезопасна» данные передаются зашифрованными.

Маршрутизатор провайдера в данном случае выступает сервером RRAS с поддержкой VPN входящих соединений. Клиенты районной сети подключаются в Интернет при помощи VPN соединения к провайдеру. При этом CheckBox о маршруте по умолчанию при настройке дополнительных опций VPN соединения, активируется, т.к. именно это соединение и IP адрес PPP интерфейса будет использоваться клиентами районной сети для работы в Интернет.

Задание для самостоятельно работы.

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


 

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

53181. Велика Британія в 19 столітті – народження традицій 929 KB
  Queen Victoria came to the throne as a young woman in 1837 and reigned until her death in 1901. Because of the growth of parliamentary government she was less powerful than previous sovereigns but as queen and empress she ruled over more lands and peoples than any previous monarch. Furthermore, she enjoyed the respect and affection of her British subjects.
53182. Економічний бій 59 KB
  Товар який стихійно виділився з світу товарів щоб відігравати роль загального еквіваленту гроші. Яку функцію виконують гроші якщо їх віддають у банк під процент Чи діє закон попиту на монополістичному ринку Що станеться на товарному ринку з ціною на молоко якщо збільшиться кількість корів і зменшаться доходи споживачів Продовжіть прислів’я: Хочеш втратити друга.дай йому в борг гроші. Командам пропонується згадати прислів’я або приказки про гроші або про працю.
53184. Закріплення теми «Креслення в системі прямокутних проекцій» 43 KB
  Получение изображения предмета на чертеже воображаемыми лучами называют проецированием Изображение предмета на плоскости методом проецирования называют проекцией Плоскость на которой получают проекцию называютплоскость проекции Назовите методы проецирования центральное и параллельное. Какой метод проецирования более простой и удобный для получения проекций в черчении Где используется метод центрального проецирования в изобразительном искусстве. Назовите три плоскости проецирования фронтальная горизонтальная...
53185. Застосування різних способів розкладання многочленів на множники 75.5 KB
  Мета: узагальнити й систематизувати знання, вміння і навички учнів; розвивати пізнавальну активність, логічне мислення, увагу; виховувати культуру математичного мовлення, упевненість у своїх силах.
53186. Піраміди гіпотез – домовини фактів 92 KB
  Тема: Піраміди гіпотез – домовини фактів†Мета: систематизувати знання за темою Пірамідаâ€; розширити й поглибити пізнавальну активність з допомогою створення проблемних творчих завдань; створити змістовну базу для вивчення інших шкільних дисциплін – астрономії фізики біології; сприяти виробленню в учнів бажання і потреби ділового співробітництва взаєморозуміння; розвивати монологічне мовлення учнів загальні трудові уміння. Обладнання: газета Піраміди гіпотез – домовини фактівâ€; альбом кросвордів за темою...
53187. Решение уравнений. Урок – игра математики в 6 классе 49.5 KB
  Многие задачи из жизни решаются на математическом языке с помощью уравнений. Поэтому очень важно, чтобы ваши знания и умения решать уравнения были прочны. Во время урока вам пригодятся находчивость, смекалка и сообразительность, потому что мы проведём наш урок в виде игры- соревнований.
53189. ГРА НА УРОЦІ АНГЛІЙСЬКОЇ МОВИ ЯК ЗАСІБ ПІДВИЩЕННЯ ПІЗНАВАЛЬНОЇ АКТИВНОСТІ ШКОЛЯРІВ 83 KB
  У школярів молодшого віку переважають ігрові інтереси, довільна поведінка, наочнообразне мислення, практичне ставлення до розвязування завдань. Зважаючи на все це, доцільно у роботі з ними на уроках іноземної мови систематично застосовувати елементи гри у поєднані з бесідою, елементами самостійної роботи.