Polytech-soft.com

ПК журнал
2 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Добавление маршрутов при работе с vpn

Добавление маршрутов при работе с vpn

Имеется удаленная подсеть 192.168.0.0/24. В ней роутер с адресом 192.168.0.1 раздает интернет. В подсети имеется сервер Windows 2003 с адресом 192.168.0.10, на нем настроен прием VPN подключений. На роутере, соответственно, настроен форвардинг впн-порта на сервер, чтобы можно было подключаться к VPN-серверу из инета.

При подключении клиента по VPN его виртуальному VPN-интерфейсу присваивается айпишник из диапазона 10.11.0.0/24, адрес сервера в этом диапазоне — 10.11.0.1.

На роутере 192.168.0.1 прописан маршрут: network 10.11.0.0, netmask 255.255.255.0, gateway 192.168.0.10. Благодаря ему компьютеры локальной сети могут пинговать впн-клиентов по их виртуальным айпишникам.

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

Если галку «использовать основной шлюз в удаленной сети» снять, то возникает проблема: после подключения клиент не видит удаленную подсеть.

Чтобы клиент её увидел, нужно прописать на нем маршрут вида: network 192.168.0.0, netmask 255.255.255.0, gateway 10.11.0.бла, где «10.11.0.бла» — айпи-адрес VPN-интерфейса клиента. После прописывания такого маршрута становится возможным доступ к ресурсам удаленной локальной сети (даже DNS работает).

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

Когда я настраивал полностью аналогичную конфигурацию на OpenVPN, то такой проблемы не возникло. В конфигруацонном файле сервера OpenVPN я прописал директиву push «route 192.168.0.0 255.255.255.0», благодаря которой соответствующий маршрут автоматически создавался при подключении. При этом, разумеется, интернет-трафик клиента не перенаправлялся в VPN-туннель.

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

Благодарю всех, кто откликнется.

1. RU_Taurus , 03.06.2009 10:27
MauS
Когда я настраивал полностью аналогичную конфигурацию на OpenVPN, то такой проблемы не возникло. В конфигруацонном файле сервера OpenVPN я прописал директиву push «route 192.168.0.0 255.255.255.0», благодаря которой соответствующий маршрут автоматически создавался при подключении.
VPN-клиент получает адрес автоматически с виндового DHCP? Если да, то отдавать ему маршрут по DHCP.
2. MauS , 03.06.2009 10:54
RU_Taurus
Нет, адрес присваивается из указанного диапазона.

Но я пробовал сделать, как вы предложили. Это ничего не меняет. А «отдавать ему маршрут по DHCP» — такой опции нигде не нашел.

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

3. RU_Taurus , 03.06.2009 11:05
MauS
Я уже честно говоря не помню как это делается в виндовом DHCP, но для него вроде никто dhcp-options не отменял (адрес роутера тоже опцией отдается кстати). В никсовом ICS это реализовано и работает.
4. яверт , 03.06.2009 11:09
MauS
что вам мешает прописать
route add 192.168.0.0 MASK 255.255.255.0 10.11.0.1 Metric 20
5. MauS , 03.06.2009 11:14
яверт
1) Это противоречит условию задачи (см последний абзац первоначального поста).
2) Этот маршрут неверен. При попытке его прописать выдается ошибка «шлюз не лежит в той же подсети».

RU_Taurus
Разумеется, на DHCP сервере прописан шлюз. Однако при подключении по VPN, клиенту он не назначается. Не уверен, как это на самом деле, но предполагаю, что DHCP-сервер не общается с клиентом; он общается с VPN-сервером, выдает ему айпишник, а VPN-сервер уже назначает этот айпишник клиенту.

6. RU_Taurus , 03.06.2009 11:28
MauS
Поверьте, я бы вам без проблем подсказал как это решается на платформе Windows, но к сожалению (или к счастью) уже достаточно давно не занимаюсь администрированием данной платформы. Могу лишь утверждать, что в связке ICS+mpd маршруты при подключении VPN-клиента отдаются.
7. Джамаль , 03.06.2009 11:43
MauS

Разумеется, на DHCP сервере прописан шлюз. Однако при подключении по VPN, клиенту он не назначается.

Найди на DHCP-сервере опцию под названием Static route (номер 033) и в неё впиши требуемый тебе маршрут.

8. vinni , 03.06.2009 12:27
MauS
PPTP-сервер и нормальный комплект маршрутов!, #31 (http://forum.ixbt.com/topic.cgi? >Там правда ещё и ISA, но суть та же — РРТР-клиенту выдаются маршруты с DHCP-сервера.
Ну а сама опция, как уже сказно — Static Route

яверт
что вам мешает прописать
route add 192.168.0.0 MASK 255.255.255.0 10.11.0.1 Metric 20

1. Как уже сказали — это неверно
2. Адрес РРТР-интерфейса клинета может измениться, а значит надо писать нетривиальный скрипт
3. У юзера (особенно если он посторонний) может не быть прав на route add, может не хватать ума, может быть другая ОС

Разумеется, на DHCP сервере прописан шлюз. Однако при подключении по VPN, клиенту он не назначается.
А весело бы было если бы он назначился, правда? Не задумывались?

цитата: RU_Taurus:
MauS
Поверьте, я бы вам без проблем подсказал как это решается на платформе Windows, но к сожалению (или к счастью) уже достаточно давно не занимаюсь администрированием данной платформы. Могу лишь утверждать, что в связке ICS+mpd маршруты при подключении VPN-клиента отдаются.

Да кто ж спорит. У меня на OpenVPN тоже маршрут отдавался благополучно.

Маршрутизация сетей через 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-адрес, выданный сервером подключившемуся клиенту (в нашем случае это клиент 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-туннель.

Пользователи, считающие этот материал полезным: 27 из 29

Настройка VPN в Windows, изменение параметров маршрутизации

Часто бывает, когда нам требуется VPN соединение с рабочей сетью из дома. Для начала нам требуется создать этот самый VPN, конечно при условии, что есть сервер, к которому мы будем подключаться, а так же логин и пароль для авторизации. После того как мы создаём соединение в WINDOWS, подключаемся, кроме доступа к сети мы ещё и получаем интернет, который так же работает через рабочую сеть. А это по разным причинам может быть не всегда удобно, низкая скорость каналов, большие задержки ping, есть ограничения на доступ к ресурсам и т.д.

В этой статье коротко о том, как создать подключение к VPN. А так же как настроить маршрутизацию для туннеля, созданного стандартными средствами windows (7/8/10/2012/2016), так, что бы через него шёл только тот трафик, который нам необходим.

1. Создание подключения.
1.1 Переходим в центр управления сетями и общим доступом. (нажать на значок сети правой кнопкой мыши)

1.2 Выбираем «Создание и настройка нового подключения или сети»

1.3 Выбираем «Подключение к рабочему месту»

1.4 Выбираем «Использовать мое подключение к интернету»

1.5 Указываем IP адрес или доменное имя вашего сервера. Вводим название нашего подключения

1.6 Далее (для win 8/10) нажимаем на панели задач на значок сети, выбираем подключение, нажимаем на него левой кнопкой мыши

1.7 Находим подключение с нашим названием, нажимаем левой кнопкой мыши, нажимаем кнопку подключиться.

1.8 Вводим логин и пароль.

После этого подключение должно работать.

Но что же делать, если нам надо пустить через VPN только какую-то часть трафика, например для определённых сетей?

2. Настройка маршрутизации для VPN подключения

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

2.2 Выбираем раздел «Изменение параметров адаптера»

2.3 Находим наше VPN подключение, нажимаем правой кнопкой мыши и выбираем пункт «Свойства»

2.4 Переходим на вкладку «Сеть» и нажимаем кнопку «Свойства»

2.5 Находим кнопку «Дополнительно»

2.6 На вкладке «Параметры IP» убираем галочку «Использовать основной шлюз удалённой сети»

Закрываем все окна, нажимая кнопку «ОК», пока не дойдём до окошка с вашим VPN. Как показано в пункте 1.6 подключаем соединение. Всё, теперь подключение установлено, но в удалённую сеть не будет идти никакой трафик, т.к мы отключили использование шлюза и ничего не добавили в маршрутизацию.

3. Настройка маршрутизации

3.1 Нажимаем снова на Ваше подключение правой кнопкой мыши, выбираем пункт «Подробно», если его нет, то «Состояние». Но тогда придётся сначала подключить Ваше VPN, зайти в состояние, посмотреть адрес шлюза и записать его.

3.2 В разделе «Подробно» смотрим на поле «Адрес сервера», записываем данные.

3.3 Открываем поиск, в панели задач и вводим cmd (командная строка)

3.4 Вводим команду:

route add 192.168.0.0 MASK 255.255.255.0 172.239.0.1

192.168.0.0 — адрес Вашей рабочей сети.
MASK 255.255.255.0 -маска Вашей подсети
172.239.0.1 — шлюз

После введения команды нажимаем Enter.

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

  • Главная
  • Настраиваем VPN. Часть 2 — Cтруктура сети

Настраиваем VPN. Часть 2 — Cтруктура сети

  • Автор: Уваров А.С.
  • 01.07.2019

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

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

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

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

Соединение хост-хост (Сквозной VPN, End-to-End)

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

Данное решение используется в первую очередь для создания защищенного канала связи для удаленной работы с сервисами, имеющими недостаточный уровень безопасности. Например, для организации удаленного доступа бухгалтера к базам 1С:Предприятия, либо для доступа к административной панели расположенного в сети интернет сервера.

Также подобное решение часто используют для защиты недостаточно защищенных протоколов, скажем FTP или POP3, если вариант с SSL по какой-либо причине (чаще всего обратной совместимости) недоступен.

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

Соединение хост — сеть (Удаленный доступ, End-to-Site)

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

Для того, чтобы удаленный компьютер имел доступ к локальной сети нам потребуется использовать маршрутизацию. Для этого на клиенте потребуется создать маршрут, который укажет, что все пакеты для сети 192.168.51.0 следует направлять через туннель на адрес VPN-сервера 10.10.0.1. Никаких обратных маршрутов со стороны локальной сети указывать не нужно.

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

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

Соединение сеть-сеть (Site-to-Site)

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

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

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

Как видно из следующей схемы, два филиала с сетями 192.168.41.0/24 и 192.168.31.0/24 могут общаться между собой исключительно через сервер центрального офиса. Все пакеты для иных сетей филиалы направляют на VPN-адрес офиса — 10.10.0.1, потому как если указать для 41-й сети путь к 31-й через 10.10.0.2, то такой маршрут работать не будет.

Почему? Потому что туннель — это точка-точка, в данном случае у нас есть соединения 10.10.0.2-10.10.0.1 и 10.10.0.3-10.10.0.1, но соединения 10.10.0.2 — 10.10.0.3 нет и быть не может. Понимание данного факта заставляет по-новому взглянуть на потоки трафика между удаленными сетями и предполагает построение оптимальной топологии с учетом этого факта.

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

Доступ в интернет

Если быть формалистами, то данный сценарий к виртуальной частной сети (VPN) не относится, но использование VPN-соединений для доступа в интернет становится все более и более популярным, поэтому рассмотрим и этот сценарий.

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

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

Так если вы занимаетесь работой с американскими интернет-магазинами, то вам понадобится VPN-сервер в США, чтобы вы выглядели для сайтов резидентами этой страны.

В подобных случаях нет никакой необходимости пускать в туннель весь исходящий трафик, более разумно настроить правила, когда через VPN будут работать только необходимые сайты, а весь остальной трафик пойдет через основного провайдера.

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

Читать еще:  Www disk partition com download html
Ссылка на основную публикацию
Adblock
detector
9. MauS , 03.06.2009 12:36