Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
- Главная
- Автоматическое добавление маршрутов для VPN-соединения в Windows
Автоматическое добавление маршрутов для VPN-соединения в Windows
В последнее время значительно вырос интерес к технологиям удаленного доступа для обеспечения работы сотрудников из любого места. Ключевую роль здесь играет VPN, как универсальное и безопасное средство для получения доступа во внутреннюю сеть предприятия. Наиболее привлекательно использовать для этого те протоколы, которые штатно поддерживаются в Windows, что позволяет организовать соединение на любом ПК без установки на него стороннего ПО. Но у данного способа есть одна проблема — добавление маршрутной информации, сегодня мы рассмотрим один из штатных способов, позволяющих легко управлять маршрутами для VPN-соединений.
Стандартные сетевые возможности Windows многим хороши, кроме одного — управление маршрутами для VPN-соединений. Именно это заставляло многих системных администраторов выбирать альтернативные технологии, например, OpenVPN, но это не совсем удобно если речь идет о личных устройствах сотрудников, так как требует установки дополнительного ПО, что, к тому же, не всегда возможно. Кроме того, мы неоднократно сталкивались с ситуациями, когда пользователи удаляли данное ПО, устанавливали конфликтующие приложения, теряли ярлыки для подключения, блокировали его антивирусным ПО и т.д. и т.п.
Подключение средствами ОС в этом плане более привлекательно, так как позволяет снять большую часть указанных выше проблем и подразумевает единообразие пользовательского интерфейса, что позволяет сделать простые и понятные инструкции.
Но вернемся к нашему вопросу. Для добавления маршрутов в удаленную сеть традиционно использовали несколько методов:
- Статическая маршрутизация — на первый взгляд все просто, что прописали руками — то и работает. Но добавление маршрутов требует привилегий администратора, не всегда возможно заранее прописать маршрут из-за отсутствия интерфейса, при переподключении маршруты могут стать недействительными.
- Маршрутизация на основе классов — требует тщательного планирования адресного пространства, нет возможности прокинуть дополнительные маршруты, сложно работать с сетями 192.168.х.х.
- CMAK и различные скрипты — требуют административных привилегий, сложны в настройке, непрозрачны.
В тоже время начиная с Windows 8 существует штатное решение в виде командлета PowerShell, которое позволяет привязать маршруты к VPN-подключению и добавлять их при его запуске, при отключении соединения маршруты будут автоматически удалены.
Запустим консоль PowerShell и прежде всего узнаем имена имеющихся в системе VPN-подключений:
Результатом работы команды будет информация обо всех коммутируемых подключениях, нас интересует поле Name:
Теперь добавим маршрут к удаленной сети для подключения с именем L2TP MT:
где в параметр ConnectionName содержит имя подключения, взятое в кавычки, а DestinationPrefix — необходимую сеть назначения или узел.
Теперь проверим как это все работает. Проверим таблицу маршрутизации при отключенном VPN-подключении и убедимся, что маршруты в удаленную сеть отсутствуют:
Теперь подключимся к VPN-серверу и снова проверим таблицу маршрутизации — в ней появится указанный нами маршрут к удаленной сети:
Если нужно добавить несколько маршрутов — выполняем команду несколько раз. При этом можно добавлять маршруты не только к удаленной сети, но и к определенному узлу, что в ряде случаев более предпочтительно по соображениям безопасности, например:
Данная команда добавит маршрут к узлу 192.168.111.101, к другим узлам удаленной сети доступа у VPN-пользователя не будет.
Чтобы удалить маршрут следует воспользоваться командой Remove-VPNConnectionRoute, синтаксис которой полностью повторяет команду добавления маршрута:
Как видим, современные версии Windows дают нам в руки достаточно простой и удобный инструмент управления маршрутами для VPN-подключений.
Важно! Данные возможности не поддерживаются в Windows 7.
Дополнительные материалы:
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
Маршрутизация сетей через VPN
Самая распространенная задача при использовании различных VPN-подключений (L2TP/IPsec, PPTP, SSTP) — обеспечить удаленный доступ клиентам в локальную сеть VPN-сервера. В этом случае при подключении клиента на VPN-сервере происходит автоматическая маршрутизация трафика в локальную сеть. Но иногда возникает задача организовать доступ не только к локальной сети VPN-сервера, но и в обратную сторону, т.е. из сети VPN-сервера в удаленную сеть VPN-клиента, чтобы обеспечить обмен данными между двумя сторонами VPN-туннеля.
Предположим, что интернет-центр Keenetic#1 подключен к сети Интернет через провайдера, предоставившего «белый» публичный IP-адрес. На этом интернет-центре будет включен один из VPN-серверов (L2TP/IPsec, PPTP, SSTP).
Интернет-центр Keenetic#2 имеет выход в Интернет через провайдера, который предоставил «серый» IP-адрес.
NOTE: Важно! Интернет-центр Keenetic, на котором будет работать VPN-сервер L2TP/IPsec или PPTP, должен быть подключен к Интернету с белым IP-адресом, а при использовании доменного имени KeenDNS, оно должно быть настроено в режиме «Прямой доступ». При несоблюдении любого из этих условий подключение к такому серверу из Интернета будет невозможно.
Что касается туннеля SSTP, то его основным преимуществом является способность работать через облако, т.е. он позволяет установить подключение между клиентом и сервером, даже при наличии частных IP-адресов с обеих сторон.
Интернет-центр Keenetic#2 автоматически устанавливает подключение к VPN-серверу (Keenetic#1), что позволяет пользователям его локальной сети (Пользователь#2) получать доступ как непосредственно на Keenetic#1 (для подключения к USB-накопителям и принтерам), так и к ресурсам, расположенным в его локальной сети, — компьютерам, серверам NAS и пр. При выполнении приведенных ниже рекомендаций аналогичная возможность доступа обеспечивается и в обратном направлении, т.е. в локальную сеть Keenetic#2 из локальной сети Keenetic#1. Например, Пользователь#1 сможет обратиться к файлам, расположенным в папке общего доступа на компьютере Пользователя#2.
Для того чтобы клиентам локальной сети VPN-сервера были доступны ресурсы локальной сети за VPN-клиентом, нужно добавить статический маршрут, с указанием расположения сети клиента. В нашем примере локальная сеть 192.168.2.0/255.255.255.0 станет доступна через IP-адрес, выданный VPN-сервером подключившемуся клиенту (в нашем случае это будет клиент c IP-адресом 172.16.1.2).
На странице «Маршрутизация» нажмите «Добавить маршрут». В появившемся окне » Параметры статического маршрута » в поле «Тип маршрута» выберите значение «Маршрут до сети», в поле «Адрес сети назначения» укажите удаленную подсеть, к которой вы хотите организовать доступ и которая находится на стороне VPN-клиента.
В поле «Адрес шлюза» следует вписать IP-адрес VPN-клиента, предоставленный VPN-сервером при подключении. В настройках VPN-сервера выключите опцию «Множественный вход» и определите постоянный IP-адрес для VPN-клиента. Сделать это можно на странице настройки VPN-сервера в разделе «Пользователи».
При настройке статического маршрута следует включить опцию «Добавлять автоматически» и в поле «Интерфейс» оставьте значение «Любой».
NOTE: Важно! После добавления маршрута, он сразу не заработает, нужно будет переподключить VPN-туннель. Отключите VPN-соединение и затем установите его снова.
На интернет-центре со стороны VPN-клиента обратите внимание на следующие настройки:
1. При настройке VPN-соединения не нужно включать опцию «NAT для клиентов». Эта настройка служит для доступа клиентов VPN-сервера в Интернет. При подключении VPN-клиент автоматически получит информацию о локальной сети расположенной за сервером. Это избавляет от необходимости настраивать статическую маршрутизацию.
2. Поскольку на интерфейсе VPN-клиента Keenetic#2 по умолчанию включен межсетевой экран, блокирующий все входящие соединения к локальной сети (в нашем примере к сети 192.168.2.x), в нём требуется открыть нужные для работы порты/протоколы.
На странице «Межсетевой экран» выберите из списка интерфейс, на котором будет отслеживаться входящий трафик (это VPN-подключение), и нажмите «Добавить правило» для создания правил доступа по любым протоколам (как правило, достаточно будет открыть доступ по протоколам tcp/udp/icmp).
TIP: Примечание:
a. Если вы установили VPN-подключение, а пинг проходит только до удаленного роутера и не проходит на компьютеры удаленной сети, то вероятнее всего на компьютерах блокирует трафик Брандмауэр Windows (Firewall). Дополнительную информацию можно найти в статье «Настройка Брандмауэра Windows для подключений из сети за VPN-сервером Keenetic».
Если вы пытаетесь выполнить ping компьютера по его IP-адресу, убедитесь, что на компьютере не блокируются входящие подключения (по умолчанию Брандмауэр Windows блокирует icmp-запросы). Попробуйте повторить ping, отключив блокировку.
б. При использовании защищённых VPN-туннелей могут возникать ограничения скорости обмена данными. Дополнительная нагрузка на устройство, связанная с маршрутизацией, обработкой и шифрованием данных в VPN, может вызвать ограничение скорости передачи данных по сравнению с предоставляемой провайдерами пропускной способностью канала. Например, VPN-сервер SSTP работает через облачные серверы Keenetic Cloud, его скорость зависит от числа пользующихся облаком пользователей и их активности.
в. Через VPN-туннель не поддерживается автоматическое определение имен компьютеров и устройств в сети Microsoft Windows, поскольку объединение сетей происходит на третьем уровне модели OSI, с задействованием NAT (трансляции сетевых адресов) и маршрутизации. Ограничения, накладываемые этими факторами, препятствуют работе службы Computer Browser (Обозреватель компьютеров), которая использует немаршрутизируемые типы передачи данных, рассчитанные на рамки одноранговой сети. В связи с этим не будет работать доступ к устройствам удаленной сети по их сетевым именам.
г. Можно объединить несколько домашних сетей, чтобы иметь доступ из каждой сети в любую другую. К VPN-серверу на одном интернет-центре можно можно установить более 10 клиентских одновременных подключений.
Начиная с версии KeeneticOS 2.14 был увеличен лимит количества VPN-туннелей PPTP:
до 100 (для Start, 4G, Lite, Omni, City, Air, Extra и Zyxel Keenetic Air, Start II, Lite III rev.B, 4G III rev.B, Extra II);
до 150 (для DSL и Duo) и до 200 (для Giga и Ultra).
В версиях до 2.14 ограничение для VPN PPTP составляло 10 одновременных туннелей.
Для VPN-туннелей L2TP/IPsec ограничение отсутствует.
д. SIP-телефония, как и другие технологии передачи данных, сможет работать через установленный VPN-туннель.
Пользователи, считающие этот материал полезным: 46 из 48
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
- Главная
- Организация VPN каналов между офисами. Маршрутизация
Организация VPN каналов между офисами. Маршрутизация
Организация каналов между удаленными сетями посредством VPN-соединения одна из самых популярных тем на нашем сайте. В тоже время, как показывает читательский отклик, наибольшие затруднения вызывает правильная настройка маршрутизации, хотя мы специально уделяли внимание этому моменту. Проанализировав наиболее часто задаваемые вопросы, мы решили посвятить теме маршрутизации отдельную статью. Есть вопросы? Надеемся, что после прочтения данного материала их станет меньше.
Прежде всего разберемся, что такое маршрутизация. Маршрутизация — это процесс определения маршрута следования информации в сетях связи. Скажем честно, тема эта весьма глубокая и требующая солидного багажа теоретических знаний, поэтому в рамках данной статьи мы сознательно упростим картину и коснемся теории ровно в той мере, которой будет достаточно для осмысления происходящих процессов и получения практических результатов.
Возьмем произвольную рабочую станцию, подключенную к сети, каким образом она определяет куда посылать тот или иной пакет? Для этой цели предназначена таблица маршрутизации, которая содержит перечень правил для всех возможных адресов назначения. На основании этой таблицы хост (или маршрутизатор) принимают решение, на какой интерфейс и адрес назначения отправить пакет, адресованный определенному получателю.
Чтобы не быть голословными рассмотрим таблицу маршрутов самой обыкновенной рабочей станции. В Windows системах это можно сделать командой:
В итоге мы увидим следующую таблицу:
Все очень просто, нас интересует секция IPv4 таблица маршрута, первые две колонки содержат адрес назначения и маску сети, затем следует шлюз — узел которому следует перенаправить пакеты для указанного назначения, интерфейс и метрика. Если в колонке Шлюз указано On-link, то это означает что адрес назначения находится в одной сети с хостом и доступен без маршрутизации. Метрика определяет приоритет правил маршрутизации, если адрес назначения имеет в таблице маршрутов несколько правил, то используется тот, что имеет меньшую метрику.
Наша рабочая станция принадлежит к сети 192.168.31.0 и, согласно таблице маршрутов, все запросы к данной сети отправляет на интерфейс 192.168.31.175, что соответствует сетевому адресу это станции. Если адрес назначения находится в одной сети с адресом источником, то доставка информации происходит без использования IP-маршрутизации (сетевой уровень L3 модели OSI), на канальном уровне (L2). В противном случае пакет отправляется узлу, указанному в соответствующему сети назначения правилу таблицы маршрутов.
Если такого правила нет, то пакет отправляется по нулевому маршруту, который содержит адрес основного шлюза сети. В нашем случае это адрес роутера 192.168.31.100. Нулевым этот маршрут называется потому, что адресом назначения для него указывается 0.0.0.0. Этот момент является очень важным для дальнейшего понимания процесса маршрутизации: все пакеты, не принадлежащие данной сети и не имеющие отдельных маршрутов, всегда отправляются основному шлюзу сети.
Что сделает маршрутизатор, получив такой пакет? Прежде всего разберемся, чем отличается маршрутизатор от обычной сетевой станции. Если говорить крайне упрощенно, то маршрутизатором (роутером) является сетевое устройство, которое настроено передавать пакеты между сетевыми интерфейсами. В Windows это достигается включением службы Маршрутизация и удаленный доступ, в Linux заданием опции ip_forward.
Решение о передаче пакетов в этом случае также принимается на основании таблицы маршрутизации. Посмотрим, что содержит данная таблица на самом обычном роутере, например, описанном нами в статье: Ubuntu Server. Настраиваем роутер NAT + DHCP + Squid3. В Linux-системах получить таблицу маршрутов можно командой:
Как видим, наш роутер содержит маршруты к известным ему сетям 192.168.31.0 и 192.168.3.0, а также нулевой маршрут к вышестоящему шлюзу 192.168.3.1.
Адрес 0.0.0.0 в колонке шлюза (Gateway) обозначает, что адрес назначения доступен без маршрутизации. Таким образом все пакеты с адресами назначения в сетях 192.168.31.0 и 192.168.3.0 будут отправлены на соответствующий интерфейс, а все остальные пакеты будут переданы дальше по нулевому маршруту.
Следующий важный момент — адреса приватных (частных) сетей, они же «серые», к ним относятся три диапазона:
Данные адреса могут свободно использоваться любым желающим и поэтому они не маршрутизируются. Что это значит? Любой пакет с адресом назначения принадлежащим одной из этих сетей будет отброшен маршрутизатором, если для него нет отдельной записи в таблице маршрутизации. Проще говоря, маршрут по умолчанию (нулевой) для таких пакетов маршрутизатором не применяется. Также следует понимать, что данное правило применяется только при маршрутизации, т.е. при передаче пакетов между интерфейсами, исходящий пакет с «серым» адресом будет отправлен по нулевому маршруту, даже если данный узел сам является маршрутизатором.
Например, если наш роутер получит входящий пакет с назначением, скажем, 10.8.0.1, то он будет отброшен, так как такая сеть ему неизвестна и адреса этого диапазона не маршрутизируются. Но если мы обратимся к этому же узлу непосредственно с роутера, то пакет будет отправлен по нулевому маршруту шлюзу 192.168.3.1 и будет отброшен уже им.
Самое время проверить, как это все работает. Попробуем с нашего узла 192.168.31.175 пропинговать узел 192.168.3.106, который находится в сети за роутером. Как видим, это нам удалось, хотя таблица маршрутов узла не содержит никаких сведений о сети 192.168.3.0.
Как это стало возможным? Так как узел-источник ничего не знает о сети назначения, то он отправит пакет на адрес шлюза. Шлюз проверит свою таблицу маршрутов, обнаружит там запись для сети 192.168.3.0 и отправит пакет на соответствующий интерфейс, в этом несложно убедиться выполнив команду трассировки, которая покажет весь путь нашего пакета:
Теперь попробуем выполнить пинг узла 192.168.31.175 с узла 192.168.3.106, т.е. в обратном направлении. У нас ничего не вышло. Почему?
Давайте внимательно посмотрим таблицу маршрутизации. Никаких записей для сети 192.168.31.0 она не содержит, поэтому пакет будет отправлен маршрутизатору 192.168.3.1, как основному шлюзу сети, который данный пакет отбросит, так как никаких данных о сети назначения не имеет. Как быть? Очевидно, что следует отправить пакет тому узлу, который содержит нужную информацию и может передать пакет по назначению, в нашем случае это роутер 192.168.31.100, который в данной сети имеет адрес 192.168.3.108.
Чтобы пакеты для сети 192.168.31.0 отправлялись именно ему, нам нужно создать отдельный маршрут.
В дальнейшем мы будем придерживаться такой записи маршрутов, что она значит? Все просто, пакеты для сети 192.168.31.0 с маской 255.255.255.0 следует отправлять узлу 192.168.3.108. В Windows маршрут можно добавить командой:
Давайте проанализируем результат, в таблице маршрутизации появился маршрут и все пакеты к сети 192.168.31.0 теперь отправляются роутеру этой сети, что видно из ответа команды ping, но до назначения не доходят. В чем дело? Самое время вспомнить, что одной из основных задач роутера является не только маршрутизация, но и функция сетевого экрана, который явно запрещает доступ из внешней сети внутрь. Если мы временно заменим данное правило разрешающим, то все будет работать.
Добавленные вышеуказанными командами маршруты сохраняются до перезагрузки узла, это удобно, даже если вы сильно накуролесили, достаточно просто выполнить перезагрузку, чтобы отменить внесенные изменения. Чтобы добавить постоянный маршрут в Windows выполните команду:
В Linux в /etc/network/interfaces, после описания интерфейса, следует добавить:
Кстати, это не единственный способ настроить доступ из сети 192.168.3.0 в сеть 192.168.31.0, вместо того, чтобы добавлять маршрут для каждого узла, можно «научить» правильно отправлять пакеты маршрутизатор.
В этом случае узел источник не имеет записей о сети назначения и отправит пакет шлюзу, в прошлый раз шлюз такой пакет отбросил, но теперь мы добавили в его таблицу маршрутизации нужный маршрут, и он отправит пакет узлу 192.168.3.108, который доставит его по назначению.
Мы настоятельно рекомендуем самим потренироваться на аналогичных примерах, чтобы маршрутизация перестала быть для вас черным ящиком, а маршруты — китайской грамотой. После того как возникнет понимание, можно переходит ко второй части данной статьи.
Теперь рассмотрим реальные примеры по объединению сетей офисов через VPN-соединение. Несмотря на то, что чаще всего для этих целей используется OpenVPN и в наших примерах мы также подразумеваем решения на его основе, все сказанное будет справедливо для любого типа VPN-соединения.
Самый простой случай, когда VPN-сервер (клиент) и маршрутизатор сети располагаются на одном хосте. Рассмотрим схему ниже:
Так как теорию, надеемся, вы усвоили и закрепили на практике, проанализируем маршрут пакетов из сети офиса 192.168.31.0 в сеть филиала 192.168.44.0, такой пакет будет отправлен на шлюз по умолчанию, который является также VPN-сервером. Однако данный узел ничего не знает о сети назначения и должен будет откинуть данный пакет. В тоже время мы уже можем обратиться к маршрутизатору филиала по его адресу в VPN-сети 10.8.0.2, так как данная сеть доступна с маршрутизатора офиса.
Чтобы получить доступ к сети филиала нам нужно предать пакеты для этой сети узлу, который является частью этой сети или имеет маршрут к ней. В нашем случае это маршрутизатор филиала. Поэтом на маршрутизаторе офиса добавляем маршрут:
Теперь шлюз офиса, получив пакет для сети филиала, отправит его через VPN-канал маршрутизатору филиала, который, являясь узлом сети 192.168.44.0 доставит пакет по назначению. Для доступа из сети филиала в сеть офиса нужно прописать аналогичный маршрут на маршрутизаторе филиала.
Возьмем схему посложнее, когда маршрутизатор и VPN-сервер (клиент) являются разными узлами сети. Здесь возможны два варианта, передать нужный пакет непосредственно VPN-серверу (клиенту) или заставить это делать шлюз.
Сначала рассмотрим первый вариант.
Для того, чтобы пакеты для сети филиала попали в VPN-сеть мы должны добавить на каждый клиент сети маршрут к VPN-серверу (клиенту), в противном случае они будут отправлены шлюзу, который их отбросит:
Однако VPN-сервер ничего не знает о сети филиала, но может отправлять пакеты в пределах VPN-сети, где есть интересующий нас узел сети филиала, поэтому направим пакет туда, добавив на VPN-сервере (клиенте) маршрут:
Недостаток данной схемы — необходимость прописывать маршруты на каждом узле сети, что не всегда удобно. Его можно использовать если устройств в сети немного или требуется выборочный доступ. В остальных случаях задачу маршрутизации будет правильнее переложить на основной маршрутизатор сети.
В этом случае сетевые устройства офиса ничего не знают о сети филиала и отправят пакеты для него по нулевому маршруту, шлюзу сети. Теперь задача шлюза перенаправить этот пакет VPN-серверу (клиенту), это просто сделать, добавив в его таблицу маршрутизации нужный маршрут:
Про задачу VPN-сервера (клиента) мы упоминали выше, он должен доставить пакеты тому узлу VPN-сети, который является частью сети назначения или имеет маршрут к ней.
Для доступа из сети филиала в сеть офиса потребуется добавить соответствующие маршруты на сетевые узлы филиала. Сделать это можно любым удобным способом, не обязательно также, как это сделано в офисе. Простой реальный пример: все компьютеры филиала должны иметь доступ к сети офиса, но не все компьютеры офиса должны иметь доступ в филиал. В таком случае в филиале добавляем маршрут к VPN-серверу (клиенту) на маршрутизаторе, а в офисе добавляем его только на нужные компьютеры.
В целом, если вы представляете, как работает маршрутизация и каким образом принимается решение о перенаправлении пакетов, а также умеете читать таблицу маршрутизации, то настройка правильных маршрутов не должна вызывать затруднений. Надеемся, что после прочтения данной статьи у вас их также не будет.
Дополнительные материалы:
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал:
