VPN intro

by

Virtual Private Network – кто все эти люди?

Изначально виртуальный частные сети (VPN) были разработаны для того, чтобы смягчить или полностью исключить такие проблемы, как передача данных прямым текстом по таким протоколам как telnet, ftp, pop, smtp. Заодно было бы неплохо решить проблемы прослушивания трафика, выдачи злодеем себя за легитимного пользователя и атаки типа MitM – man in the middle (с помощью аутентификации, проверки целостности пакетов и шифрования).

disclaimer: цель этой и следующих статей не является пересказ похожей информации из бесчисленных источников, а мое желание уложить все в голове по причине того, что в security в целом и в VPN в частности я, что называется, “плаваю”.

Режимы подключения

Существует два режима – туннельный и транспортный (tunnel mode, transport mode).

В transport mode соединение устанавливается между сущностями с реальными адресами источника и получателя. В этом случае злодей в состоянии подсмотреть ip адреса, между которыми происходит обмен зашифрованной информацией, а вот “разглядеть” полезную нагрузку уже не выйдет.

Tunnel mode. Один из недостатков транспортного режима состоит в том, что приходится устанавливать соединения для каждого устройства в отдельности, что, к примеру, в случае 3х площадок по два маршрутизатора на каждой даст 72 соединения.

Эту проблему призван решить tunnel mode, где существует медиум для защиты передаваемой информации между отправителем и получателем. В качестве медиума могут выступать сервер, маршрутизатор, МСЭ, VPN концентратор.

Типы VPN
  • Site-to-Site или Lan-to-Lan – предоставляют безопасный доступ между удаленными площадками прозрачно для пользователей и приложений.
  • Remote Access – предоставляют доступ конечным пользователям к сетевой инфраструктуре.
  • User-to-User – защита подключения между конечными устройствами.
VPN компоненты
  • Аутентификация – позволяет подтвердить, что устройство или пользователь тот за кого он себя выдает и может получить доступ к данному сервису посредством ключей (pre shared keys) или цифровых сертификатов.
  • Инкапсуляция – определяет какое приложение или протокол будет помещено в полезную нагрузку. Некоторые реализации VPN помещают в нагрузку только информацию приложений, другие же позволяют шифровать layer 3 пакет или, даже, layer 2 фрейм. То, как информация будет инкапсулирована важно хотя бы потому, что есть некоторые проблемы с преодолением МСЭ и NAT/PAT, но об этом позже.
  • Шифрование данных – тут все просто. Берется какая-то информация и прогоняется через алгоритм шифрования (DES, 3DES, AES, RSA etc).
  • Проверка целостности пакетов – с помощью хэш-функций (MD5, SHA) к пакету добавляется подпись, которая позволяет убедиться в том, что пакет прибыл в неизменном виде.
  • Управление ключами – к примеру, позволяет прозрачно менять ключи по истечению какого-то времени (например на следующей неделе ключ меняется на derPar01).
  • Управление адресным пространством.
Дизайн VPN

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

  • Подключения типа точка-точка (site-to-site, device-to-device).
  • полносвязные и частично связные топологии (fully meshed, partial meshed).

Определится с возможными проблемами и вариантами их решений (остановимся на этом подробнее):

  • Выбор траффика для шифрования.
  • Фрагментация пакетов.
  • Выбор типа приложений.
  • Защита траффика.
  • Преодоление NAT и МСЭ.

Выбор трафика для шифрования – представим ситуация, когда в случае с remote access VPN удаленный пользователь подключен к корпоративной сети и хочет не только получить доступ к инфраструктуре компании, но и смотреть смешных котиков. Согласитесь, мало смысла гонять котиков через VPN  и нагружать дополнительно WAN канал, если можно с помощью фичи split tunneling отправлять через VPN только действительно важные данные.

Фрагментация пакетов – с VPN все тормозит и CPU load на терминаторе подключений под 100%? Не самой последней причиной может стать фрагментация пакетов. Типичный MTU – 1500 байт, VPN добавляет еще 80, вот и приходится, скажем, маршрутизатору не только заниматься шифрованием/дешифровкой пакетов, но и их фрагментацией с последующим увеличением количества пакетов для шифрования в два раза.

Выбор типа приложений – это когда мы не хотим шифровать SSH и HTTPS, но хотим Telnet и HTTP.

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

Проблемы с трансляцией адресов и МСЭ.

IPsec, к примеру, имеет два протокола для передачи данных между устройствами – AH (Authentication Header) и ESP (Encapsulation Security Protocol/Payload). AH занимается только проверкой целостности пакетов, основываясь на хэше IP отправителя и получателя. Так как в процессе трансляции адреса один из них меняется (или меняется номер порта при PAT), то наступает пичалька. ESP и шифрует и проверяет целостность пакетов, причем проверка целостности не осуществляется на основании “внешних” ip отправителя и получателя, однако это не значит, что у ESP нет проблем с преодолением PAT. И AH и ESP – протоколы 3ого уровня. Устройства, которые занимаются PAT требуют, чтобы информация была инкапсулирована в TCP или UDP сегменты. Но у AH и ESP нет номеров портов, что портит всю картину.

“Но как же так?!” – спросит пытливый читатель – “ведь ICMP тоже layer 3, однако я замечательно могу пинговать ya.ru из-за PAT?!”. Устройства могут осуществлять трансляции layer 3 протоколов, некоторые из них умеют даже AH и ESP.

Решается эта проблема с помощью NAT-T (NAT traversal) когда ESP IPsec пакеты инкапсулируются в UDP сегменты.

С МСЭ другая проблема – настроено инспектирование сессий и запрещен доступ из внешних сетей. IPsec по своей натуре создает два односторонних соединения и если МСЭ, за которым вы находитесь, не знает про SPI (Security Parameter Index), то сессия от VPN терминатора к вам пропущена не будет.

Другой “use case” – банально запрещены все протоколы кроме IP и ICMP.

Некоторые реализации VPN

GRE (Generic Route Encapsulation) – изначально разработанный Cisco протокол 3 уровня для того, чтобы брать, к примеру, AppleTalk пакет, инкапсулировать его в IP пакет и по IP сети передавать в другой сетмент где живет тот же AppleTalk.

Увы, GRE не проводит аутентификацию, шифрование или проверку целостности, однако может быть совмещен с другими решениями, такими как IPsec.

IPsec (IP security) – так же протокол 3 уровня, поддерживающий транспорт IP протоколов. Так как GRE IP протокол, то через GRE туннель, проложенный в IPsec VPN соединении можно защищать не TCP/IP трафик (у кого там завалялись новеловские IPX сетки?).

IPsec фреймворк обеспечивает конфиденциальность передаваемой информации (с помощью DES, 3DES, AES алгоритмов шифрования), ее целостность (MD5, SHA хэш-функции) и аутентификацию (pre-shared keys, RSA сертификаты, RSA псевдослучайные значения – RSA encrypted nonces).

L2TP – Layer 2 tunneling protocol – внебрачный сын Cisco и Microsoft. Сам по себе не занимается шифрованием, однако так же может работать поверх IPsec. Целиком инкапсулируется в UDP сегмент.

SSL VPN (Secure Socket Layer) – обычно воспринимается исключительно как HTTPS протокол, однако существует воз и маленькая тележка remote access VPN, которые целиком и полностью полагаются на SSL (Citrix Access Gateway, Cisco AnyConnect). Иногда даже без установки стороннего софта (clientless SSL VPN).