Настраиваем VPN сервер. Часть 2 - Маршрутизация и структура сети.

|

vpn-routing.png

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

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

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

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

Существует несколько вариантов построения виртуальной сети, каждый из них предусматривает свою схему маршрутизации. Рассмотрим их подробнее.

  • Клиенты получают адреса из диапазона локальной сети.

IT-tech-VPN1.pngДанный вариант требует поддержки со стороны сервера Proxy ARP, который позволяет объединить две не связанные на канальном уровне сети в одну. Все хосты будут "считать" что находятся в одной физической сети и обмениваться трафиком без какой либо дополнительной маршрутизации.

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

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

IT-tech-VPN2.pngЭтот вариант предусматривает выделение удаленных клиентов в отдельную подсеть, в нашем случае это 10.0.1.0/24. Как нетрудно заметить обе подсети могут быть частью общей сети 10.0.0.0/23. Мы можем управлять структурой сети двумя способами: при помощи маски подсети или маршрутизации. Первый вариант позволяет переместив ПК в сеть 10.0.0.0/23 (изменив маску с 255.255.255.0 на 255.255.254.0) дать ему доступ к обеим подсетям.

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

Для доступа клиентских ПК из одной подсети в другую нам потребуется прописать на них статические маршруты. Мы будем использовать запись вида:

X.X.X.X mask Y.Y.Y.Y Z.Z.Z.Z

где X.X.X.X сеть, Y.Y.Y.Y маска сети, Z.Z.Z.Z шлюз. Добавить маршрут в среде Windows можно командой:

route add X.X.X.X mask Y.Y.Y.Y Z.Z.Z.Z

В Linux:

route add -net X.X.X.X netmask Y.Y.Y.Y gw Z.Z.Z.Z

Действие данных команд сохраняется до перезагрузки и поэтому если вы что-то сделали не так, перезагрузите ПК и попробуйте снова. Убедившись что все работает нужно добавить маршруты на постоянной основе. В Windows это делается добавлением к команде ключа -p:

route add X.X.X.X mask Y.Y.Y.Y Z.Z.Z.Z -p

В Ubuntu потребуется добавить в файл /etc/network/interfaces, после описания интерфейса, строки:

up route add -net X.X.X.X netmask Y.Y.Y.Y gw Z.Z.Z.Z

Вернемся к нашим маршрутам. Для доступа удаленных клиентов в нашу локальную сеть необходимо прописать маршрут к ней:

10.0.0.0 mask 255.255.255.0 10.0.1.1 

И наоборот, для доступа из локальной сети к удаленным клиентам, если такой необходимости нет, данный маршрут можно не прописывать:

10.0.1.0 mask 255.255.255.0 10.0.0.1

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

  • Клиенты получают адреса из диапазона который не маршрутизируется из локальной сети.


IT-tech-VPN3.pngДанная схема обычно не предусматривает маршрутизацию из локальной сети в удаленную и применяется для подключения клиентов с низкой степенью доверия (заказчики, дилеры и т.п.). При такой реализации удаленным клиентам доступны только ресурсы опубликованные в VPN, для доступа к локальной сети одного указания маршрута (как в предыдущем случае) будет недостаточно, потребуется еще настройка сервера на трансляцию пакетов (NAT) из локальной сети в удаленную и наоборот.

Опубликовать ресурс в VPN можно несколькими способами: разместить его на VPN сервере и разрешить доступ к нему из удаленной сети, пробросить в удаленную сеть нужный порт или подключить нужный ресурс в качестве клиента удаленной сети. На нашей схеме мы опубликовали подобным образом терминальный сервер 10.0.0.2, который будет доступен в удаленной сети по адресу 172.16.0.2

  • Объединение двух подсетей

IT-tech-VPN4.pngДанная схема применяется для объединения нескольких подсетей (центрального офиса и филиалов) в единую сеть, структура такой сети более сложна, но при понимании того, какие пакеты и через какие интерфейсы нам необходимо направлять все очень быстро становиться на свои места. В нашем случае X.X.X.X выделенный IP адрес в центральном офисе, филиалы могут иметь серые IP адреса. На роутере центрального офиса расположен VPN сервер, роутер филиала подключается как клиент.

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

Поэтому на клиентах подсети LAN1 прописываем маршрут к LAN2:

10.0.1.0 mask 255.255.255.0 10.0.0.1

На роутере подсети LAN1 прописываем маршрут на другой конец туннеля:

10.0.1.0 mask 255.255.255.0 172.16.0.2

Для подсети LAN2 маршруты будут выглядеть следующим образом, для клиентов:

 10.0.0.0 mask 255.255.255.0 10.0.1.1

Для роутера:

10.0.0.0 mask 255.255.255.0 172.16.0.1

В следующих частях нашей статьи мы рассмотрим практические реализации VPN сервера на платформах Linux и Windows.

Дополнительные материалы:


  1. Настраиваем VPN сервер. Часть 1 - Общие вопросы
  2. Настраиваем VPN сервер. Часть 2 - Маршрутизация и структура сети
  3. Настраиваем VPN сервер. Часть 3 - PPTP. Платформа Linux
  4. Настраиваем VPN сервер. Часть 4 - PPTP. Платформа Windows
  5. Настраиваем VPN сервер. Часть 5 - L2TP. Платформа Windows
  6. Ubuntu Server. Форвардинг PPTP средствами iptables
  7. Организация VPN каналов между офисами при помощи OpenVPN
  8. Организация каналов между офисами при помощи OpenVPN с дополнительной парольной защитой
  9. Организация VPN каналов между офисами. Маршрутизация
  10. Организация каналов между офисами при помощи OpenVPN на платформе Linux
  11. Почему тормозит OpenVPN? Размер буферов приема и отправки
  12. SSH-туннели на службе системного администратора

 

Подписка на блог

Наш канал на YouTube Мы в Твиттере

Архивы по месяцам

Реклама

Статистика

 

Яндекс.Метрика

География

Flag Counter

Реклама

Об этой записи

Сообщение опубликовано 08.08.2010 13:08. Автор — Уваров А.С..

Предыдущая запись — Настраиваем VPN сервер. Часть 1 - Общие вопросы.

Следующая запись — Установка ключа защиты 1С Предприятие на Ubuntu 10.04

Смотрите новые записи на главной странице или загляните в архив, где есть ссылки на все сообщения.

Реклама

Облако тегов