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

Маршрутизация внутри локальной сети на pfSense

Содержание

Маршрутизация внутри локальной сети на pfSense

В этом руководстве будет рассмотрен процесс настройки маршрутизации внутри частной сети топологии звезда. Маршрутизатором выступает виртуальный сервер под управлением операционной системы pfSense 2.3.

Что это такое?

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

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

Создание и настройка сети

Для начала в панели управления необходимо создать все необходимые для сети серверы и один из них с операционной системой pfSense.

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

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

Настройка pfSense

После успешного добавления адаптера перейдите в Web-based интерфейс pfSense.

Далее необходимо добавить LAN-интерфейс. В горизонтальном меню Interfaces->(assign) в открывшемся окне выбрать нужный интерфейс и нажать Add->Save.

После добавления интерфейса необходимо его настроить. В горизонтальном меню Interfaces->LAN. В открывшемся окне отмечаем галочкой Enable Interface и в поле IPv4 Configuration Type выбираем Static IPv4.

В поле IPv4 Address введите локальный адрес pfSense и маску. Затем нажмите Save->Apply changes.

Настройка сетевых адаптеров серверов

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

Пример настройки интерфейса на Ubuntu:

В качестве шлюза по умолчанию необходимо указать локальный IP pfSense и указать значение DNS-сервера. Настройка файла /etc/network/interfaces: auto ens33
iface ens33 inet static
address 10.0.1.3
netmask 255.255.255.0
dns-nameserver 8.8.8.8
gateway 10.0.1.4

Пример настройки интерфейса на Windows:

Перейдите в Панель управления->Сеть и интернет->Сетевые подключения. Выберете правой кнопкой мыши нужный интерфейс и откройте Свойства.

Выберете IP версии 4 (TCP/IPv4) и в открывшемся окне введите локальный адрес сервера, маску и основной шлюз.

Чтобы Ваш компьютер выходил в глобальную сеть именно через маршрутизатор, необходимо отключить адаптер, отвечающий за это, или удалить, или закомментировать соответствующие настройки в файле /etc/network/interfaces (для Linux).

Примечание: если Вы отключили адаптер и еще не настроили pfSense, то Вы не сможете подключиться к серверу по SSH/RDP, используйте web-консоль в панели управления.

Настройка маршрутизации на pfSense

Теперь необходимо настроить Port Forwarding на pfsense, чтобы можно было обращаться к серверам внутри сети за маршрутизатором. В горизонтальном меню Firewall->NAT->Port Forward. Добавить правило можно с помощью кнопки Add. На картинке ниже изображено правило для подключения к виртуальному серверу с операционной системой Ubuntu и локальным IP-адресом 10.0.1.3 к 22 порту по SSH.

Рассмотрим добавление правила для подключения к компьютеру с операционной системой Windows по RDP. После нажатия кнопки Add в открывшемся окне в поле Destination выбираем Any.

В поле Destination port range нужно выбрать порт назначения, в нашем случае это MS RDP. В поле Redirect target IP введите локальный IP-адрес ПК к которому Вы будете подключаться через этот порт. В поле Redirect target port нужно выбрать порт для перенаправления, в нашем случае это MS RDP. Далее нажмите Save->Apply changes.

Примечание: если при подключении к серверу по SSH Вы используете значение не по умолчанию, то в поле Redirect target port и Destination port range нужно выбрать Other и ввести номер порта в поле Custom.

На этом настройка маршрутизации на pfSense закончена.

Проверка и подключение

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

Например, для подключения к VPS с ОС Ubuntu и локальным IP-адресом 10.0.1.3 к 22 порту по SSH необходимо в качестве IP-адреса указать адрес маршрутизатора и порт, логин и пароль для сервера из панели управления.

Также можно проверить все открытые порты c помощью утилиты nmap: nmap -Pn

Например: nmap -Pn 188.227.16.85

При подключении к Windows-server по RDP с помощью скачанного файла, откройте его для редактирования с помощью любого текстового редактора и измените значение параметра full address:s: в первой строке на IP-адрес маршрутизатора.

RussianProxy.ru

По умолчанию, после установки RussianProxy VPN соединения ВЕСЬ трафик идёт через vpn сервер, то есть адрес нашего сервера становится основным шлюзом для всего интернет трафика. Однако, иногда возникает необходимость в других настройках vpn соединения, как то:

  • 1 вариант: после установления vpn соединения, пустить весь трафик через основного провайдера интернета, и только трафик на определённые IP адреса, например только на подсеть IP адресов игры Lineage 2, пустить напрямую, минуя впн соединение.
  • 2 вариант. после установления vpn соединения, пустить весь трафик через RussianProxy VPN соединение, и только трафик для некоторых IP адресов, пустить через vpn соединение.
  • 3 вариант. Вы хотите чтобы весь трафик шел через RussianProxy VPN соединение, даже в случае разрыва соединения или при старте операционной системы.

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

Рассмотрим пример реализации первого варианта на конкретном примере — нужно, чтобы при установленном RussianProxy VPN соединении, через него шёл трафик только для сайта http://ping.eu, весь остальной трафик бы шёл через стандартного провайдера интернет.

  • Открываем свойства соединения с RussianProxy VPN:
  • Выбираем закладку «Сеть»:
  • Открываем свойства TPC/IP протокола и нажимаем кнопку «Дополнительно»:
  • Убираем галочку с пункта «Использовать основной шлюз в удаленной сети»:
  • После этого нажимаем во всех открытых окнах свойств кнопку «OK» и подключаем vpn соединение.
  • Теперь все соединения с интернет будут идти мимо VPN. Например: зайдите на сайте www.ping.eu и Вы увидете свой IP адрес выданный Вам провайдером интернета. Для того чтобы соединение с выбранным сайтом шло через VPN, Вы должны узнать IP адрес этого сайта (например запустив команду ping site.com или на странице: http://russianproxy.ru/ping указав адрес интересующего сайта). Для сайта ping.eu: Pinging ping.eu [85.25.86.50] with 32 bytes of data: Reply from 85.25.86.50: bytes=32 time=46ms TTL=52
    После этого Вы должны узнать IP адрес выданный вам VPN сервером (можно посмотреть в сведениях о состоянии VPN соединения) или открыв наш сайт http://proxydetect.com — примерный вид: 46.183.162.###
  • Прописываем маршрут для нужного адреса 85.25.86.50:
    route add 85.25.86.50 46.183.162.### — только для IP 85.25.86.50
    route add 85.0.0.0 mask 255.0.0.0 46.183.162.### для всей подсети 85.*.*.* (если хотите чтобы трафик ко всем сайтам подсети шел через VPN)
    Вместо ### — должно стоять число из вашего IP адреса.
  • Проверяем адрес на сайте http://ping.eu — он должен быть 46.183.162.###, при использовании vpn соединения с динамическим выделенным IP, или равен выделенному Вам IP адресу , при использовании пакета с выделенным IP.

Неудобство такого способа заключается в том, что Вам придётся прописывать маршрут каждый раз после соединения с VPN. Однако, если у Вас тариф VPN с выделенным IP, Вы можете прописать постоянный маршрут один раз и больше не заботиться о его постоянном прописывании.
route add адрес_сайта ваш_постоянный_IP -p — постоянный маршрут для одного сайта
route add адрес_сайта mask маска_подсетки ваш_постоянный_IP -p — постоянный маршрут для подсети IP адресов

На пакетах с динамическим выделенным IP возможен вариант прописавыния маршрута средствами CMD:

echo ===Routing=====================================================================
for /f «tokens=2 delims=:» %%a in (‘ipconfig ^| find /i «46.183.162.»‘) do (set «IP=%%a»)
route add 91.202.44.0 mask 255.255.255.0 %IP%
route add 92.63.99.78 mask 255.255.255.255 %IP%

Строка `for /f «tokens=2 delims=:» %%a in (‘ipconfig ^| find /i «46.183.162.»‘) do (set «IP=%%a»)` поместит в переменную `%IP%` текущий IP адрес, присвоенный VPN-соединению.

Теперь рассмотрим третий вариант.
Сделаем это на конкретном примере.
Имеется компьютер подключенный к интернету через роутер 192.1.1.1. Мы хотим чтобы ни один байт не ушел в интернет напрямую через роутер, минуя наше vpn соединение. Для начала определим на какой единственный адрес может идти трафик через роутер — это адрес впн сервера:
nslookup pptp-l2tp-vpn-russia-1.atomintersoft.com -> 46.183.162.5

Рассмотрим таблицу маршрутизации —
route print:

Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.100 276 127.0.0.0 255.0.0.0 On-link
127.0.0.1 306 127.0.0.1 255.255.255.255 On-link
127.0.0.1 306 127.255.255.255 255.255.255.255 On-link
127.0.0.1 306 192.168.1.0 255.255.255.0 On-link
192.168.1.100 276 192.168.1.100 255.255.255.255 On-link
192.168.1.100 276 192.168.1.255 255.255.255.255 On-link
192.168.1.100 276 224.0.0.0 240.0.0.0 On-link
127.0.0.1 306 224.0.0.0 240.0.0.0 On-link
192.168.1.100 276 255.255.255.255 255.255.255.255 On-link
127.0.0.1 306 255.255.255.255 255.255.255.255 On-link
192.168.1.100 276 ===========================================================================

Постоянные маршруты:
Сетевой адрес Маска Адрес шлюза Метрика
0.0.0.0 0.0.0.0 192.168.1.1 По умолчанию =========================================================================== Видно, что ВЕСЬ трафик идет через постоянный маршрут по умолчанию:

0.0.0.0 0.0.0.0 192.168.1.1 По умолчанию

Удалим его: route delete 0.0.0.0

Теперь мы не можем достигнуть ни одного адреса за пределами локальной сети 192.1.1.* Далее нам нужно прописать маршрут до нашего впн сервера 46.183.162.5:

route add 46.183.162.5 192.168.1.1 -p

После этого наша таблица маршрутизации примет такой вид:

IPv4 таблица маршрута =========================================================================== Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
127.0.0.0 255.0.0.0 On-link
127.0.0.1 306 127.0.0.1 255.255.255.255 On-link
127.0.0.1 306 127.255.255.255 255.255.255.255 On-link
127.0.0.1 306 192.168.1.0 255.255.255.0 On-link
192.168.1.100 276 192.168.1.100 255.255.255.255 On-link
192.168.1.100 276 192.168.1.255 255.255.255.255 On-link
192.168.1.100 276 46.183.162.5 255.255.255.255
192.168.1.1 192.168.1.100 21 224.0.0.0 240.0.0.0 On-link
127.0.0.1 306 224.0.0.0 240.0.0.0 On-link
192.168.1.100 276 255.255.255.255 255.255.255.255 On-link
127.0.0.1 306 255.255.255.255 255.255.255.255 On-link
192.168.1.100 276 =========================================================================== Постоянные маршруты:
Сетевой адрес Маска Адрес шлюза Метрика
46.183.162.5 255.255.255.255 192.168.1.1 1 ===========================================================================

То есть доступен только один адрес в интернете — 46.183.162.5 — а это и есть адрес нашего впн сервера.
Не забудьте в настройках впн соединения вписать именно IP адрес 46.183.162.5, а не доменное имя pptp-l2tp-vpn-russia-1.atomintersoft.com. Теперь запускаем наше RussianProxy VPN соединение и весь интернет трафик, за исключением трафика до нашего впн сервера, пойдет через шифрованное со сжатием впн соединение. Итоговая таблица маршрутизации при установленном впн соединении выглядит в нашем случае так:

IPv4 таблица маршрута =========================================================================== Активные маршруты: Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика

0.0.0.0 0.0.0.0 On-link 46.183.162.31 21 127.0.0.0 255.0.0.0 On-link
127.0.0.1 4531 127.0.0.1 255.255.255.255 On-link
127.0.0.1 4531 127.255.255.255 255.255.255.255 On-link
127.0.0.1 4531 192.168.1.0 255.255.255.0 On-link
192.168.1.100 4501 192.168.1.100 255.255.255.255 On-link
192.168.1.100 4501 192.168.1.255 255.255.255.255 On-link
192.168.1.100 4501 46.183.162.31 255.255.255.255 On-link
46.183.162.31 276 46.183.162.5 255.255.255.255
192.168.1.1 192.168.1.100 4246 224.0.0.0 240.0.0.0 On-link
127.0.0.1 4531 224.0.0.0 240.0.0.0 On-link
192.168.1.100 4502 224.0.0.0 240.0.0.0 On-link
46.183.162.31 21 255.255.255.255 255.255.255.255 On-link
127.0.0.1 4531 255.255.255.255 255.255.255.255 On-link
192.168.1.100 4501 255.255.255.255 255.255.255.255 On-link
46.183.162.31 276 =========================================================================== Постоянные маршруты:

Трассировка маршрута к ya.ru [213.180.204.8] с максимальным числом прыжков 30:
1 16 ms 16 ms 17 ms AIS [46.183.162.1]
2 20 ms 21 ms 20 ms v1505.th-1.caravan.ru [212.158.160.2]
3 16 ms 17 ms 16 ms v811.m9-3.caravan.ru [212.24.42.49]
4 20 ms 25 ms 21 ms ix2-m9.yandex.net [193.232.244.93]
5 23 ms 20 ms 18 ms ya.ru [213.180.204.8] Трассировка завершена. ===============================================================

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

MikroTik L2TP/IPsec сервер не отправляет маршрут клиенту

После двух дней мучений, готов признать что хвалёный MikroTik не справился с простой задачей, которая на Keenetic Ultra II решается в пару кликов. Возможно, это вовсе не связано с недоработками в RouterOS, а у меня просто не хватило терпения или знании, чтобы заставить L2TP/IPsec на «микротике» добавлять маршрут клиенту при соединении.

Полазив по тематическим форумам и wiki, посвященных настройке оборудования MikroTik, найти решения так и не удалось. Собственно, в чём суть проблемы? При подключении к L2TP/IPsec серверу, клиент не видит компьютеры локальной сети за ним, впрочем как и самого роутера. Пинги дальше виртуальной сети не проходят.

Решение 1: Отправлять весь трафик клиента через VPN

Если в настройке соединения на клиенте указать что следует «Отправлять весь трафик через VPN», локальная сеть за роутером прекрасно видится. Но в этом случае мы гоним весь собственный трафик, вместе торрентами и прочим барахлом через удалённый офис, где запущен L2TP/IPsec сервер. Зачем это всё, если нам требуется просто получить доступ к терминальному серверу в удалённой сети?

Windows 10 по умолчанию заворачивает весь трафик в VPN канал при создании подключения. Проверить это можно открыв свойства протокола IP версии 4 (TCP/IPv4) и в дополнительных параметрах TCP/IP будет активирован пункт «Использовать основной шлюз удаленной сети».

Решение 2: Прописать дополнительный статический маршрут на клиенте

Странно, но по всей видимости, MikroTik не умеет самостоятельно отправлять дополнительный маршрут клиенту при подключении к L2TP/IPsec серверу. Замечу, что Keenetic Ultra II прекрасно справляется с аналогичной задачей и поднять на нём L2TP/IPsec сервер может обычный пользователь. Лишний раз убеждаюсь, что «микроты» придуманы, чтобы наполнять жизнь упоротых любителей копания в настройках смыслом.

Раз не получилось сотворить задуманное в настройках L2TP сервера, придётся добавить требуемый маршрут к удалённой сети на клиенте ручками. Для примера, пусть локальная сеть за MikroTik будет 192.168.88.0/24 и local-address L2TP/IPsec сервера 10.8.0.10:

sudo route -n add 192.168.88.0/24 10.8.0.10

Как ни крути, но такое решение тоже «костыль». И как бы не утверждали на одном из форумов по настройке «микротов», что заворачивать весь клиентский трафик в VPN канал благо, я с этим не согласен. Потому буду рад, если кто напишет как заставить MikroTik самостоятельно назначать маршруты клиентам вместе с выдачей IP.

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

Комментариев: 29

  1. 2019-08-07 в 11:02:05 | Сергей Мусалимов

А не проще взять Д-линк или другой нормальный роутер ?

Сергей, не подскажете что подразумевается под «нормальными» роутерами? На Keenetic данная конкретная задача решается проще, но микротик, как ни крути, более функционален.

Я не надеялась, но обновление решило проблему. Спасибо огромное

длинк давно перестал быть нормальным.

Была задачи в филиальной сети заменить роутеры на DD-WRT в которых уже использовался OpenVPN. Приобрели хваленый микротик, т.к. в нем заявлена поддержка OpenVPN. И что же оказалось — она есть, но куцая и нам не подошла, т.к нам бы пришлось все переделывать. Взяли Zyxel Keenetic, а вот там поддержка OpenVPN оказалась той что нужно. На них и остановились. Keenetic’и замечательно справляются со свое задачей не только с OpenVPN, но и без особых заморочек строить туннели Ipsec.

правила надо было прописавать и masquerade настроеть под vpn. и все на тиках ходит.

Павел, не подскажите какие именно правила отправляют маршрут клиенту? и как на это влияет masquerade?

вот правила для фаервола

пускаем IP нашего VPN-пула в локалку:

По-умолчанию masquerade настроен для физического WAN-интерфейса(sfp1/ether1 и тд) , а нам надо запустить все через L2TP

Делаем следующее правило:

Еще есть ньюанс, что локальные интерфейсы в бридже надо перевести в proxy-arp

Павел, а вы сами пробовали так делать? Как это влияет на отправку маршрута клиенту?

Совершенно дилетантский подход к настройке железа. Ды, сударь, с кошками или джунами работали? Прежде чем написать статью — загуглите что и как настраивается, дело двух строк (и вам уже подсказали их) . А то круто получается: графоманством пострадать — норм, время есть, а в гугле настройку канала найти — «ай-яй-яй, микрот гавно»

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

dre@mer, а на хрена? Статью написать, хайпануть, получить бабло за просмотр — это мы запросто, а изучить матчасть по настройке железа — «нафиг надо, хомячки схавают». Тем более, что вам уже подсказали как это сделать.

Роман, отвечу в вашем стиле: «Все пи##Rасы, один я Дартаньян. » Ну а по сути, вы сами пробовали то что написано? Почитайте внимательно о чём статья. Проблема в том, что «микрот» не умеет отправлять маршрут клиенту при L2TP/IPsec, как Keenetik. Поэтому и приходится заворачивать весь пользовательский трафик в канал.

И насчёт хайпа. вы реально считаете данную тему хайповой и что на ней можно заработать? Да она интересна только узким специалистам.

если бы я не обслуживал парк порядка 30 микротов в 8 офисах, двух датацентрах (site-to-site ipsec, обычные l2tp каналы (с шифрование и без) , включая l2tp дублирующие, с распределенной маршрутизацией) — я бы молчал. Суть моего негодования сводится к тому, что не разобравшись с матчастью клепается чудо-статейка о том, какое говно этот микрот, и ничего он не умеет *рукалицо*.

И, да, у меня все прекрасно работает, только дело в том, что микрот отправляет клиенту дефолт (если в курсе что это) , а сам трафик рулится маршрутам уже на микроте, и там его можно завернуть в любую дырку, но важно ещё понимать принцип работы firewall. А сравнивать его с длинком или зухелем, млять, это как сравнить инвалидку и болид формулы-1: и то и то машина, но какая разница между ними.

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

Роман, я очень рад что вы освоили дефолтные маршруты, только статья не об этом

Сколько баталий, интриг и войн. Предложение с firewall и nat это лишние костыли, все гораздо проще решается. Микротик умеет выполнять данное требование, желательно пройти курс MTCNA, после которого все вопросы данного рода отпадут. PPP — Secrets, когда создаете запись, в этой записи есть такая настройка, как Routes, именно здесь и указывается необходимая Вам сеть, куда надо попасть. Эта сеть добавляется в таблицу маршрутизации микротика и после и все запросы к этой сети, будут отправляться через local ip l2tp микротика. Easy win

Вы путаете, я знаю про поле Routes и в нём прописывается сеть клиента, который подключается к L2TP серверу, а вот отправлять маршрут клиенту, Mikrotik пока не умеет. Не верите мне, почитайте форумы или задайте вопрос преподавателям курсов. Возможно это будет решено в 7-ой версии прошивки.

Вы неправильно понимаете работу поле Routes. Оно прописывает дополнительный маршрут, куда должны попадать пакеты через vpn туннель. Маршрут на клиенте не будет появляться, но когда вы сделаете запрос к этой сети, пакет отправиться на шлюз local ip l2tp микротика, а там уже будет динамическая запись к вашей сети, куда надо попасть. Я эту схему реализовал, это работает. А вы вместо того, чтоб спорить, возьмите и проделайте. Если в боевую сеть страшно запускать, тогда соберите стенд с одним микротиком и проверьте.

Более детально распишу. К примеру, у нас есть локальная сеть 192.168.1.0/24

подключенная к ether2 микротика. Так же есть сеть 192.168.2.0/24, подключенная в другой порт, порты между собой независимы. Для сети 192.168.1.0/24 на микротике Вы создаете туннель, допустим, loсal ip 10.0.0.1 and remote ip 10.0.0.2. Так вот, чтобы из сети 192.168.1.0/24 попасть в сеть 192.168.2.0/24, мы прописываем в это поле Routes 192.168.2.0/24. После того, как клиент подключиться по впн, в таблице маршрутизации появится динамическая запись о сети 192.168.2.0/24 через созданный туннель. А маршрутизатор в свою очередь знает о сети 192.168.2.0/24 и как туда добраться. Соответственно компы из сети 192.168.1.0/24 смогут увидеть сетку 192.168.2.0/24

Маршрут на клиенте не будет появляться, но когда вы сделаете запрос к этой сети, пакет отправиться на шлюз local ip l2tp микротика

Каким образом клиентская машина поймёт, что пакеты для другой, неизвестной ей сети, следует отправлять именно в VPN-канал, если такого маршрута у клиента нет? Ещё раз обращаю внимание, что он НЕ ЯВЛЯЕТСЯ ШЛЮЗОМ ПО УМОЛЧАНИЮ!

И уж поверьте, я не раз проверил что там передаётся, а что нет.

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

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

. машина видит, что такой сети она не знает, поэтому отправляет на шлюз l2tp local ip микротика.

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

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

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

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

Все выше сказанные посты имеют свою правду. Дело в том, что я столкнулся с приблизительно такой же проблемой. При создании VPN L2TP Server Mikrotik с использованием IpSec и VPN клиенте Windows без использования основного шлюза в удаленной сети, локальная сеть за сервером L2TP недоступна через сеть сделанную для VPN соединения. Добавление постоянных маршрутов на клиенте решало эту проблему, но при разрыве VPN соединения и при установке нового соединения сеть была не доступной. Решение оказалось простым. Необходимо сделать маршрут в созданном VPN в локальную сеть за микротиком. Что для этого необходимо:

1. Для каждого пользователя VPN назначить ip address клиента и сервера, т.е. в PPP Secret указать в поле Local Address -это адрес сервера при создании тунеля из пула адресов созданных для данного VPN, в поле Remote Address — это адрес клиента. При установке VPN пользователи будут получать именно те адреса которые вы укажите.

2. В поле Routes указать сеть куда необходимо маршрутизировать трафик (локальная сеть за микротиком).

3. Прописать постоянный маршрут на Windows VPN-клиенте через адрес полученный при установке VPN.

Люди добрые, почитал эту ветку и ужаснулся.

А для чего на микроте протоколы динамической маршрутизации RIP, OSPF?

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

Кому интересно, пишите.

Расскажите как это настраивается в данном случае?

Включите прослушиватель RIP на винде.

Создайте server binding для vpn клиента.

Запустите протокол RIP на роутере Routing-Rip-Interfaces — добавьте интерфейс vpn клиента, далее в Networks пропишите ip адрес туннеля vpn клиента и там же анонсируйте маршрут (подсеть), который хотите передать. Вот и всё.

Доброго времени суток! Комментатор 184, а как быть mac os и ios

Развертывание сети VPN

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

Казалось бы, проще всего включить шифратор в «разрыв» локальной сети, т. е. установить его между коммутатором и маршрутизатором. Но одним из условий развертывания VPN было обеспечение бесперебойного функционирования сети в целом, независимо от того, включено шифрование или нет. Подключение шифратора вело к появлению узкого места в любом случае, однако при его установке на «горло» сети бесперебойность работы подвергалась серьезной опасности, так как, выйди шифратор из строя, данный офис потеряет связь с остальными. Для центрального офиса кратковременная потеря связи с удаленными площадками — небольшая трагедия, а вот последние удаленно работали с серверами, физически расположенными в центральном офисе компании, так что простои вследствие неполадок в работе шифрующего оборудования были недопустимы. Таким образом, функционирование локальной сети в целом должно было быть обеспечено независимо от работы шифраторов.

Схема сети

Все рабочие станции центрального офиса и часть серверов подключались к одному коммутатору. Прочее серверное оборудование центрального офиса работало через другой коммутатор и относилось к демилитаризованной зоне. Оба коммутатора соединялись с маршрутизатором Cisco, который и связывал локальные сети центрального и удаленных офисов в единую корпоративную сеть. Топология удаленной локальной сети выглядела еще проще: коммутатор для подключения серверного оборудования отсутствовал, поэтому не было и демилитаризованной зоны, а единственный коммутатор присоединялся напрямую к маршрутизатору Cisco; тот, в свою очередь, связывался с маршрутизаторами центрального и удаленных офисов. Их взаимодействие осуществлялось по протоколу динамической маршрутизации EIGRP.

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

Одному из интерфейсов шифратора был назначен IP-адрес той локальной сети, где он был установлен. Второму — IP-адрес виртуальной сети класса C. Для простоты первый интерфейс назовем «внутренним», а второй — «внешним». Открытый трафик поступал на внутренний интерфейс, а с внешнего отправлялся уже зашифрованный трафик, причем он был инкапсулирован таким образом, что IP-адресом отправителя пакета являлся IP-адрес внешнего интерфейса шифратора, а IP-адресом получателя — IP-адрес внешнего интерфейса шифратора того офиса компании, для которого предназначался изначальный открытый пакет. Сам шифратор не занимался никаким анализом проходящего через него трафика, т. е. был, как уже говорилось, сквозным.

Организация шифруемого соединения

Для пояснения схемы мы рассмотрим пример работы по защищенному соединению между центральным офисом и одной из удаленных площадок. Трафик из локальной сети центрального офиса через коммутатор поступал на маршрутизатор Cisco. На маршрутизаторе были заданы правила условной маршрутизации (policy routing), согласно которым трафик, предназначавшийся для удаленного офиса компании, направлялся не в среду ATM, а на внутренний интерфейс установленного в локальной сети шифратора. Наглядно схема включения шифратора в сеть представлена на Рисунке 1. Маршрутизировать трафик — дело маршрутизатора, так что возлагать функции анализа трафика на шифрующие устройства не стоит. Шифратор «знал» только ключи шифрования для конкретных адресов получателей.

С внешнего интерфейса шифратора инкапсулированный защищенный трафик направлялся опять-таки на маршрутизатор, на интерфейсе Ethernet которого было задано два IP-адреса: один — соответствовал локальной сети центрального офиса; другой — принадлежал виртуальной сети шифратора и служил для него шлюзом по умолчанию. Далее зашифрованный пакет снова сверялся со списками доступа маршрутизатора, где описываются правила динамической маршрутизации EIGRP, и, согласно им, направлялся в то или иное подразделение компании. Маршрутизатор удаленного офиса имел схожую конфигурацию, но не хранил сложные списки доступа c описанием маршрутизации EIGRP, а все пакеты, в том числе предназначавшиеся для других удаленных площадок, пересылались в центральную сеть. На интерфейсе Ethernet маршрутизатора удаленного офиса также было задано два IP-адреса: один принадлежал локальной сети филиала, а второй — виртуальной сети установленного там шифратора и являлся для шифратора шлюзом по умолчанию.

Внешнему интерфейсу шифратора центрального офиса был назначен IP-адрес 192.168.0.2, внутреннему — 10.0.0.253. Все машины в локальной сети имели адрес из сети 10.0.0.0/24. Для интерфейса Ethernet на маршрутизаторе центрального офиса были определены адреса 10.0.0.1 и 192.168.0.1. На шифраторе в качестве шлюза по умолчанию был задан адрес 192.168.0.1. На всех рабочих станциях центрального офиса в качестве адреса шлюза по умолчанию был указан адрес 10.0.0.1.

Внешнему интерфейсу маршрутизатора удаленного офиса соответствовал IP-адрес 192.168.1.2, а внутреннему — 10.0.1.253; все машины локальной сети удаленного офиса имели адреса из сети 10.0.1.0/24. Интерфейсу Ethernet на маршрутизаторе были назначены адреса 10.0.1.1 и 192.168.1.1. На шифраторе в качестве шлюза по умолчанию был указан адрес 192.168.1.1. На всех рабочих станциях локальной сети удаленного офиса в качестве шлюза по умолчанию был задан адрес 10.0.1.1. В скобках отметим, что приведенные адреса не существуют реально и используются только для иллюстрации схемы.

Предположим, клиент из удаленной сети хочет установить защищенное соединение с сервером из центрального офиса по протоколу telnet. Его рабочая станция имеет IP-адрес 10.0.1.22, а сервер центрального офиса — 10.0.0.44. Таким образом, трафик от удаленного клиента имеет адрес отправителя 10.0.1.22 и адрес получателя 10.0.0.44, порт 23 (telnet). Поскольку шлюзу по умолчанию в удаленном офисе присвоен адрес 10.0.1.1, то все пакеты поступают на маршрутизатор Cisco. На маршрутизаторе настроены списки доступа, где описываются правила условной маршрутизации: в частности, пакеты, предназначающиеся сервису telnet (TCP-порт 23), должны маршрутизироваться не напрямую в центральный офис, а на внутренний интерфейс шифратора.

Пакет от маршрутизатора попадает на указанный интерфейс, затем производится шифрование и инкапсуляция пакета. В результате с внешнего интерфейса шифратора удаленного офиса отсылается пакет с адресом отправителя 192.168.1.2 (внешний интерфейс шифратора удаленного офиса), адресом получателя 192.168.0.2 (внешний интерфейс шифратора центрального офиса), TCP-портом получателя 23. Пакет следует на интерфейс Ethernet маршрутизатора удаленного офиса, где, в соответствии с правилами маршрутизации для сети 192.168.0.0/24, направляется в центральный офис, на маршрутизаторе которого настроен список доступа — согласно ему, пакет с адресом получателя из сети 192.168.0.0/24 передается на внешний интерфейс шифратора (192.168.0.1). Далее он декапсулируется, расшифровывается и с внутреннего интерфейса шифратора центрального офиса попадает в сеть с адресом отправителя 10.0.1.22, адресом получателя 10.0.0.44 и портом получателя 23 (telnet), т. е. с исходными данными. После поступления на маршрутизатор пакет передается далее в соответствии с обычными правилами маршрутизации в локальной сети. В обратном направлении диалог сервера 10.0.0.44 с клиентом 10.0.1.22 происходит в соответствии с аналогичной процедурой, за исключением того, что списки доступа условной маршрутизации создаются на основании TCP-порта отправителя, а не получателя.

Плюсы и минусы

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

У данного подхода есть еще одно неоспоримое преимущество — это бо’льшая устойчивость сети в целом по сравнению с подключением шифратора на «горло» локальной сети. В частности, протоколы динамической маршрутизации позволяют определить доступность интерфейсов шифратора и автоматически перестроить таблицу маршрутизации в случае выхода из строя одного из интерфейсов либо шифратора в целом. Никакой инкапсуляции проводиться не будет, так что офисы компании станут доступны друг другу по сети. Но подобное решение имеет одну очень неприятную особенность: если администратор не узнает об изменении таблиц маршрутизации, то передаваемый в открытом виде трафик может оказаться скомпрометированным. На такой случай нужно предусмотреть схему оповещения администратора.

Может показаться, что при статической маршрутизации схема параллельного включения шифратора в сеть ничем не отличается от схемы его подключения на «горло» сети, так как связь все равно пропадет, но это не так. Откат конфигурации маршрутизатора (хотя бы даже удаленно) осуществить гораздо проще, чем физически перекоммутировать оборудование на непосредственную маршрутизацию. У такого подхода есть свои плюсы — о защите трафика несложно позаботиться еще до того, как он попадет в среду передачи данных, где может произойти его компрометация.

Мы намеренно не использовали встроенные возможности маршрутизатора Cisco по созданию VPN, так как уверены в следующем:

    маршрутизатор должен заниматься только маршрутизацией, а шифрованием — отдельное устройство;

    налицо значительная разница в стоимости IOS с поддержкой шифрования и IOS без таковой; кроме того, нельзя не учитывать существующие экспортные/импортные ограничения на криптографическое оборудование и алгоритмы;

    алгоритм шифрования DES, характерный для Cisco IOS, не считается устойчивым, и его применение не рекомендуется;

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

    Условная маршрутизация

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

    В настройках Cisco рекомендуется отключить IP Redirect на интерфейсах Ethernet посредством команды no ip redirects в конфигурации интерфейса Ethernet, поскольку при создании условного маршрута маршрутизатор с настройками по умолчанию рассылает широковещательное ICMP-сообщение Network Redirect. при его получении машины из подсети меняют статический маршрут для сети, для которой задан условный маршрут Cisco, со шлюза по умолчанию на криптошлюз. Естественно, в ситуации, когда необходимо восстановить изначальную конфигурацию сети (без криптошлюзов), откат не ограничивается восстановлением конфигурации Cisco — помимо этого, изменение маршрутов необходимо произвести вручную на рабочих станциях и серверах защищенной сети.

    Доверяй, но проверяй

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

    Об авторе: Павел Покровский — специалист по информационной безопасности.

    • Автор: Уваров А.С.
    • 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.

    RussianProxy.ru

    По умолчанию, после установки RussianProxy VPN соединения ВЕСЬ трафик идёт через vpn сервер, то есть адрес нашего сервера становится основным шлюзом для всего интернет трафика. Однако, иногда возникает необходимость в других настройках vpn соединения, как то:

    • 1 вариант: после установления vpn соединения, пустить весь трафик через основного провайдера интернета, и только трафик на определённые IP адреса, например только на подсеть IP адресов игры Lineage 2, пустить напрямую, минуя впн соединение.
    • 2 вариант. после установления vpn соединения, пустить весь трафик через RussianProxy VPN соединение, и только трафик для некоторых IP адресов, пустить через vpn соединение.
    • 3 вариант. Вы хотите чтобы весь трафик шел через RussianProxy VPN соединение, даже в случае разрыва соединения или при старте операционной системы.

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

    Рассмотрим пример реализации первого варианта на конкретном примере — нужно, чтобы при установленном RussianProxy VPN соединении, через него шёл трафик только для сайта http://ping.eu, весь остальной трафик бы шёл через стандартного провайдера интернет.

    • Открываем свойства соединения с RussianProxy VPN:
    • Выбираем закладку «Сеть»:
    • Открываем свойства TPC/IP протокола и нажимаем кнопку «Дополнительно»:
    • Убираем галочку с пункта «Использовать основной шлюз в удаленной сети»:
    • После этого нажимаем во всех открытых окнах свойств кнопку «OK» и подключаем vpn соединение.
    • Теперь все соединения с интернет будут идти мимо VPN. Например: зайдите на сайте www.ping.eu и Вы увидете свой IP адрес выданный Вам провайдером интернета. Для того чтобы соединение с выбранным сайтом шло через VPN, Вы должны узнать IP адрес этого сайта (например запустив команду ping site.com или на странице: http://russianproxy.ru/ping указав адрес интересующего сайта). Для сайта ping.eu: Pinging ping.eu [85.25.86.50] with 32 bytes of data: Reply from 85.25.86.50: bytes=32 time=46ms TTL=52
      После этого Вы должны узнать IP адрес выданный вам VPN сервером (можно посмотреть в сведениях о состоянии VPN соединения) или открыв наш сайт http://proxydetect.com — примерный вид: 46.183.162.###
    • Прописываем маршрут для нужного адреса 85.25.86.50:
      route add 85.25.86.50 46.183.162.### — только для IP 85.25.86.50
      route add 85.0.0.0 mask 255.0.0.0 46.183.162.### для всей подсети 85.*.*.* (если хотите чтобы трафик ко всем сайтам подсети шел через VPN)
      Вместо ### — должно стоять число из вашего IP адреса.
    • Проверяем адрес на сайте http://ping.eu — он должен быть 46.183.162.###, при использовании vpn соединения с динамическим выделенным IP, или равен выделенному Вам IP адресу , при использовании пакета с выделенным IP.

    Неудобство такого способа заключается в том, что Вам придётся прописывать маршрут каждый раз после соединения с VPN. Однако, если у Вас тариф VPN с выделенным IP, Вы можете прописать постоянный маршрут один раз и больше не заботиться о его постоянном прописывании.
    route add адрес_сайта ваш_постоянный_IP -p — постоянный маршрут для одного сайта
    route add адрес_сайта mask маска_подсетки ваш_постоянный_IP -p — постоянный маршрут для подсети IP адресов

    На пакетах с динамическим выделенным IP возможен вариант прописавыния маршрута средствами CMD:

    echo ===Routing=====================================================================
    for /f «tokens=2 delims=:» %%a in (‘ipconfig ^| find /i «46.183.162.»‘) do (set «IP=%%a»)
    route add 91.202.44.0 mask 255.255.255.0 %IP%
    route add 92.63.99.78 mask 255.255.255.255 %IP%

    Строка `for /f «tokens=2 delims=:» %%a in (‘ipconfig ^| find /i «46.183.162.»‘) do (set «IP=%%a»)` поместит в переменную `%IP%` текущий IP адрес, присвоенный VPN-соединению.

    Теперь рассмотрим третий вариант.
    Сделаем это на конкретном примере.
    Имеется компьютер подключенный к интернету через роутер 192.1.1.1. Мы хотим чтобы ни один байт не ушел в интернет напрямую через роутер, минуя наше vpn соединение. Для начала определим на какой единственный адрес может идти трафик через роутер — это адрес впн сервера:
    nslookup pptp-l2tp-vpn-russia-1.atomintersoft.com -> 46.183.162.5

    Рассмотрим таблицу маршрутизации —
    route print:

    Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
    0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.100 276 127.0.0.0 255.0.0.0 On-link
    127.0.0.1 306 127.0.0.1 255.255.255.255 On-link
    127.0.0.1 306 127.255.255.255 255.255.255.255 On-link
    127.0.0.1 306 192.168.1.0 255.255.255.0 On-link
    192.168.1.100 276 192.168.1.100 255.255.255.255 On-link
    192.168.1.100 276 192.168.1.255 255.255.255.255 On-link
    192.168.1.100 276 224.0.0.0 240.0.0.0 On-link
    127.0.0.1 306 224.0.0.0 240.0.0.0 On-link
    192.168.1.100 276 255.255.255.255 255.255.255.255 On-link
    127.0.0.1 306 255.255.255.255 255.255.255.255 On-link
    192.168.1.100 276 ===========================================================================

    Постоянные маршруты:
    Сетевой адрес Маска Адрес шлюза Метрика
    0.0.0.0 0.0.0.0 192.168.1.1 По умолчанию =========================================================================== Видно, что ВЕСЬ трафик идет через постоянный маршрут по умолчанию:

    0.0.0.0 0.0.0.0 192.168.1.1 По умолчанию

    Удалим его: route delete 0.0.0.0

    Теперь мы не можем достигнуть ни одного адреса за пределами локальной сети 192.1.1.* Далее нам нужно прописать маршрут до нашего впн сервера 46.183.162.5:

    route add 46.183.162.5 192.168.1.1 -p

    После этого наша таблица маршрутизации примет такой вид:

    IPv4 таблица маршрута =========================================================================== Активные маршруты:
    Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
    127.0.0.0 255.0.0.0 On-link
    127.0.0.1 306 127.0.0.1 255.255.255.255 On-link
    127.0.0.1 306 127.255.255.255 255.255.255.255 On-link
    127.0.0.1 306 192.168.1.0 255.255.255.0 On-link
    192.168.1.100 276 192.168.1.100 255.255.255.255 On-link
    192.168.1.100 276 192.168.1.255 255.255.255.255 On-link
    192.168.1.100 276 46.183.162.5 255.255.255.255
    192.168.1.1 192.168.1.100 21 224.0.0.0 240.0.0.0 On-link
    127.0.0.1 306 224.0.0.0 240.0.0.0 On-link
    192.168.1.100 276 255.255.255.255 255.255.255.255 On-link
    127.0.0.1 306 255.255.255.255 255.255.255.255 On-link
    192.168.1.100 276 =========================================================================== Постоянные маршруты:
    Сетевой адрес Маска Адрес шлюза Метрика
    46.183.162.5 255.255.255.255 192.168.1.1 1 ===========================================================================

    То есть доступен только один адрес в интернете — 46.183.162.5 — а это и есть адрес нашего впн сервера.
    Не забудьте в настройках впн соединения вписать именно IP адрес 46.183.162.5, а не доменное имя pptp-l2tp-vpn-russia-1.atomintersoft.com. Теперь запускаем наше RussianProxy VPN соединение и весь интернет трафик, за исключением трафика до нашего впн сервера, пойдет через шифрованное со сжатием впн соединение. Итоговая таблица маршрутизации при установленном впн соединении выглядит в нашем случае так:

    IPv4 таблица маршрута =========================================================================== Активные маршруты: Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика

    0.0.0.0 0.0.0.0 On-link 46.183.162.31 21 127.0.0.0 255.0.0.0 On-link
    127.0.0.1 4531 127.0.0.1 255.255.255.255 On-link
    127.0.0.1 4531 127.255.255.255 255.255.255.255 On-link
    127.0.0.1 4531 192.168.1.0 255.255.255.0 On-link
    192.168.1.100 4501 192.168.1.100 255.255.255.255 On-link
    192.168.1.100 4501 192.168.1.255 255.255.255.255 On-link
    192.168.1.100 4501 46.183.162.31 255.255.255.255 On-link
    46.183.162.31 276 46.183.162.5 255.255.255.255
    192.168.1.1 192.168.1.100 4246 224.0.0.0 240.0.0.0 On-link
    127.0.0.1 4531 224.0.0.0 240.0.0.0 On-link
    192.168.1.100 4502 224.0.0.0 240.0.0.0 On-link
    46.183.162.31 21 255.255.255.255 255.255.255.255 On-link
    127.0.0.1 4531 255.255.255.255 255.255.255.255 On-link
    192.168.1.100 4501 255.255.255.255 255.255.255.255 On-link
    46.183.162.31 276 =========================================================================== Постоянные маршруты:

    Трассировка маршрута к ya.ru [213.180.204.8] с максимальным числом прыжков 30:
    1 16 ms 16 ms 17 ms AIS [46.183.162.1]
    2 20 ms 21 ms 20 ms v1505.th-1.caravan.ru [212.158.160.2]
    3 16 ms 17 ms 16 ms v811.m9-3.caravan.ru [212.24.42.49]
    4 20 ms 25 ms 21 ms ix2-m9.yandex.net [193.232.244.93]
    5 23 ms 20 ms 18 ms ya.ru [213.180.204.8] Трассировка завершена. ===============================================================

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

    Маршрутизация внутри локальной сети на pfSense

    В этом руководстве будет рассмотрен процесс настройки маршрутизации внутри частной сети топологии звезда. Маршрутизатором выступает виртуальный сервер под управлением операционной системы pfSense 2.3.

    Что это такое?

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

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

    Создание и настройка сети

    Для начала в панели управления необходимо создать все необходимые для сети серверы и один из них с операционной системой pfSense.

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

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

    Настройка pfSense

    После успешного добавления адаптера перейдите в Web-based интерфейс pfSense.

    Далее необходимо добавить LAN-интерфейс. В горизонтальном меню Interfaces->(assign) в открывшемся окне выбрать нужный интерфейс и нажать Add->Save.

    После добавления интерфейса необходимо его настроить. В горизонтальном меню Interfaces->LAN. В открывшемся окне отмечаем галочкой Enable Interface и в поле IPv4 Configuration Type выбираем Static IPv4.

    В поле IPv4 Address введите локальный адрес pfSense и маску. Затем нажмите Save->Apply changes.

    Настройка сетевых адаптеров серверов

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

    Пример настройки интерфейса на Ubuntu:

    В качестве шлюза по умолчанию необходимо указать локальный IP pfSense и указать значение DNS-сервера. Настройка файла /etc/network/interfaces: auto ens33
    iface ens33 inet static
    address 10.0.1.3
    netmask 255.255.255.0
    dns-nameserver 8.8.8.8
    gateway 10.0.1.4

    Пример настройки интерфейса на Windows:

    Перейдите в Панель управления->Сеть и интернет->Сетевые подключения. Выберете правой кнопкой мыши нужный интерфейс и откройте Свойства.

    Выберете IP версии 4 (TCP/IPv4) и в открывшемся окне введите локальный адрес сервера, маску и основной шлюз.

    Чтобы Ваш компьютер выходил в глобальную сеть именно через маршрутизатор, необходимо отключить адаптер, отвечающий за это, или удалить, или закомментировать соответствующие настройки в файле /etc/network/interfaces (для Linux).

    Примечание: если Вы отключили адаптер и еще не настроили pfSense, то Вы не сможете подключиться к серверу по SSH/RDP, используйте web-консоль в панели управления.

    Настройка маршрутизации на pfSense

    Теперь необходимо настроить Port Forwarding на pfsense, чтобы можно было обращаться к серверам внутри сети за маршрутизатором. В горизонтальном меню Firewall->NAT->Port Forward. Добавить правило можно с помощью кнопки Add. На картинке ниже изображено правило для подключения к виртуальному серверу с операционной системой Ubuntu и локальным IP-адресом 10.0.1.3 к 22 порту по SSH.

    Рассмотрим добавление правила для подключения к компьютеру с операционной системой Windows по RDP. После нажатия кнопки Add в открывшемся окне в поле Destination выбираем Any.

    В поле Destination port range нужно выбрать порт назначения, в нашем случае это MS RDP. В поле Redirect target IP введите локальный IP-адрес ПК к которому Вы будете подключаться через этот порт. В поле Redirect target port нужно выбрать порт для перенаправления, в нашем случае это MS RDP. Далее нажмите Save->Apply changes.

    Примечание: если при подключении к серверу по SSH Вы используете значение не по умолчанию, то в поле Redirect target port и Destination port range нужно выбрать Other и ввести номер порта в поле Custom.

    На этом настройка маршрутизации на pfSense закончена.

    Проверка и подключение

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

    Например, для подключения к VPS с ОС Ubuntu и локальным IP-адресом 10.0.1.3 к 22 порту по SSH необходимо в качестве IP-адреса указать адрес маршрутизатора и порт, логин и пароль для сервера из панели управления.

    Также можно проверить все открытые порты c помощью утилиты nmap: nmap -Pn

    Например: nmap -Pn 188.227.16.85

    При подключении к Windows-server по RDP с помощью скачанного файла, откройте его для редактирования с помощью любого текстового редактора и измените значение параметра full address:s: в первой строке на IP-адрес маршрутизатора.

    Развертывание сети VPN

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

    Казалось бы, проще всего включить шифратор в «разрыв» локальной сети, т. е. установить его между коммутатором и маршрутизатором. Но одним из условий развертывания VPN было обеспечение бесперебойного функционирования сети в целом, независимо от того, включено шифрование или нет. Подключение шифратора вело к появлению узкого места в любом случае, однако при его установке на «горло» сети бесперебойность работы подвергалась серьезной опасности, так как, выйди шифратор из строя, данный офис потеряет связь с остальными. Для центрального офиса кратковременная потеря связи с удаленными площадками — небольшая трагедия, а вот последние удаленно работали с серверами, физически расположенными в центральном офисе компании, так что простои вследствие неполадок в работе шифрующего оборудования были недопустимы. Таким образом, функционирование локальной сети в целом должно было быть обеспечено независимо от работы шифраторов.

    Схема сети

    Все рабочие станции центрального офиса и часть серверов подключались к одному коммутатору. Прочее серверное оборудование центрального офиса работало через другой коммутатор и относилось к демилитаризованной зоне. Оба коммутатора соединялись с маршрутизатором Cisco, который и связывал локальные сети центрального и удаленных офисов в единую корпоративную сеть. Топология удаленной локальной сети выглядела еще проще: коммутатор для подключения серверного оборудования отсутствовал, поэтому не было и демилитаризованной зоны, а единственный коммутатор присоединялся напрямую к маршрутизатору Cisco; тот, в свою очередь, связывался с маршрутизаторами центрального и удаленных офисов. Их взаимодействие осуществлялось по протоколу динамической маршрутизации EIGRP.

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

    Одному из интерфейсов шифратора был назначен IP-адрес той локальной сети, где он был установлен. Второму — IP-адрес виртуальной сети класса C. Для простоты первый интерфейс назовем «внутренним», а второй — «внешним». Открытый трафик поступал на внутренний интерфейс, а с внешнего отправлялся уже зашифрованный трафик, причем он был инкапсулирован таким образом, что IP-адресом отправителя пакета являлся IP-адрес внешнего интерфейса шифратора, а IP-адресом получателя — IP-адрес внешнего интерфейса шифратора того офиса компании, для которого предназначался изначальный открытый пакет. Сам шифратор не занимался никаким анализом проходящего через него трафика, т. е. был, как уже говорилось, сквозным.

    Организация шифруемого соединения

    Для пояснения схемы мы рассмотрим пример работы по защищенному соединению между центральным офисом и одной из удаленных площадок. Трафик из локальной сети центрального офиса через коммутатор поступал на маршрутизатор Cisco. На маршрутизаторе были заданы правила условной маршрутизации (policy routing), согласно которым трафик, предназначавшийся для удаленного офиса компании, направлялся не в среду ATM, а на внутренний интерфейс установленного в локальной сети шифратора. Наглядно схема включения шифратора в сеть представлена на Рисунке 1. Маршрутизировать трафик — дело маршрутизатора, так что возлагать функции анализа трафика на шифрующие устройства не стоит. Шифратор «знал» только ключи шифрования для конкретных адресов получателей.

    С внешнего интерфейса шифратора инкапсулированный защищенный трафик направлялся опять-таки на маршрутизатор, на интерфейсе Ethernet которого было задано два IP-адреса: один — соответствовал локальной сети центрального офиса; другой — принадлежал виртуальной сети шифратора и служил для него шлюзом по умолчанию. Далее зашифрованный пакет снова сверялся со списками доступа маршрутизатора, где описываются правила динамической маршрутизации EIGRP, и, согласно им, направлялся в то или иное подразделение компании. Маршрутизатор удаленного офиса имел схожую конфигурацию, но не хранил сложные списки доступа c описанием маршрутизации EIGRP, а все пакеты, в том числе предназначавшиеся для других удаленных площадок, пересылались в центральную сеть. На интерфейсе Ethernet маршрутизатора удаленного офиса также было задано два IP-адреса: один принадлежал локальной сети филиала, а второй — виртуальной сети установленного там шифратора и являлся для шифратора шлюзом по умолчанию.

    Внешнему интерфейсу шифратора центрального офиса был назначен IP-адрес 192.168.0.2, внутреннему — 10.0.0.253. Все машины в локальной сети имели адрес из сети 10.0.0.0/24. Для интерфейса Ethernet на маршрутизаторе центрального офиса были определены адреса 10.0.0.1 и 192.168.0.1. На шифраторе в качестве шлюза по умолчанию был задан адрес 192.168.0.1. На всех рабочих станциях центрального офиса в качестве адреса шлюза по умолчанию был указан адрес 10.0.0.1.

    Внешнему интерфейсу маршрутизатора удаленного офиса соответствовал IP-адрес 192.168.1.2, а внутреннему — 10.0.1.253; все машины локальной сети удаленного офиса имели адреса из сети 10.0.1.0/24. Интерфейсу Ethernet на маршрутизаторе были назначены адреса 10.0.1.1 и 192.168.1.1. На шифраторе в качестве шлюза по умолчанию был указан адрес 192.168.1.1. На всех рабочих станциях локальной сети удаленного офиса в качестве шлюза по умолчанию был задан адрес 10.0.1.1. В скобках отметим, что приведенные адреса не существуют реально и используются только для иллюстрации схемы.

    Предположим, клиент из удаленной сети хочет установить защищенное соединение с сервером из центрального офиса по протоколу telnet. Его рабочая станция имеет IP-адрес 10.0.1.22, а сервер центрального офиса — 10.0.0.44. Таким образом, трафик от удаленного клиента имеет адрес отправителя 10.0.1.22 и адрес получателя 10.0.0.44, порт 23 (telnet). Поскольку шлюзу по умолчанию в удаленном офисе присвоен адрес 10.0.1.1, то все пакеты поступают на маршрутизатор Cisco. На маршрутизаторе настроены списки доступа, где описываются правила условной маршрутизации: в частности, пакеты, предназначающиеся сервису telnet (TCP-порт 23), должны маршрутизироваться не напрямую в центральный офис, а на внутренний интерфейс шифратора.

    Пакет от маршрутизатора попадает на указанный интерфейс, затем производится шифрование и инкапсуляция пакета. В результате с внешнего интерфейса шифратора удаленного офиса отсылается пакет с адресом отправителя 192.168.1.2 (внешний интерфейс шифратора удаленного офиса), адресом получателя 192.168.0.2 (внешний интерфейс шифратора центрального офиса), TCP-портом получателя 23. Пакет следует на интерфейс Ethernet маршрутизатора удаленного офиса, где, в соответствии с правилами маршрутизации для сети 192.168.0.0/24, направляется в центральный офис, на маршрутизаторе которого настроен список доступа — согласно ему, пакет с адресом получателя из сети 192.168.0.0/24 передается на внешний интерфейс шифратора (192.168.0.1). Далее он декапсулируется, расшифровывается и с внутреннего интерфейса шифратора центрального офиса попадает в сеть с адресом отправителя 10.0.1.22, адресом получателя 10.0.0.44 и портом получателя 23 (telnet), т. е. с исходными данными. После поступления на маршрутизатор пакет передается далее в соответствии с обычными правилами маршрутизации в локальной сети. В обратном направлении диалог сервера 10.0.0.44 с клиентом 10.0.1.22 происходит в соответствии с аналогичной процедурой, за исключением того, что списки доступа условной маршрутизации создаются на основании TCP-порта отправителя, а не получателя.

    Плюсы и минусы

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

    У данного подхода есть еще одно неоспоримое преимущество — это бо’льшая устойчивость сети в целом по сравнению с подключением шифратора на «горло» локальной сети. В частности, протоколы динамической маршрутизации позволяют определить доступность интерфейсов шифратора и автоматически перестроить таблицу маршрутизации в случае выхода из строя одного из интерфейсов либо шифратора в целом. Никакой инкапсуляции проводиться не будет, так что офисы компании станут доступны друг другу по сети. Но подобное решение имеет одну очень неприятную особенность: если администратор не узнает об изменении таблиц маршрутизации, то передаваемый в открытом виде трафик может оказаться скомпрометированным. На такой случай нужно предусмотреть схему оповещения администратора.

    Может показаться, что при статической маршрутизации схема параллельного включения шифратора в сеть ничем не отличается от схемы его подключения на «горло» сети, так как связь все равно пропадет, но это не так. Откат конфигурации маршрутизатора (хотя бы даже удаленно) осуществить гораздо проще, чем физически перекоммутировать оборудование на непосредственную маршрутизацию. У такого подхода есть свои плюсы — о защите трафика несложно позаботиться еще до того, как он попадет в среду передачи данных, где может произойти его компрометация.

    Мы намеренно не использовали встроенные возможности маршрутизатора Cisco по созданию VPN, так как уверены в следующем:

      маршрутизатор должен заниматься только маршрутизацией, а шифрованием — отдельное устройство;

      налицо значительная разница в стоимости IOS с поддержкой шифрования и IOS без таковой; кроме того, нельзя не учитывать существующие экспортные/импортные ограничения на криптографическое оборудование и алгоритмы;

      алгоритм шифрования DES, характерный для Cisco IOS, не считается устойчивым, и его применение не рекомендуется;

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

      Условная маршрутизация

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

      В настройках Cisco рекомендуется отключить IP Redirect на интерфейсах Ethernet посредством команды no ip redirects в конфигурации интерфейса Ethernet, поскольку при создании условного маршрута маршрутизатор с настройками по умолчанию рассылает широковещательное ICMP-сообщение Network Redirect. при его получении машины из подсети меняют статический маршрут для сети, для которой задан условный маршрут Cisco, со шлюза по умолчанию на криптошлюз. Естественно, в ситуации, когда необходимо восстановить изначальную конфигурацию сети (без криптошлюзов), откат не ограничивается восстановлением конфигурации Cisco — помимо этого, изменение маршрутов необходимо произвести вручную на рабочих станциях и серверах защищенной сети.

      Доверяй, но проверяй

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

      Об авторе: Павел Покровский — специалист по информационной безопасности.

      MikroTik L2TP/IPsec сервер не отправляет маршрут клиенту

      После двух дней мучений, готов признать что хвалёный MikroTik не справился с простой задачей, которая на Keenetic Ultra II решается в пару кликов. Возможно, это вовсе не связано с недоработками в RouterOS, а у меня просто не хватило терпения или знании, чтобы заставить L2TP/IPsec на «микротике» добавлять маршрут клиенту при соединении.

      Полазив по тематическим форумам и wiki, посвященных настройке оборудования MikroTik, найти решения так и не удалось. Собственно, в чём суть проблемы? При подключении к L2TP/IPsec серверу, клиент не видит компьютеры локальной сети за ним, впрочем как и самого роутера. Пинги дальше виртуальной сети не проходят.

      Решение 1: Отправлять весь трафик клиента через VPN

      Если в настройке соединения на клиенте указать что следует «Отправлять весь трафик через VPN», локальная сеть за роутером прекрасно видится. Но в этом случае мы гоним весь собственный трафик, вместе торрентами и прочим барахлом через удалённый офис, где запущен L2TP/IPsec сервер. Зачем это всё, если нам требуется просто получить доступ к терминальному серверу в удалённой сети?

      Windows 10 по умолчанию заворачивает весь трафик в VPN канал при создании подключения. Проверить это можно открыв свойства протокола IP версии 4 (TCP/IPv4) и в дополнительных параметрах TCP/IP будет активирован пункт «Использовать основной шлюз удаленной сети».

      Решение 2: Прописать дополнительный статический маршрут на клиенте

      Странно, но по всей видимости, MikroTik не умеет самостоятельно отправлять дополнительный маршрут клиенту при подключении к L2TP/IPsec серверу. Замечу, что Keenetic Ultra II прекрасно справляется с аналогичной задачей и поднять на нём L2TP/IPsec сервер может обычный пользователь. Лишний раз убеждаюсь, что «микроты» придуманы, чтобы наполнять жизнь упоротых любителей копания в настройках смыслом.

      Раз не получилось сотворить задуманное в настройках L2TP сервера, придётся добавить требуемый маршрут к удалённой сети на клиенте ручками. Для примера, пусть локальная сеть за MikroTik будет 192.168.88.0/24 и local-address L2TP/IPsec сервера 10.8.0.10:

      sudo route -n add 192.168.88.0/24 10.8.0.10

      Как ни крути, но такое решение тоже «костыль». И как бы не утверждали на одном из форумов по настройке «микротов», что заворачивать весь клиентский трафик в VPN канал благо, я с этим не согласен. Потому буду рад, если кто напишет как заставить MikroTik самостоятельно назначать маршруты клиентам вместе с выдачей IP.

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

      Комментариев: 29

      1. 2019-08-07 в 11:02:05 | Сергей Мусалимов

      А не проще взять Д-линк или другой нормальный роутер ?

      Сергей, не подскажете что подразумевается под «нормальными» роутерами? На Keenetic данная конкретная задача решается проще, но микротик, как ни крути, более функционален.

      Я не надеялась, но обновление решило проблему. Спасибо огромное

      длинк давно перестал быть нормальным.

      Была задачи в филиальной сети заменить роутеры на DD-WRT в которых уже использовался OpenVPN. Приобрели хваленый микротик, т.к. в нем заявлена поддержка OpenVPN. И что же оказалось — она есть, но куцая и нам не подошла, т.к нам бы пришлось все переделывать. Взяли Zyxel Keenetic, а вот там поддержка OpenVPN оказалась той что нужно. На них и остановились. Keenetic’и замечательно справляются со свое задачей не только с OpenVPN, но и без особых заморочек строить туннели Ipsec.

      правила надо было прописавать и masquerade настроеть под vpn. и все на тиках ходит.

      Павел, не подскажите какие именно правила отправляют маршрут клиенту? и как на это влияет masquerade?

      вот правила для фаервола

      пускаем IP нашего VPN-пула в локалку:

      По-умолчанию masquerade настроен для физического WAN-интерфейса(sfp1/ether1 и тд) , а нам надо запустить все через L2TP

      Делаем следующее правило:

      Еще есть ньюанс, что локальные интерфейсы в бридже надо перевести в proxy-arp

      Павел, а вы сами пробовали так делать? Как это влияет на отправку маршрута клиенту?

      Совершенно дилетантский подход к настройке железа. Ды, сударь, с кошками или джунами работали? Прежде чем написать статью — загуглите что и как настраивается, дело двух строк (и вам уже подсказали их) . А то круто получается: графоманством пострадать — норм, время есть, а в гугле настройку канала найти — «ай-яй-яй, микрот гавно»

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

      dre@mer, а на хрена? Статью написать, хайпануть, получить бабло за просмотр — это мы запросто, а изучить матчасть по настройке железа — «нафиг надо, хомячки схавают». Тем более, что вам уже подсказали как это сделать.

      Роман, отвечу в вашем стиле: «Все пи##Rасы, один я Дартаньян. » Ну а по сути, вы сами пробовали то что написано? Почитайте внимательно о чём статья. Проблема в том, что «микрот» не умеет отправлять маршрут клиенту при L2TP/IPsec, как Keenetik. Поэтому и приходится заворачивать весь пользовательский трафик в канал.

      И насчёт хайпа. вы реально считаете данную тему хайповой и что на ней можно заработать? Да она интересна только узким специалистам.

      если бы я не обслуживал парк порядка 30 микротов в 8 офисах, двух датацентрах (site-to-site ipsec, обычные l2tp каналы (с шифрование и без) , включая l2tp дублирующие, с распределенной маршрутизацией) — я бы молчал. Суть моего негодования сводится к тому, что не разобравшись с матчастью клепается чудо-статейка о том, какое говно этот микрот, и ничего он не умеет *рукалицо*.

      И, да, у меня все прекрасно работает, только дело в том, что микрот отправляет клиенту дефолт (если в курсе что это) , а сам трафик рулится маршрутам уже на микроте, и там его можно завернуть в любую дырку, но важно ещё понимать принцип работы firewall. А сравнивать его с длинком или зухелем, млять, это как сравнить инвалидку и болид формулы-1: и то и то машина, но какая разница между ними.

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

      Роман, я очень рад что вы освоили дефолтные маршруты, только статья не об этом

      Сколько баталий, интриг и войн. Предложение с firewall и nat это лишние костыли, все гораздо проще решается. Микротик умеет выполнять данное требование, желательно пройти курс MTCNA, после которого все вопросы данного рода отпадут. PPP — Secrets, когда создаете запись, в этой записи есть такая настройка, как Routes, именно здесь и указывается необходимая Вам сеть, куда надо попасть. Эта сеть добавляется в таблицу маршрутизации микротика и после и все запросы к этой сети, будут отправляться через local ip l2tp микротика. Easy win

      Вы путаете, я знаю про поле Routes и в нём прописывается сеть клиента, который подключается к L2TP серверу, а вот отправлять маршрут клиенту, Mikrotik пока не умеет. Не верите мне, почитайте форумы или задайте вопрос преподавателям курсов. Возможно это будет решено в 7-ой версии прошивки.

      Вы неправильно понимаете работу поле Routes. Оно прописывает дополнительный маршрут, куда должны попадать пакеты через vpn туннель. Маршрут на клиенте не будет появляться, но когда вы сделаете запрос к этой сети, пакет отправиться на шлюз local ip l2tp микротика, а там уже будет динамическая запись к вашей сети, куда надо попасть. Я эту схему реализовал, это работает. А вы вместо того, чтоб спорить, возьмите и проделайте. Если в боевую сеть страшно запускать, тогда соберите стенд с одним микротиком и проверьте.

      Более детально распишу. К примеру, у нас есть локальная сеть 192.168.1.0/24

      подключенная к ether2 микротика. Так же есть сеть 192.168.2.0/24, подключенная в другой порт, порты между собой независимы. Для сети 192.168.1.0/24 на микротике Вы создаете туннель, допустим, loсal ip 10.0.0.1 and remote ip 10.0.0.2. Так вот, чтобы из сети 192.168.1.0/24 попасть в сеть 192.168.2.0/24, мы прописываем в это поле Routes 192.168.2.0/24. После того, как клиент подключиться по впн, в таблице маршрутизации появится динамическая запись о сети 192.168.2.0/24 через созданный туннель. А маршрутизатор в свою очередь знает о сети 192.168.2.0/24 и как туда добраться. Соответственно компы из сети 192.168.1.0/24 смогут увидеть сетку 192.168.2.0/24

      Маршрут на клиенте не будет появляться, но когда вы сделаете запрос к этой сети, пакет отправиться на шлюз local ip l2tp микротика

      Каким образом клиентская машина поймёт, что пакеты для другой, неизвестной ей сети, следует отправлять именно в VPN-канал, если такого маршрута у клиента нет? Ещё раз обращаю внимание, что он НЕ ЯВЛЯЕТСЯ ШЛЮЗОМ ПО УМОЛЧАНИЮ!

      И уж поверьте, я не раз проверил что там передаётся, а что нет.

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

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

      . машина видит, что такой сети она не знает, поэтому отправляет на шлюз l2tp local ip микротика.

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

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

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

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

      Все выше сказанные посты имеют свою правду. Дело в том, что я столкнулся с приблизительно такой же проблемой. При создании VPN L2TP Server Mikrotik с использованием IpSec и VPN клиенте Windows без использования основного шлюза в удаленной сети, локальная сеть за сервером L2TP недоступна через сеть сделанную для VPN соединения. Добавление постоянных маршрутов на клиенте решало эту проблему, но при разрыве VPN соединения и при установке нового соединения сеть была не доступной. Решение оказалось простым. Необходимо сделать маршрут в созданном VPN в локальную сеть за микротиком. Что для этого необходимо:

      1. Для каждого пользователя VPN назначить ip address клиента и сервера, т.е. в PPP Secret указать в поле Local Address -это адрес сервера при создании тунеля из пула адресов созданных для данного VPN, в поле Remote Address — это адрес клиента. При установке VPN пользователи будут получать именно те адреса которые вы укажите.

      2. В поле Routes указать сеть куда необходимо маршрутизировать трафик (локальная сеть за микротиком).

      3. Прописать постоянный маршрут на Windows VPN-клиенте через адрес полученный при установке VPN.

      Люди добрые, почитал эту ветку и ужаснулся.

      А для чего на микроте протоколы динамической маршрутизации RIP, OSPF?

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

      Кому интересно, пишите.

      Расскажите как это настраивается в данном случае?

      Включите прослушиватель RIP на винде.

      Создайте server binding для vpn клиента.

      Запустите протокол RIP на роутере Routing-Rip-Interfaces — добавьте интерфейс vpn клиента, далее в Networks пропишите ip адрес туннеля vpn клиента и там же анонсируйте маршрут (подсеть), который хотите передать. Вот и всё.

      Доброго времени суток! Комментатор 184, а как быть mac os и ios

      Читать еще:  Сеть между Win 10 и Win xp
      Ссылка на основную публикацию
      Статьи c упоминанием слов:

      Adblock
      detector