Доступ в Интернет через VPN и Outpost Firewall Pro

24.12.2006
Новиков М.Г.

Содержание:

Вступление
Включение VPN в Outpost Firewall Pro 4
Объяснение вышеописанных действий
Уровни протоколов Интернета

Вступление (чтоб язычком помолоть)

Некоторое время назад некто Bonnie — моя старинная подруга по сети FoxbatNet — в разговоре про средства защиты упомянула про то, что встроенный в Windows XP SP2 брандмауэр не блокирует Интернет-трафик, поступающий через VPN-соединение. Я проверил и ужаснулся — действительно, брандмауэр не блокировал ни одну программу, хотя соединение VPN у него в списке имелось и галочка напротив него стояла. Получается, что я полгода сидел практически голый, без брандмауэра, с одним только антивирусом KAV6!

Глубоко разочаровавшись в брандмауэре Windows, который я активно пропагандировал во времена своей модемной бытности (где он, кстати, работал вполне сносно), я решил перейти на что-нибудь более серьезное. После суточного штудирования Интернета я решил попробовать для начала поставить фаервол Outpost. Плюсы его очевидны. Во-первых, это русскоязычный интерфейс, а во-вторых, неплохие показатели во многих различных тестах. Этого мне было достаточно.

Поставив Outpost Firewall Pro ver. 4.0.971.7030 (584) я обнаружил, что не могу установить VPN-соединение с Интернетом. Чтобы выяснить причину, пришлось почитать различные тематические форумы. В этой статье я изложу свои советы по настройке фаервола для работы с VPN, а также сообщу некоторую информацию о протоколах и портах, необходимую для качественной настройки фаервола.

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

[Вернуться в начало]

Включение VPN в Outpost Firewall Pro 4 (чтобы уже включили и спокойно читали дальше)

Открываем «Параметры -> Системные -> Глобальные правила». Нажимаем кнопку «Правила» и выполняем следующие действия:

1. В списке правил проверяем наличие правила «Allow GRE protocol». По умолчанию оно должно полностью разрешать протокол GRE. Можно сузить это правило, дополнив его так: «где удалённый адрес ХХХ.ХХХ.ХХХ.ХХХ и где локальный адрес YYY.YYY.YYY.YYY». Вместо Х-ов вписываем IP-адрес VPN-сервера вашего провайдера, а вместо Y-ов — выделенный вам IP-адрес.

2. Добавляем новое правило «*Разрешить TCP на 1723»: «Где протокол TCP и где удалённый адрес ХХХ.ХХХ.ХХХ.ХХХ и где удалённый порт PPTP и где локальный адрес YYY.YYY.YYY.YYY разрешить эти данные».

После этих действий VPN будет работать.

[Вернуться в начало]

Объяснение вышеописанных действий (чтобы понять, что же мы сделали)

VPN-соединение реализуется протоколом канального уровня PPTP. Протокол PPTP для своей работы использует другой протокол — GRE, с помощью которого осуществляется тоннелирование трафика, а также порт 1723 протокола TCP, через который осуществляется управление GRE-тоннелем. Эти все порты и протоколы и нужно открыть, чтобы заработал PPTP, а значит, и VPN.

Фактически, при отправке через VPN-соединение данных с вашего компьютера на произвольный сайт в Интернете, VPN-клиент вашего компьютера в рамках протокола PPTP запаковывает каждый исходящий от вас IP-пакет в PPP-пакет (как бы для отправки в сеть), затем PPP-пакет запаковывается в GRE-пакет (для организации тоннеля), после чего GRE-пакет запаковывается в IP-пакет с указанием адреса VPN-сервера (для создания как бы внешней оболочки тоннеля, чтобы проложить его в реальной среде локальной сети). Затем каждый IP-пакет штатным образом запаковывается в PPP-пакет для отправки в сеть на адрес VPN-сервера.

Схема преобразования данных при отправке информации в Интернет с использованием
обычного соединения (для сравнения):

и VPN-соединения:

VPN-сервер в обратной последовательности распаковывает пакеты PPP, IP, GRE и PPP, и выделенные таким образом первоначальные IP-пакеты отправляет дальше, как если бы никакого VPN-тоннеля не было.

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

Схема доступа в Интернет через VPN-канал:

При прохождении данных в обратном направлении всё происходит примерно также. Запрошенные вами данные в виде PPP пакетов приходят на адрес прокси-сервера, который для своих нужд их распаковывает/запаковывает, и выдаёт на выходе IP-пакеты, в которых адрес прокси-сервера изменён на адрес вашего компьютера. Не вдаваясь в подробности, можно сказать, что адрес вашего компьютера прокси-сервер запомнил ранее, при запросе вами этих данных. Далее пакеты принимаются VPN-сервером.

VPN-сервер запаковывает IP-пакеты с адресом вашего компьютера  в PPP-пакеты (как бы для передачи по открытой локальной сети), потом в GRE-пакеты (организующие тоннель), и далее в IP-пакеты с указанием адреса VPN-клиента, установленного на вашем компьютере (для создания как бы внешней оболочки тоннеля, чтобы проложить его в реальной среде локальной сети). Как правило, VPN-клиент имеет адрес, отличающийся от адреса вашего компьютера только первым байтом. Затем готовые IP-пакеты запаковываются в PPP-пакеты и передаются по локальной сети на ваш компьютер.

Приходя на ваш компьютер, данные распаковываются VPN-клиентом в обратной последовательности: PPP, IP, GRE и PPP. Выделенные таким образом первоначальные IP-пакеты собираются TCP-протоколом и направляются к вашим приложениям, как будто они были распакованы из обычных PPP-пакетов, пришедших из локальной сети.

Замечу, что при запаковке ваших первичных IP-пакетов для отправки в тоннель, их тело может шифроваться протоколом MPPE, и лишь затем шифрованный IP-пакет упаковывается в PPP-пакет. Соответственно при распаковке пакет дешифруется. Однако данная услуга может не поддерживаться сервером.

[Вернуться в начало]

Уровни протоколов Интернета (чтобы понять предыдущее объяснение)

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

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

Если отправить всю страницу не пакетами, а одним массивом, то во-первых, не получится одновременно открывать другие страницы, пока не докачается текущая (ведь канал будет занят), а во-вторых, при малейшей ошибке в передаче придётся заново передавать весь массив. А так, мелкие пакеты всех открываемых одновременно страниц приходят вперемешку, но восстанавливаются параллельно каждый в свою страницу, а при ошибке в передаче перезапрашивается только ошибочный пакет.

Дробление и восстановление производится в несколько этапов согласно стандартным правилам (протоколам), реализованным программно. Существует множество протоколов, которые в зависимости от этапа, на котором они работают, подразделяются на несколько уровней:

На верхнем (прикладном) уровне располагаются такие протоколы, как HTTP — протокол передачи гипертекста. Он осуществляет операции по превращению web-страницы в поток байтов и передачу его протоколам более низкого (транспортного) уровня для отправки, или  заключительные операции восстановления web-страницы из потока данных, полученных от протоколов транспортного уровня при приёме. К протоколам прикладного уровня относятся также следующие распространённые протоколы: FTP, SMTP, POP3, IMAP4, DNS, NETBIOS и т.п.

На более низком (транспортном) уровне располагаются такие протоколы, как TCP — протокол управления передачей. При отправке он осуществляет разбивку пришедшего с верхнего (прикладного) уровня потока байтов на пакеты, добавляет в каждый пакет свой заголовок с данными, по которым тот же протокол на другом конце сможет снова собрать информацию и передать её выше, на прикладной уровень, и отправляет получившиеся пакеты ниже, на сетевой уровень, контролируя их доставку. Если пакет не дошёл, протокол посылает его сетевому уровню повторно. При приёме протокол собирает пакеты в нужной последовательности. По номеру порта, указанного в пакетах, он определяет принадлежность к приложению-адресату и передаёт собранные в поток байты на более верхний (прикладной) уровень. К протоколам транспортного уровня  относятся также следующие протоколы: UDP, NETBEUI и т.п.

На ещё более низком (сетевом) уровне располагаются такие протоколы, как IP — основной протокол Интернета. Протокол добавляет к пакетам свои заголовки с адресом компьютера получателя, превращая тем самым пакет в IP-дейтаграмму, то есть в пакет, содержащий в себе всю необходимую информацию об адресе назначения (IP-адрес в своём заголовке и порт в заголовке вложенного TCP-пакета). IP-протокол  занимается отсылкой или приёмом дейтаграмм, не заботясь об их общем количестве, последовательности или факте доставки. Эта обязанность лежит на протоколах вышестоящего (транспортного) уровня, в частности TCP. К протоколам сетевого уровня  помимо IP относятся также протокол GRE, ARP, ICMP, IGMP и т.п.

Ещё ниже находится канальный уровень, который условно разделяется на два подуровня: уровень управления логическим каналом (LLC) и уровень доступа к среде (MAC). LLC отвечает за достоверную передачу кадров данных между узлами, а также реализует функции интерфейса с прилегающим к нему сверху сетевым уровнем (например, протоколом IP), а MAC выполняет функции обеспечения доступа к разделяемой между узлами сети общей физической среде передачи данных.

Все протоколы канального уровня также делятся на две группы, но по другому принципу: В первую группу входят протоколы для соединений точка-точка (PPP, PPTP, SLIP, LAP-B, LAP-D), а во вторую — протоколы для сетей сложных топологий (Token Ring, Ethernet, Fast Ethernet, 100VG-AnyLAN, FDDI). Первая группа работает в случаях связи через модем или канал VPN (а также во всех подобных случаях прямого соединения точка-точка), а вторая — во всех остальных случаях (например, внутри единой сети).

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

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

Сводная таблица уровней протоколов:

Определения и описания протоколов я не привожу, поскольку этой информации и так достаточно в Интернете, и при желании вы всегда можете с ней ознакомиться.

Приятный ресурс по сетевым технологиям:

http://net.e-publish.ru/p214aa1.html