Понятие частной виртуальной сети

VPN (Virtual Private Network — виртуальная частная сеть) — логическая сеть, создаваемая поверх другой сети, например Интернет. Несмотря на то, что коммуникации осуществляются по публичным сетям с использованием небезопасных протоколов, за счёт шифрования создаются закрытые от посторонних каналы обмена информацией. VPN позволяет объединить, например, несколько офисов организации в единую сеть с использованием для связи между ними неподконтрольных каналов.

Аббревиатуру VPN можно расшифровать не только как Virtual Private Network, но и как Virtual Protected Network, т.е. Виртуальная Защищенная Сеть.

Термин «private» имеет два основных значения: частный (собственный) и конфиденциальный (закрытый). Если говорить о первом значении, то частная сеть - это сеть, в которой всё оборудование, включая территориальные кабельные системы, коммутирующие устройства, средства управления, являются собственностью предприятия. Такая сеть отвечает требованиям и второго определения, так как в собственной сети легче соблюдать конфиденциальность, поскольку все ресурсы сети используются только сотрудниками предприятия - владельца сети.

VPN - это частная сеть передачи данных, использующая открытую телекоммуникационную инфраструктуру и сохраняющая при этом конфиденциальность передаваемых данных посредством применения протоколов туннелирования и средств защиты информации.

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

История зарождения VPN уходит своими корнями далеко в 60-е годы прошлого столетия, когда специалисты инженерно-технического отдела нью-йоркской телефонной компании разработали систему автоматического установления соединений абонентов АТС – Centrex (Central Exchange). Другими словами это не что иное, как виртуальная частная телефонная сеть, т.к. арендовались уже созданные каналы связи, т.е. создавались виртуальные каналы передачи голосовой информации. В настоящее время данная услуга заменяется более продвинутым ее аналогом – IP-Centrex.

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

· Cisco — L2F (Layer 2 Forwarding), L2TP (Layer 2 Tunnelling Protocol), L2TPV3 (Layer 2 Tunnelling Protocol version 3).

· Microsoft — PPTP (Point-To-Point Tunnelling Protocol).

· Check Point Software Technologies — VPN-1.

· Redcreek Communications — Ravlin.

· Intel — Landrover VPN Express.

· и многие др.

Количество программных реализаций VPN от энтузиастов-любителей очень и очень велико. Большинство из них содержали в себе ряд серьёзных уязвимостей, зачастую в них был достаточно посредственно проработан вопрос шифрования — использовались достаточно слабые криптоалгоритмы, ни о какой многоплатформенности нельзя было и говорить. Но, несмотря на то, что большинство умирало на уровне альфа-бета версий, некоторые семена выросли в достаточно серьёзные решения, например, OpenVPN. Первые создаваемые реализации VPN обеспечивали лишь создание защищённого канала точка-точка между двумя серверами, по которому передавались все виды трафика. Со временем функциональность VPN расширялась, стали поддерживать более сложные, чем точка-точка, конфигурации сети: extranet VPN, intranet VPN, remote access VPN и VPN смешанных типов. Следствием этого явилось увеличение числа пользователей в виртуальных частных сетях, и на передний план вышли проблемы управления акаунтами, ассоциации с ними необходимых прав доступа, оперативное изменение прав в рамках всей создаваемой сети. Затем, в связи с увеличением числа пользователей стали повышаться требования к масштабируемости и расширяемости. Помимо постоянного увеличения числа пользователей изменился контент и объём передаваемых данных. Если на заре VPN по сетям в основном передавались текстовые данные, то на сегодняшний день эти сети часто используются для передачи медиа данных, на основе виртуальных частных сетей нередко устраивают видеоконференции и обеспечивают голосовую связь. Подобный «взрыв» объёмов трафика стал создавать огромные нагрузки на виртуальные частные сети, часто важная информация стала доходить со значительным запозданием из-за загрузки сетей. Это поставило перед разработчиками VPN решений новую проблему — проблему обеспечения качества обслуживания, которая на сегодняшний день наиболее актуальна.

VPN туннели

VPN соединение состоит из канала типа точка-точка, Это соединение также известно под названием туннель. Туннель создаётся в незащищённой сети, в качестве которой чаще всего выступает Интернет. Соединение точка-точка подразумевает, что оно всегда устанавливается между двумя компьютерами, которые называются узлами или peers. Каждый peer отвечает за шифрование данных до того, как они попадут в туннель и расшифровке этих данных после того, как они туннель покинут.

Хотя VPN туннель всегда устанавливается между двумя точками, каждый peer может устанавливать дополнительные туннели с другими узлами. Для примера, когда трём удалённым станциям необходимо связаться с одним и тем же офисом, будет создано три отдельных VPN туннеля к этому офису. Для всех туннелей peer на стороне офиса может быть одним и тем же. Это возможно благодаря тому, что узел может шифровать и расшифровывать данные от имени всей сети, как это показано на рис. 9.1.

Рис.9.1 VPN шлюз к сети

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

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

Рис.9.2 Защищённая сеть на основе незащищённой сети

Сеть A считается доменом шифрования VPN шлюза A, а сеть B доменом шифрования VPN шлюза B, соответственно. Когда пользователь сети A изъявляет желание отправить данные в сеть B, VPN шлюз A зашифрует их и отошлёт через VPN туннель. VPN шлюз B расшифрует информацию и передаст получателю в сети B.

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

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

Независимо от используемого ПО, все VPN работают по следующим принципам:

· Каждый из узлов идентифицирует друг друга перед созданием туннеля, чтобы удостовериться, что шифрованные данные будут отправлены на нужный узел

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

· Узлы сверяют политики, чтобы договориться об используемых алгоритмах; если это не получается, то туннель не устанавливается

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

Есть несколько стандартов регламентирующих вышеописанное взаимодействие: L2TP, PPTP, и IPSec.

Протокол IPSec

Стандарт IPSec был разработан для повышения безопасности IP протокола. Это достигается за счёт дополнительных протоколов, добавляющих к IP пакету собственные заголовки, которые называются инкапсуляциями.

AH (Authentication Header) - протокол заголовка идентификации. Обеспечивает целостность путём проверки того, что ни один бит в защищаемой части пакета не был изменён во время передачи. Не будем вдаваться в подробности, какая часть пакета защищается и где находятся данные AH заголовка, т.к. это зависит от используемого типа шифрования и в деталях, с диаграммами описывается в соответствующем RFC. Использование AH может вызвать проблемы, например, при прохождении пакета через NAT устройство. NAT меняет IP адрес пакета, чтобы разрешить доступ в Интернет с закрытого локального адреса. Т.к. пакет в таком случае изменится, то контрольная сумма AH станет неверной. Также стоит отметить, что AH разрабатывался только для обеспечения целостности. Он не гарантирует конфиденциальности путём шифрования содержимого пакета.

ESP (Encapsulating Security Protocol) - инкапсулирующий протокол безопасности, который обеспечивает и целостность и конфиденциальность. В режиме транспорта ESP заголовок находится между оригинальным IP заголовком и заголовком TCP или UDP. В режиме туннеля заголовок ESP размещается между новым IP заголовком и полностью зашифрованным оригинальным IP пакетом.

Т.к. оба протокола - AH и ESP добавляют собственные заголовки, они имеют свой ID протокола, по которому можно определить что последует за заголовком IP. Каждый тип заголовка имеет собственный номер. Например, для TCP это 6, а для UDP - 17. При работе через firewall важно не забыть настроить фильтры, чтобы пропускать пакеты с ID AH и/или ESP протокола. Для AH номер ID - 51, а ESP имеет ID протокола равный 50.

Третий протокол, используемый IPSec - это IKE или Internet Key Exchange protocol. Как следует из названия, он предназначен для обмена ключами между двумя узлами VPN. Насмотря на то, что генерировать ключи можно вручную, лучшим и более масштабируемым вариантом будет автоматизация этого процесса с помощью IKE. Необходимо помнить, что ключи должны часто меняться, и вам наверняка не хочется полагаться на свою память, чтобы найти время для совершения этой операции вручную.

SA (Security Association) - это термин IPSec для обозначения соединения. При настроенном VPN, для каждого используемого протокола создаётся одна SA пара (т.е. одна для AH и одна для ESP). SA создаются парами, т.к. каждая SA - это однонаправленное соединение, а данные необходимо передавать в двух направлениях. Полученные SA пары хранятся на каждом узле. Если ваш узел имеет SA, значит VPN туннель был установлен успешно.

Т.к. каждый узел способен устанавливать несколько туннелей с другими узлами, каждый SA имеет уникальный номер, позволяющий определить к какому узлу он относится. Это номер называется SPI (Security Parameter Index) или индекс параметра безопасности.

SA хранятся в базе данных с названием SAD (Security Association Database) или БД ассоциаций безопасности.

Каждый узел IPSec также имеет вторую БД - SPD или Security Policy Database (БД политики безопасности). Она содержит настроенную вами политику узла. Большинство VPN решений разрешают создание нескольких политик с комбинациями подходящих алгоритмов для каждого узла, с которым нужно установить соединение.

Настройки включает:

· Симметричные алгоритмы для шифрования/расшифровки данных

· Криптографические контрольные суммы для проверки целостности данных

· Способ идентификации узла. Самые распространенные способы - это предустановленные ключи (pre-shared secrets) или RSA сертификаты.

· Использовать ли режим туннеля или режим транспорта

· Какую использовать группу Diffie Hellman

· Как часто проводить переидентификацию узла

· Как часто менять ключ для шифрования данных

· Использовать ли PFS

· Использовать ли AH, ESP, или оба вместе.

При создании политики, как правило, возможно создание упорядоченного списка алгоритмов и Diffie Hellman групп. В таком случае будет использована первая совпавшая на обоих узлах позиция. Запомните, очень важно, чтобы всё в политике безопасности позволяло добиться этого совпадения. Если за исключением одной части политики всё остальное совпадает, узлы всё равно не смогут установить VPN соединение. При настройке VPN между различными системами уделите время изучению того, какие алгоритмы поддерживаются каждой стороной, чтобы иметь выбор наиболее безопасной политики из возможных.