Маршрутизация в linux для vpn
Уровень сложности материала — средний.
Иногда, возникает необходимость перенаправлять трафик к некоторым сайтам через другой сетевой интерфейс. Простой пример: сотрудники филиала большой компании, должны работать со служебными разделами корпоративного портала через VPN. Из сети Интернет, доступ к данным разделам закрыт, в связи с требованиями безопасности.
У нас есть Linux сервер, который, помимо прочего, функционирует в качестве маршрутизатора. Весьма распространенная ситуация, ее и будем рассматривать, как пример. На схеме изображена типичная структура сети основного офиса и филиала: 
Задача настроить Linux роутер таким образом, чтобы обращения к сайту example.org шли через VPN.
Будем исходить из того, что VPN соединение уже настроено; при подключении создается устройство соответствующего типа (ppp или tun).
Логически решение выглядит так:
Рассказывать как установить пакеты на вашей версии Linux я не буду, надеюсь вы уже можете это сделать самостоятельно. Тем более дистрибутивы разные, и приводить в качестве примера какой-то конкретный, считаю неправильным.
Для начала настроим dnsmasq.
В первую очередь, нас интересуют вышестоящие (upstream) DNS серверы, к которым будут направляться запросы. Сам по себе, dnsmasq является, своего рода, прокси сервером. По умолчанию данная информация берется из системных настроек, файла resolv.conf. Однако можно указать альтернативный файл с помощью строки (dnsmasq.conf)
Укажем список доменов для занесения соответствующих им IP адресов в ipset list с именем VIAVPN
Через разделитель «/» можно указать любое количество доменов. Обращаю внимание, что все субдомены тоже попадут в ipset. В конце строки указывается название листа, в нашем случае VIAVPN.
Теперь самое время завести тот самый список VIAVPN
# ipset create VIAVPN hash:ip family inet
Указывается тип списка – ip адреса со структурой хранения hash. То есть, с очень быстрым, фактически мгновенным, поиском IP адреса в огромном списке. Именно по этой причине используется ipset, а не напрямую правила iptables. Family inet говорит об адресах протокола IPv4.
Правило iptables, которое будет маркировать пакеты, к IP адресам доменов (то есть с пометкой VIAVPN), маркером 1. По сути, мы меняем одну метку на другую, но беда в том, что селкторы ip rule не могут работать с ipset, лишь с fwmark. Данное правило как раз служит исключительно для этого:
Команда не требует каких-то особых разъяснений, всё достаточно очевидно. Единственное, dst говорит о направлении трафика. То есть, извлекаем из пакета адрес назначения и проверяем его наличие в списке VIAVPN. Если присутствует, помечаем такой пакет меткой 1.
Переходим к маршрутизации
Ну, первое, конечно, заводим отдельную таблицу, назовем ее vpnrouting. Идем в файлик /etc/iproute2/rt_tables и добавляем туда строку
ID может быть любым свободным положительным числом до 255
Добавляем маршрут по умолчанию (default gateway) в созданную таблицу. Кроме него, в нашем случае, больше ничего не понадобится, однако, сюда можно добавить другие, более точные маршруты при необходимости
# ip route add table vpnrouting default dev tun0
Поскольку, интерфейс VPN, как правило, point-to-point — можно указать вместо адреса соседнего маршрутизатора, устройство, с которого следует отправлять пакеты. Что мы и сделали.
Почти всё готово! Осталось указать, в какой таблице искать маршруты для пакетов с меткой (fwmark) 1. Если добавлять маршруты через упрощенную утилиту route, то они, на самом деле, прописываются, в таблицу main. А правило для всех пакетов, по умолчанию, ищет маршруты именно в ней.
Выведем список всех правил поиска маршрута для наглядности:
# ip rule show
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
Тут всё просто, число слева — это приоритет. Для поступившего пакета ищется маршрут, начиная с наименьшего, по возрастанию. Сначала, в таблице local, там содержится информация о широковещании и адреса локальных интерфейсов. Таким образом ядро распознает широковещательные пакеты, а так же те, которые адресованы данной машине. Если маршрут для пакета не найден, проверяется следующая таблица – main. В ней всё то, что мы видим по команде «route –n». В том числе маршрут по умолчанию.
Задача указать правило поиска ДО таблицы main. По умолчанию, оно будет добавлено с приоритетом 32765. Нам это вполне подходит (хотя можем указать приоритет явным образом, например 100):
# ip rule add prio 100 fwmark 1 lookup vpnrouting
ВАЖНОЕ ЗАМЕЧАНИЕ!
Не забудьте проверить состояние rp_filter
Для нормальной работы, результат должен быть либо 0, либо 2. Смысл данного фильтра в следующем. Когда пакет приходит на интерфейс, ядро проверяет для него обратный маршрут. И если ответ предполагает отправку через другой интерфейс, а не тот же самый, то он считается мусорным и сбрасывается. Структура, которую мы настроили, не позволяет ядру корректно определить маршрут через тот же интерфейс. Поскольку на данном этапе он еще не маркирован, и предполагает отправку через default gateway таблицы main.
Для более полной информации, стоит прочитать что такое rp_filter, для чего он нужен и смысл значений его параметров. Я рекомендую переводить его в значение 2 для интерфейса tun0, и 1 для всех остальных.
Маршрутизация всего трафика через VPN в Ubuntu Linux
После многих часов поиска и устранения неисправностей, поиска потенциальных решений на этом и других сайтах, и я смирился, чтобы попросить совета у моих игроков. Я работаю над маршрутизацией всего сетевого трафика на экземпляре Ubuntu через Cisco VPN в университете. Используя встроенный сетевой менеджер или vpnc, я могу успешно установить соединение с VPN и успешно маршрутизировать трафик на любой университетский IP через VPN. Однако, помимо этих конкретных диапазонов IP-адресов, я не могу придумать какой-либо маршрут, который успешно сопоставит весь сетевой трафик через VPN.
До сих пор я пытался:
И многие другие глупые, неэффективные вещи, которые я не могу вспомнить достаточно хорошо, чтобы транскрибировать точно.
Кроме того, я пробовал маршрутизировать меньшие диапазоны IP-адресов и конкретные IP-адреса, но безрезультатно. Я не совсем уверен, что происходит не так, как следствия, которые я смог наблюдать, это сбои разрешения имен и сбои маршрутизации трафика через VPN. Что я здесь не так делаю?
Вот вывод ip route show после запуска VPN-соединения с VPNC:
Я успешно перенаправил произвольный трафик через этот VPN в MS Windows через клиент Cisco AnyConnect с конфигурацией по умолчанию. Вот как выглядит таблица маршрутизации, когда работает клиент AnyConnect (это другой компьютер за тем же маршрутизатором на 192.168.1.254).
Ваша сеть VPN 10.0.0.0/8, как показано этой строкой:
В настоящее время ваш маршрутизатор по умолчанию:
это, конечно, то, что вы не хотите, потому что он принадлежит вашей локальной сети: таким образом, все ваши вещи маршрутизируются через ваш локальный шлюз, как будто VPN не существует.
какой маршрут к вашему VPN-провайдеру.
Однако, если ваш провайдер готов перенаправить весь ваш трафик, вам нужно сделать следующее.
Во-первых, вам нужно выяснить, есть ли шлюз, который может принять ваше соединение, с другой стороны, потому что нам нужен его IP-адрес. Я дам вам четыре способа сделать это.
1) Когда компьютер подключен к VPN, попробуйте следующую команду:
Если все идет хорошо, вы должны увидеть ответ, содержащий следующую строку:
2) В качестве альтернативы вы можете попробовать перейти на один из разрешенных сайтов (те, которые отображаются в вашей таблице маршрутизации как проходящие через интерфейс tun0 ), а затем выполнить команду:
Вы должны получить список устройств, с которыми связались по протоколу ARP, с MAC и IP-адресом; скорее всего, вы получите либо ноль, либо один ответ. Если вы получили один ответ, то это ваш маршрутизатор.
3) Если вы не получили такой ответ, вы можете попробовать с
4) Используйте команду tcpdump:
и увидеть IP-адреса, выбрасываемые командой.
Если вы также не получили правильного ответа на этот тест, это означает, что кто-то действительно затянул винты в своей сети.
Но давайте будем оптимистичны и предположим, что теперь у вас есть кандидатский IP-адрес xwyz для удаленного маршрутизатора. Вам нужно будет удалить шлюз по умолчанию (как sudo!):
и попробуйте ориентироваться.
Позвольте мне повторить: поскольку ваш провайдер разрешил трафик только на несколько выбранных IP-адресов через свою VPN, возможно, он принял дополнительные меры (= брандмауэр), чтобы не дать умному пользователю принудительно использовать общий трафик через свою VPN. В этом случае вы ничего не можете сделать. Но если он этого не сделал, вышеуказанные шаги должны помочь вам найти решение.
Во всех ваших route командах отсутствуют маски сетей, поэтому они соответствуют только конкретному 0.0.0.0 адресу, а не всему интернету. Так замените 0.0.0.0 с 0.0.0.0/0 в первой команде вы пытались:
Может быть одно предупреждение, которое я не уверен, что ваш VPN-клиент решает сам: конечную точку туннеля нужно исключить из маршрутизации через VPN, она должна быть направлена через ваш eth0 интерфейс. Поэтому, если добавление этого маршрута по умолчанию нарушает вашу VPN, добавьте конкретный маршрут для вашей конечной точки VPN:
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Настраиваем L2TP VPN-сервер на платформе Linux (Debian / Ubuntu)
Перед тем, как приступать к работе над данной статьей мы внимательно изучили русскоязычный сегмент сети на предмет освещения данной темы и были весьма сильно удивлены. Большинство находящихся на первых страницах поиска ресурсов перепечатывает одну и ту же устаревшую инструкцию, даже в достаточно свежих публикациях. Но наш сайт с самого своего основания принципиально не занимается перепечатками (кроме переводов) и мы всегда проверяем на практике то, что рекомендуем нашим читателям. В этот раз нам пришлось потратить некоторое лишнее время на чтение документации, зато теперь мы можем предложить вам актуальный материал по настройке L2TP в Linux.
В качестве систем на тестовом стенде мы использовали Debian 10 и Ubuntu 20.04, но с некоторыми изменениями данная инструкция применима к любым версиям Linux со strongSwan версии 5.0 и выше.
Настраиваем IPsec
Именно с устаревшими настройками IPsec вам придется столкнуться в большинстве опубликованных инструкций. Нет, все даже будет работать, но вот безопасность такого решения окажется довольно низкой, не соответствующей современным требованиям. Поэтому, если у вас уже имеется настроенный экземпляр L2TP-сервера мы настоятельно советуем обновить его настройки.
Для работы с IPsec мы будем использовать пакет strongSwan, установим его:
Затем откроем файл настроек /etc/ipsec.conf и добавим в его конец следующие две секции:
Первая секция задает общие параметры: включает фрагментацию IKE и настраивает протокол обнаружения мертвых узлов (Dead Peer Detection, DPD), отвечающий за обнаружение неактивных клиентов. Вторая относится уже к L2TP-соединениям, указывая использовать транспортный режим IPsec, аутентификацию по общему ключу и задает используемые шифры. Приведенные значения являются рекомендуемыми и взяты из официальной документации strongSwan.
Общий ключ следует указать в файле /etc/ipsec.secrets, добавив в него следующую строку:
Результатом ее выполнения станет случайная строка длинной в 18 символов.
После внесения указанных настроек перезапустим службу:
Настраиваем L2TP
Для реализации функций L2TP-сервера предназначен пакет xl2tpd, для его установки выполните:
Затем откройте файл настроек /etc/xl2tpd/xl2tpd.conf, раскомментируйте и приведите к следующему виду опции:
Опции local ip и ip range отвечают за локальный адрес сервера в VPN-сети и диапазон адресов для выдачи удаленным клиентам. Здесь можно использовать два подхода: выдавать клиентам адреса из диапазона локальной сети офиса и включить ProxyARP, в этом случае настраивать маршрутизацию на клиентах не требуется, они будут как-бы включены в общую сеть офиса на канальном уровне (L2), либо выдавать адреса из непересекающегося диапазона и использовать маршрутизацию. Автоматизировать создание маршрутов для Windows-клиентов можно с использованием PowerShell.
Для настройки PPP перейдем в /etc/ppp и скопируем стандартный файл настроек:
Затем открываем файл /etc/ppp/options.xl2tpd на редактирование и приводим к следующему виду. Опции перечислены в порядке их следования, нужно раскомментировать их и указать нужное значение, если опция отсутствует, то ее следует добавить в конце файла.
Если вы будете использовать ProxyARP то дополнительно раскомментируйте опцию:
Также для Windows-клиентов можно передать настройку DNS-серверов, для этого добавьте опции:
Это позволит настроить первичный и альтернативный DNS-сервера в системе.
Сохраним все внесенные изменения и перезапустим службу L2TP-сервера:
Строку со следующим сообщением можно проигнорировать, на работу VPN-сервера она не влияет:
Заключительным этапом настройки будет создание учетных записей для удаленных клиентов, для этого откроем файл /etc/ppp/chap-secrets и внесем следующую строку:
Первым указываем логин, затем имя службы, оно должно совпадать с тем, которое мы указали в опции name в xl2tpd.conf, после него идет пароль и IP-адрес клиента, символ * обозначает что можно присвоить любой адрес из выбранного диапазона. Если же требуется выдать клиенту постоянный адрес, то его следует указать явно, и он не должен входить в динамический диапазон указанный в ip range, например:
Для доступа к L2TP-серверу следует разрешить в брандмауэре входящие подключения к портам 500 UDP и 4500 UDP, подключение к 1701 UDP, вопреки распространенному заблуждению, разрешать не следует.
Дополнительные материалы:
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Организация каналов между офисами при помощи OpenVPN на платформе Linux
Так уж получилось, что за все время существования нашего ресурса мы ни разу не обращались к теме OpenVPN на платформе Linux. Несмотря на то, что это кроссплатформенный продукт, наши публикации, а точнее публикации наших авторов затрагивали только Windows платформу, поэтому мы решили устранить этот досадный недостаток и заодно самостоятельно проработать данную тему. Кроме того, данный материал, как и все наши материалы, органично связан с другими публикациями, что позволит легко вписать данный сервис в инфраструктуру созданную на основе наших статей.
Следует понимать, что OpenVPN не накладывает каких-либо ограничений на платформы для работы сервера и клиентов, вы можете без проблем объединить в единую сеть устройства с разными ОС и аппаратными платформами и все это будет работать.
Отдельного внимания заслуживают богатые сетевые возможности продукта, который может успешно работать даже в сложных сетевых конфигурациях, не допускающих прохождения некоторых видов трафика (например, мобильные операторы), а также возможность автоматической конфигурации узлов сети, в т.ч. настройки маршрутов.
Схема сети и маршрутизация
Мы специально не стали разворачивать для OpenVPN отдельную конфигурацию в наше лаборатории, а воспользовались уже существующими виртуальными машинами. В качестве сервера центрального офиса мы использовали роутер на базе Ubunutu Server 14.04 LTS, за которым находится сеть 192.168.31.0/24, в которой находится рабочая станция под управлением Windows 10. В филиале OpenVPN установлен на сервер с Debian 8, который принадлежит сети 192.168.18.0/24, в которой находится рабочая станция с Windows 8.1 и которая выходит в интернет через простой роутер начального уровня.
Таким образом мы реализовали два основных варианта, когда машина с OpenVPN является шлюзом сети и когда она установлена на одном из узлов, что требует разной настройки маршрутизации.
Рассмотрим первый случай. Так как OpenVPN находится на шлюзе сети, то каких-либо дополнительных настроек маршрутизации нам делать не надо, все пакеты, не принадлежащие локальной сети, все равно будут отправлены шлюзу, а задачу их маршрутизации на самом шлюзе мы возложим на OpenVPN. В частности, нам нужно будет отправить пакеты к сети 192.168.18.0/24 на другой конец туннеля.
В случае, когда OpenVPN расположен на одном из узлов сети ситуация несколько иная. Так, например, пакеты к сети 192.168.31.0/24 будут также направлены шлюзу, который их просто отбросит, так как диапазоны частных сетей («серые» IP) не маршрутизируются. Поэтому нам потребуется явно задать маршрут к OpenVPN, который передаст эти пакеты дальше, согласно собственных настроек маршрутизации, а именно OpenVPN серверу. Это можно сделать, прописав соответствующий маршрут на роутере сети, либо, если роутер не позволяет этого сделать, непосредственно на каждой рабочей станции.
В нашем случае потребуется маршрут (на роутере или на клиентах):
который будет направлять все пакеты к сети 192.168.31.0 узлу с установленным OpenVPN, дальнейшая маршрутизация на другой конец туннеля будет выполняться также силами OpenVPN.
Мы настоятельно рекомендуем прорабатывать данный вопрос перед развертыванием VPN-сети, чтобы у вас уже на этом этапе было полное понимание ее структуры и схемы маршрутизации между ее узлами. Более подробную информацию по данному вопросу можно получить в статье: Организация VPN каналов между офисами. Маршрутизация.
Настройка сервера OpenVPN
Прежде всего установим необходимые пакеты:
Пакет easy-rsa предназначен для создания и управления сертификатами и по сути представляет собой автономный центр сертификации (CA), поэтом следует принять меры по недопущению доступа сторонних лиц к закрытым ключам CA. В тоже время мы считаем избыточными советы по выносу центра сертификации на отдельный хост, в небольших сетях это может оказаться более небезопасно, чем размещение на роутере, к которому имеет доступ только администратор.
Скопируем рабочую директорию easy-rsa в папку с настройками OpenVPN:
В своей работе easy-rsa использует библиотеку openssl и содержит конфигурационные файлы для разных версий библиотеки. В современных системах повсеместно используется openssl-1.0.x поэтому сразу делаем символическую ссылку на нужный конфигурационный файл:
Теперь откроем файл /etc/openvpn/easy-rsa/vars и отредактируем в нем следующие строки, указав собственные учетные данные, например, так:
Сохраним файл и перейдем к созданию собственного CA, для этого перейдем в директорию easy-rsa и загрузим переменные:
Затем произведем очистку и инициализацию нашего центра сертификации:
Первая команда произведет полную очистку рабочей директории с ключами и служебными файлами и ее случайное выполнение на работающем CA приведет к его уничтожению. Вторая команда создаст комплект из открытого и закрытого ключей центра сертификации.
В процессе создания ключа вы будете получать вопросы, ответы по умолчанию на которые содержатся в квадратных скобках и основаны на ваших данных из файла vars, поэтому просто подтверждаем их нажатием Enter (или вводим свои значения).
Закончив с центром сертификации перейдем к формированию ключей и сертификатов сервера. Но сначала создадим файл параметров Диффи-Хеллмана. Данный алгоритм шифрования используется для обеспечения режима прямой секретности, которая сводится к тому, что даже если злоумышленник получит ключи, то он не сможет расшифровать перехваченные ранее данные, так как они зашифрованы с уникальным сеансовым ключом, который нигде не сохраняется.
Результатом выполнения данной команды будет появление в директории с ключами файла dh2048.pem, который нужен только серверу, но в тоже время секретным он не является.
Наконец сформируем ключи собственно для сервера:
В процессе генерации вам также придется подтвердить параметры из файла vars, либо указать свои, в конце вы получите два вопроса о подписи и выпуске сертификата, на оба отвечаем утвердительно.
Теперь перейдем к настройке самого OpenVPN. Прежде всего создадим директорию для хранения ключей, несмотря на то, что можно указать пути к папке с ключами easy-rsa, мы все-таки советуем хранить серверные ключи отдельно.
Перейдем в папку с ключами easy-rsa и скопируем необходимые ключи и сертификаты:
Затем распакуем и скопируем в /etc/openvpn шаблон файла конфигурации:
Напомним, чтобы не набирать длинные пути можно воспользоваться автодополнением по клавише Tab.
Откроем данный файл (/etc/openvpn/server.conf) и перейдем к его редактированию, если не указано иное, то приведенные ниже опции следует найти и привести к указанному виду, при необходимости раскомментировав. Опции перечислены в порядке их следования в файле.
Данные опции установлены по умолчанию и задают порт, протокол и тип туннеля, менять их не следует, однако на плохих каналах иногда имеет смысл использовать протокол tcp. Ниже добавим опцию, указывающую топологию создаваемой VPN-сети:
Затем найдем и откорректируем пути к ключам и сертификатам:
Синтаксис конфигурационного файла допускает указание относительных путей, в этом случае корневой будет считаться папка /etc/openvpn.
Зададим диапазон OpenVPN сети:
Следующая опция указывает файл для хранения выданных клиентам IP-адресов, так как OpenVPN прекрасно умеет назначать адреса мы не видим смысла делать это вручную:
Укажем путь к директории с конфигурационными файлами, выполняемыми при подключении клиента:
Затем перейдем к настройкам маршрутизации. Прежде всего укажем шлюз по умолчанию для OpenVPN сети, которым должен являться сервер:
Передадим всем клиентам аналогичную команду, но для сети за сервером:
Установим параметры проверки активности:
Данная опция устанавливает интервал проверки узла (10 сек) и время после которого, при отсутствии ответа, клиент считается неактивным.
Укажем тип применяемого шифрования, на выбор предлагается три вида шифра, но Triple-DES имеет самые большие накладные расходы, поэтому выбирать следует между Blowfish и AES. Однозначно дать рекомендации здесь трудно, но следует учитывать, что AES де-факто является промышленным стандартом и аппаратно поддерживается в процессорах Intel.
В целях безопасности понизим права запущенного сервера:
При этом обязательно проконтролируйте наличие следующих опций, которые обеспечивают правильную работу с ресурсами после понижения прав:
Укажем расположение логов:
Следующие опции задают подробность лога и количество повторяющихся в логе сообщений:
Для отладки проблем с подключением уровень лога следует поднять до 5-6.
На этом настройка сервера закончена, сохраняем файл конфигурации и создаем директорию для конфигураций клиентов, иначе получите ошибку при запуске службы:
Теперь можно попробовать запустить сервер:
Убедимся в наличии сетевого интерфейса туннеля командой
И проверим таблицу маршрутизации:
Настройка клиента OpenVPN
Настройка клиента начинается на сервере с генерации ключевой пары. Для этого снова перейдем в директорию easy-rsa и загрузим переменные (если вы создаете клиентские ключи одновременно с серверными, то повторно загружать переменные не нужно).
Выполним генерацию клиентских ключей и сертификатов командой:
На компьютер клиента нам нужно передать ca.crt, client1.crt и client1.key, последний файл является секретным и не должен передаваться в открытом виде по незащищенным каналам.
Также создадим в папке ccd файл с инструкциями для клиента, которые будут выполнены при его подключении. Имя файла должно совпадать с именем сертификата клиента, точнее с полем CN в нем, если вы не меняли это поле при создании ключевой пары оно будет соответствовать имени файла сертификата.
Откроем этот файл и внесем в него строки:
Данная команда создает маршрут в OpenVPN сети, направляя пакеты предназначенные сети 192.168.18.0 на внутренний адрес данного клиента. В таблице маршрутов ОС данный маршрут не отображается, но без него маршрутизация в OpenVPN сети правильно работать не будет.
Теперь, взяв с собой необходимые ключи и сертификаты, переместимся на клиентский компьютер. В нашем случае это сервер с установленным Debian 8.
Установим необходимые пакеты:
Создадим директорию для ключей и разместим в ней ключи и сертификаты:
Скопируем файл с шаблоном конфигурации клиента:
И перейдем к его редактированию:
Затем укажем адрес и порт нашего сервера:
Вместо доменного имени можно указывать IP-адрес, например, так:
Следующая опция предписывает бесконечное число попыток разрешить доменное имя сервера OpenVPN, рекомендуется для клиентов с нестабильным подключением к сети.
Понижаем права службы после запуска (если конфигурационный файл предназначен для Windows-машин данные опции не нужны):
Обязательно проверяем наличие:
Указываем расположение ключей и сертификатов:
Следующая опция предотвращает потенциальные атаки класса «человек посередине»:
Затем укажем тип шифрования, он должен совпадать с тем, что вы указали на сервере:
Задаем расположение логов и их детализацию:
Сохраняем файл конфигурации и запускаем службу с явным указанием клиента, в противном случае будет выполнена попытка найти и запустить конфиг сервера:
Также убеждаемся в том, что туннельный интерфейс создался и необходимые маршруты добавлены:
На скриншоте выше несложно заметить маршрут в сеть 192.168.31.0 через туннель, но так как данный компьютер не является шлюзом сети, то нам нужно будет добавить на шлюзе или клиентских ПК маршрут к сети 192.168.31.0 через локальный адрес данного компьютера, о чем мы говорили в начале статьи.
Например, мы добавили такой маршрут на клиентском ПК c Windows 8.1:
После чего без каких-либо проблем смогли получить доступ к компьютерам в сети офиса (добавленный вручную маршрут мы выделили на скриншоте).
А также в обратном направлении.
Обратите внимание, что в этом случае никаких дополнительных маршрутов к сети 192.168.18.0 на клиентском ПК прописывать нет необходимости.
Дополнительные материалы:
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: