Подписаться  на наше издание быстро и дешевле чем где-либо Вы можете прямо сейчас! Подписаться!

 

 

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


Прошли времена, когда у человека был всего один компьютер. У Homo Informaticus, как минимум, два устройства — на работе и дома. А если у человека два дома, то и домашних компьютеров, соответственно, нужно две штуки. А если считать компьютерами еще и цифровые камеры с мобилками, то на одного цивилизованного пользователя приходится уже по пять-десять цифровых устройств. Умножив же все это на количество активных пользователей в одной семье, получим и вовсе несусветную цифру :).


Это, конечно, скорее хорошо, чем наоборот, однако возникает проблема хранения файлов: выяснить, что и где находится, все сложнее. Да пусть вы и знаете, что данные, к примеру, у вас дома — но вы-то в этот момент находитесь на работе, так что это тоже мало помогает их оттуда получить.


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


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


До сих пор мы говорили, в основном, об отдельно взятом пользователе — однако у фирм и компаний проблемы те же, только умноженные на сложность решаемых задач. Филиалы и офисы, равно как и отдельные сотрудники — все хотят обмениваться данными без особых проблем, а также пользоваться общими приложениями. Опять-таки, существует множество "обходных" путей, вроде ftp-серверов, почтовых ящиков IMAP или groupware. Но это, как говаривал небезызвестный поручик, то же самое, что нюхать цветы в противогазе: если вдруг файл не находится на ftp-сервере или если groupware не реализует желаемую функцию, то вы можете оказаться в весьма непростой ситуации. Особенно это обидно, если вы находитесь действительно далеко, буквально на другом конце земли — приходится переводить коллег в режим "удаленного управления" и выдавать команды вроде "поищи там в договорах, должно быть — или не там, а где-то в другом месте, может, на том компе возле окна, или не на том…".


VPN? What VPN?


Одним, но отнюдь не единственным решением, позволяющим немного упростить вещи в этом мире, являются частные виртуальные сети — VPN. Многие воспринимают слово "виртуальный" как нечто ненастоящее, хотя первоначальное значение слова как раз "истинный", "действительный". В науке таким образом обозначаются явления, которые можно наблюдать визуально, наглядно — например, виртуально ручка со стола может полететь (переместиться) прямо на потолок. Ей ничего не мешает — ну, а не летит потому, что ей не хочется… Хотя и может. Называется виртуальным перемещением.


Так и виртуальные сети — они вполне реальны, вполне видимы, хотя чтобы ощутить их существование, приходится выполнить пару дополнительных операций (в примере с ручкой, например, достаточно резко перевернуть дом вверх тормашками; сложно — но можно). Собственно, операций всего-то две: инкапсуляция и шифрование. Идея проста: в одном месте IP-пакеты шифруются и упаковываются в другие IP-пакеты (в так называемую оболочку, wrapper), передаются к месту доставки и там распаковываются. В минимальном варианте выглядит как IP(SHA(IP))-инкапсуляция.

 


Любая схема VPN обязательно включает "облако" интернет - хотя, возможно,
лучше бы нарисовать темный лес, населенный волками


Просто? Не совсем. Во-первых, в общем случае пакеты могут быть любого происхождения, а не только IP. Среда распространения диктует свои правила: Ethernet упаковывает IP в одни упаковки, а Wireless Intenet — в другие. Точно так же и для VPN вам может понадобиться какая-то особая форма упаковки.


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


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


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


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


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


Технический уровень


Если VPN — это, так сказать, коммерческий термин высокого уровня, апеллирующий к умам менеджерского состава, то на техническом уровне он реализуется как безопасное туннельное соединение. Характерно: сервер "Майкрософт" оперирует термином VPN, как бы подчеркивая — все остальное не вашего ума дело. Напротив, в Linux везде идет речь о туннелях, хотя в сети и есть прекрасный VPN Howto — потому что в Linux все именно что нашего ума дело. Помимо прочего, у меня нет лицензионного MS-сервера — и, надеюсь, у вас тоже. Так что не будем впадать в грех пиратства, а просто займемся Linux.


Существует несколько способов установить VPN:

  1. Описанный в VPN Howto способ устанавливает туннель посредством ssh, после чего запускается pppd для установки соединения PPP поверх этого соединения (выглядящего, как псевдотерминал).
  2. PPTP — протокол, используемый "Майкрософт" для построения VPN. Существует также OpenSource-версия этого протокола, с которым постоянно возникают какие-то проблемы. Если есть интерес, то PPTP описан в VPN Masquerade HOWTO.
  3. IP Sec. Вместо ssh используется другой безопасный способ тунеллирования — IP Sec. Маршрутизация такая же, как и в методе №1.
  4. CIPE — еще один способ кодирования трафика. В качестве пакетов-носителей для IP выступают закодированные UDP-пакеты. Данный способ разработан с учетом работы через NAT и SOCKS прокси, поддерживает Linux и MS Windows.

Не усложняя себе жизнь, рассмотрим первый метод установки VPN. Если вкратце, то первая часть работы по настройке — это создание пользовательских эккаунтов типа:

 

frank:*:504:101:Frank Jones (home),,,:/home/vpn-users:/usr/sbin/pppd

 

Как видите, эти пользователи на совсем обычны — для них вообще не разрешен вход в систему с помощью ввода пароля (звездочка во втором поле), проверкой прав будет заниматься ssh на основе открытых ключей. Все "VPN-подключанты" имеют один общий домашний каталог, и, ко всему, в качестве командной оболочки для них выступает pppd.


Пропустим длинные объяснения, почему не нужно ставить на VPN-шлюз другие сервисы и делать его уязвимым. Я не думаю, что все так страшно, но, конечно, лучше каждый сервис ставить на отдельный компьютер. Конечно, взлом (или влом) через VPN в Windows-сеть может заметно развлечь хакера, однако для "хорошей" Linux-локалки риск "экспоушена" критических данных значительно меньше. Можете поставить за VPN-шлюзом еще пару DMZ-брандмауэров, если считаете, что в вашей локалке есть интересные данные :).


Второй этап — настройка ssh. Дело это не сложное, но раз уж мы отказались от паролей один раз, то нужно и далее "держаться за ключи". Файл /etc/sshd_config может иметь вид:

 

PermitRootLogin yes
IgnoreRhosts yes
StrictModes yes
QuietMode no
CheckMail no
IdleTimeout 3d
X11Forwarding no
PrintMotd no
KeepAlive yes
RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
UseLogin no

 

Тут все ясно: PasswordAuth — no, RSAAuth — yes. После этого вы, в принципе, готовы подлогониться с удаленного хоста по ssh. Конечно, надо будет еще обменяться публичными ключиками…


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


Маршрутизация


Чтобы настраивать маршрутизацию для VPN, нужно для начала иметь ядро, скомпилированное с возможностями advanced routing, masquerade и т.д. Если вы используете расхожую дисковую инсталляцию Linux на ядре 2.6, то с вероятностью 95% вы уже имеете все что нужно: обычно маршрутизацию отключают в специальных дистрибутивах, например в пользовательском Ubuntu.


Правила ipchains выглядят так:

 

ipchains — F forward
ipchains — P forward DENY
ipchains — A forward -j ACCEPT -s 192.168.13.0/24 -d 172.16.0.0/12

 

На русском языке это можно прочитать так: очистить цепочку правил forward, установить там политику "отказать всем", хотя если пакеты идут из 192.168.13.0/24 в 172.16.0.0/12, то "перепрыгнуть" (-j ака --jump) через запрет и разрешить прохождение.


Что это дает? А то, что если какое-то невнятное приложение попытается через наш туннель "копать" еще какие-то адреса, кроме принадлежащих нашей локальной сети, то это не пройдет. Мы предполагаем, что пользователь и так имеет доступ к интернету — иначе как же мы получаем VPN? А ежели кто-то хочет ковырять дальше — то это 100% душман.


Все, выталкиваем наш трафик на нужный интерфейс и указываем, куда ему идтить:

 

route add -net 192.168.0.0 netmask 255.255.0.0 gw 172.16.254.254 dev eth1

 

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


Клиентская сторона


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


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


Для дальнейшего вам понадобится "кустомный" пакет pty-redir, который легко найти в интернете. Он создает псевдотерминал tty и соединяет его с любой программой, в нашем случае — с ssh. Остальные параметры относятся к ssh и не представляют собой ничего интересного:

 

pty-redir /usr/bin/ssh -t -e none -o 'Batchmode yes' -c blowfish -i \ /root/.ssh/identity.vpn -l joe > /tmp/vpn-device
sleep 10

 

pppd `cat /tmp/vpn-device`
sleep 15

 

route add -net 192.168.0.0 gw vpn.comizdat.com netmask 255.255.0.0

 

Не будем особо останавливаться на том, как конфигурировать pppd,— главное, чтобы в /etc/ppp/options были строки:

 

ipcp-accept-local
ipcp-accept-remote
proxyarp
noauth

 

Также понятно, что нужно настроить тех самых "ненормальных" пользователей:

 

groupadd vpn-users
mkdir /home/vpn-users
mkdir /home/vpn-users/.ssh

 

Есть там и еще пара "заковырок", таких как установка одинакового UID и GID для всех пользователей вручную или генерация и менеджмент ключей ssh, но поскольку к VPN все это прямого отношения не имеет, то будем надеяться, что вы уже встречались с такими вещами.


В остальном: VPN Howto покажет и расскажет, как обернуть процесс инициализации и проверки туннеля в виде красивых скриптов, которые смотрят на блокировку PID, а также присутствует ли блокировка и т.д., и т.п. — все очень похоже на любой другой сервис. Откровенно говоря, никогда не доходили руки до такой красоты, но почитать и поучиться можно.


Другие варианты


Как уже было сказано, существует множество методов заставить пакеты "перепрыгивать" из одной сети в другую поверх интернета. Мы рассмотрели самый "линуксовый": идея — ничего нового не изобретать, увязав три уже существующих компонента (псевдоконсоль, ssh и pppd) плюс немного настроек пользователей. Кратко остановимся на других вариантах.


PPTP/L2TP


Упоминавшийся PPTP от "Майкрософт" — вовсе не плохая система тунеллирования. Главный плюс — многопротокольность: поддерживаются IP, IPX и NetBEUI (куда ж "Майкрософт" без него?). Существенное ограничение: сервером VPN легально может выступать только MS Windows NT Server. В качестве клиентской части таких ограничений нет, так что существует и OpenSource клиентская часть. Естественно, что в этот протокол встроены Microsoft-специфичные механизмы защиты, такие как MS-CHAP, а само подключение осуществляется в терминах концепции RAS. То есть изначально PPTP создавался для диал-ап’еров и не был рассчитан на соединение двух сетей.


Дополнительный протокол L2TP предназначен для установки на стороне провайдера, так чтобы кодированием занимался провайдер, а не клиент и сервер. Это, конечно, стоит денег — за тем, как говорится, и приходили.


Откровенно говоря, я бы не взялся интегрировать Linux в PPTP-среду — как говорится, "лебедь красив именно как лебедь". Хотя для "майкро-мира" это довольно стабильный, надежный и, как минимум, достаточно старый метод построения VPN. Кстати, в документации по PPTP встречается такая красивая фраза: "PPTP is built into Windows NT Server, which is an open platform…". А вы говорите: "жлобы" — да это ж наши хлопцы! :)


IPSec


Второй в порядке альтернативных вариантов — VPN на основе IPSec. Это такой новомодный протокол, который включает "все в одном": аутентификацию, тунеллинг, кодированный трафик и даже аудит соединений. Короче, IPSec сделан для VPN — и наоборот.


Что важно: разработали этот "супер IP" инженеры из IETF специально для IPv6, но работает он и с обычным IPv4 (RFC 2401) А значит, всем равняться на стандарт, который, кстати, объявлен "самым полным и универсальным решением обеспечения сетевой безопасности". Конечно, можно отключить любые возможности из IPSec и использовать его, например, как ssh,— только для кодирования трафика.


Для улучшения защиты IPSec использует IKE, Internet Key Exchange: для начальной стадии используется установленный вручную публичный ключ, ключ аутентификации и т.д. Эти ключи используются только на этапе обмена IKA, при этом генерируются новые ключи для данного сеанса, происходит обмен ими — так что весь остальной трафик будет закодиован по новым ключам. Как известно, использование постоянных ключей потенциально приводит к взлому. IKA решает эту проблему путем "ухода от стереотипов".


IPSec может работать как в транспортном режиме, когда соединяется два хоста, так и в режиме туннеля, когда для соединения используется два специальных маршрутизатора (не факт, что выделенных). Можно также применить IPSec как к целому трафику по определенной подсети (маршруту), так и только на отдельном порту: первое используется для выделенных VPM-шлюзов, а второе — для отдельных IPSec-aware серверных приложений.


Кроме прочего, IPSec больше относится к ядру BSD и поставляется вместе со многими дистрибутивами, так что это естественный выбор для "красных бесов" (при этом понадобится перестройка ядра, GENERIC не включает IPSec). Вместо этого в Linux принято "нажимать" на ssh — хотя, конечно, все открыто и доступно, порт IPSec/IKA называется FreeS/Wan (иногда пишется FreeSwan). Даже ipsec-howto.org есть.


CIPE


Новый и интересный протокол, одинаково хорошо реализованный для Linux и MS Windows и созданный как раз для построения "готовой" VPN. В любом случае CIPE выглядит как сетевой интерфейс (не спецификация, а железный, NIC) — под Windows даже устанавливается специальный драйвер этого интерфейса.


Не могу ничего сказать о настройке и работе самой VPN, поскольку не имею второго "желающего конца" для установки этого типа VPN. По крайней мере, установка в Linux прошла без проблем, а настройки в MS Windows через панель управления выглядят понятно. Так же, как и IPSec, CIPE "туннелит" весь IP, а не только TCP, как это делает ssh (ssl, если уж на то пошло). Автор и мэйнтейнер CIPE — один человек, Олаф Тиц, так что это протокол, продукт и технология в одном лице, а это хороший признак, позволяющий надеяться, что одна часть программы не будет работать во вред другой, как это порой случается в мире OpenSource. Будете в Германии — передавайте Олафу привет. Драйвер CIPE для Windows можете найти на нашем диске.


И в чем же правда?


А правда в следующем: VPN — это просто набор из трех букв, ничего толком не обозначающий. Что скрывается за этими буквами, знает только дед Бабай. Предположительно, должна наблюдаться маршрутизация, инкапсуляция, шифрование трафика, безопасная аутентификация и дополнительные фильтры iptables. Рассмотренный вариант — самый "геройский", то есть "сделано руками, чтобы работало".


Другие варианты — специфика вашей среды: если вы всюду окружены MS Windows, то вам и PPTP в руки. По уму лучше всего разобраться в IPSec, хотя бы по ipsec-howto.org, но умной информации там немеряно — я этот туториал так и не прошел.


Кстати, зайдите на http://vpnlabs.org/ — там много такого, что поможет вам если и не совсем разобраться, то, по крайней мере, установить и пользоваться VPN. А это уже немало.

2005.09.28
19.03.2009
В IV квартале 2008 г. украинский рынок серверов по сравнению с аналогичным периодом прошлого года сократился в денежном выражении на 34% – до $30 млн (в ценах для конечных пользователей), а за весь календарный год – более чем на 5%, до 132 млн долл.


12.03.2009
4 марта в Киеве компания Telco провела конференцию "Инновационные телекоммуникации", посвященную новым эффективным телекоммуникационным технологиям для решения задач современного бизнеса.


05.03.2009
25 февраля в Киеве компания IBM, при информационной поддержке "1С" и Canonical, провела конференцию "Как сохранить деньги в условиях кризиса?"


26.02.2009
18-19 февраля в Киеве прошел юбилейный съезд ИТ-директоров Украины. Участниками данного мероприятия стали ИТ-директора, ИТ-менеджеры, поставщики ИТ-решений из Киева, Николаева, Днепропетровска, Чернигова и других городов Украины...


19.02.2009
10 февраля в Киеве состоялась пресс-конференция, посвященная итогам деятельности компании "DiaWest – Комп’ютерний світ" в 2008 году.


12.02.2009
С 5 февраля 2009 г. в Киеве начали работу учебные курсы по использованию услуг "электронного предприятия/ учреждения" на базе сети информационно-маркетинговых центров (ИМЦ).


04.02.2009
29 января 2009 года в редакции еженедельника "Computer World/Украина" состоялось награждение победителей акции "Оформи подписку – получи приз!".


29.01.2009
22 января в Киеве компания "МУК" и представительство компании Cisco в Украине провели семинар для партнеров "Обзор продуктов и решений Cisco Small Business"

 

 
 
Copyright © 1997-2008 ИД "Комиздат".