Настройка шлюза удаленных рабочих столов

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

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

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

Чтобы не быть голословными рассмотрим таблицу маршрутов самой обыкновенной рабочей станции. В Windows системах это можно сделать командой:

route print

В итоге мы увидим следующую таблицу:

Все очень просто, нас интересует секция IPv4 таблица маршрута, первые две колонки содержат адрес назначения и маску сети, затем следует шлюз — узел которому следует перенаправить пакеты для указанного назначения, интерфейс и метрика. Если в колонке Шлюз указано On-link, то это означает что адрес назначения находится в одной сети с хостом и доступен без маршрутизации. Метрика определяет приоритет правил маршрутизации, если адрес назначения имеет в таблице маршрутов несколько правил, то используется тот, что имеет меньшую метрику.

Наша рабочая станция принадлежит к сети 192.168.31.0 и, согласно таблице маршрутов, все запросы к данной сети отправляет на интерфейс 192.168.31.175, что соответствует сетевому адресу это станции. Если адрес назначения находится в одной сети с адресом источником, то доставка информации происходит без использования IP-маршрутизации (сетевой уровень L3 модели OSI), на канальном уровне (L2). В противном случае пакет отправляется узлу, указанному в соответствующему сети назначения правилу таблицы маршрутов.

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

Что сделает маршрутизатор, получив такой пакет? Прежде всего разберемся, чем отличается маршрутизатор от обычной сетевой станции. Если говорить крайне упрощенно, то маршрутизатором (роутером) является сетевое устройство, которое настроено передавать пакеты между сетевыми интерфейсами. В Windows это достигается включением службы Маршрутизация и удаленный доступ, в Linux заданием опции ip_forward.

Решение о передаче пакетов в этом случае также принимается на основании таблицы маршрутизации. Посмотрим, что содержит данная таблица на самом обычном роутере, например, описанном нами в статье: Ubuntu Server. Настраиваем роутер NAT + DHCP + Squid3. В Linux-системах получить таблицу маршрутов можно командой:

route -n

Как видим, наш роутер содержит маршруты к известным ему сетям 192.168.31.0 и 192.168.3.0, а также нулевой маршрут к вышестоящему шлюзу 192.168.3.1.

Адрес 0.0.0.0 в колонке шлюза (Gateway) обозначает, что адрес назначения доступен без маршрутизации. Таким образом все пакеты с адресами назначения в сетях 192.168.31.0 и 192.168.3.0 будут отправлены на соответствующий интерфейс, а все остальные пакеты будут переданы дальше по нулевому маршруту.

Следующий важный момент — адреса приватных (частных) сетей, они же «серые», к ним относятся три диапазона:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

Данные адреса могут свободно использоваться любым желающим и поэтому они не маршрутизируются. Что это значит? Любой пакет с адресом назначения принадлежащим одной из этих сетей будет отброшен маршрутизатором, если для него нет отдельной записи в таблице маршрутизации. Проще говоря, маршрут по умолчанию (нулевой) для таких пакетов маршрутизатором не применяется. Также следует понимать, что данное правило применяется только при маршрутизации, т.е. при передаче пакетов между интерфейсами, исходящий пакет с «серым» адресом будет отправлен по нулевому маршруту, даже если данный узел сам является маршрутизатором.

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

Самое время проверить, как это все работает. Попробуем с нашего узла 192.168.31.175 пропинговать узел 192.168.3.106, который находится в сети за роутером. Как видим, это нам удалось, хотя таблица маршрутов узла не содержит никаких сведений о сети 192.168.3.0.

Как это стало возможным? Так как узел-источник ничего не знает о сети назначения, то он отправит пакет на адрес шлюза. Шлюз проверит свою таблицу маршрутов, обнаружит там запись для сети 192.168.3.0 и отправит пакет на соответствующий интерфейс, в этом несложно убедиться выполнив команду трассировки, которая покажет весь путь нашего пакета:

tracert 192.168.3.106

Теперь попробуем выполнить пинг узла 192.168.31.175 с узла 192.168.3.106, т.е. в обратном направлении. У нас ничего не вышло. Почему?

Давайте внимательно посмотрим таблицу маршрутизации. Никаких записей для сети 192.168.31.0 она не содержит, поэтому пакет будет отправлен маршрутизатору 192.168.3.1, как основному шлюзу сети, который данный пакет отбросит, так как никаких данных о сети назначения не имеет. Как быть? Очевидно, что следует отправить пакет тому узлу, который содержит нужную информацию и может передать пакет по назначению, в нашем случае это роутер 192.168.31.100, который в данной сети имеет адрес 192.168.3.108.

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

192.168.31.0 mask 255.255.255.0 192.168.3.108

В дальнейшем мы будем придерживаться такой записи маршрутов, что она значит? Все просто, пакеты для сети 192.168.31.0 с маской 255.255.255.0 следует отправлять узлу 192.168.3.108. В Windows маршрут можно добавить командой:

route add 192.168.31.0 mask 255.255.255.0 192.168.3.108

В Linux:

route add -net 192.168.31.0 netmask 255.255.255.0 gw 192.168.3.108

Попробуем.

Давайте проанализируем результат, в таблице маршрутизации появился маршрут и все пакеты к сети 192.168.31.0 теперь отправляются роутеру этой сети, что видно из ответа команды ping, но до назначения не доходят. В чем дело? Самое время вспомнить, что одной из основных задач роутера является не только маршрутизация, но и функция сетевого экрана, который явно запрещает доступ из внешней сети внутрь. Если мы временно заменим данное правило разрешающим, то все будет работать.

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

route add 192.168.31.0 mask 255.255.255.0 192.168.3.108 -p

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

post-up route add -net 192.168.31.0 netmask 255.255.255.0 gw 192.168.3.108

Кстати, это не единственный способ настроить доступ из сети 192.168.3.0 в сеть 192.168.31.0, вместо того, чтобы добавлять маршрут для каждого узла, можно «научить» правильно отправлять пакеты маршрутизатор.

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

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

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

Самый простой случай, когда VPN-сервер (клиент) и маршрутизатор сети располагаются на одном хосте. Рассмотрим схему ниже:

Так как теорию, надеемся, вы усвоили и закрепили на практике, проанализируем маршрут пакетов из сети офиса 192.168.31.0 в сеть филиала 192.168.44.0, такой пакет будет отправлен на шлюз по умолчанию, который является также VPN-сервером. Однако данный узел ничего не знает о сети назначения и должен будет откинуть данный пакет. В тоже время мы уже можем обратиться к маршрутизатору филиала по его адресу в VPN-сети 10.8.0.2, так как данная сеть доступна с маршрутизатора офиса.

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

192.168.44.0 mask 255.255.255.0 10.8.0.2

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

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

Сначала рассмотрим первый вариант.

Для того, чтобы пакеты для сети филиала попали в VPN-сеть мы должны добавить на каждый клиент сети маршрут к VPN-серверу (клиенту), в противном случае они будут отправлены шлюзу, который их отбросит:

192.168.44.0 mask 255.255.255.0 192.168.31.101

Однако VPN-сервер ничего не знает о сети филиала, но может отправлять пакеты в пределах VPN-сети, где есть интересующий нас узел сети филиала, поэтому направим пакет туда, добавив на VPN-сервере (клиенте) маршрут:

192.168.44.0 mask 255.255.255.0 10.8.0.2

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

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

192.168.44.0 mask 255.255.255.0 192.168.31.101

Про задачу VPN-сервера (клиента) мы упоминали выше, он должен доставить пакеты тому узлу VPN-сети, который является частью сети назначения или имеет маршрут к ней.

192.168.44.0 mask 255.255.255.0 10.8.0.2

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

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

Мы успешно проделали предыдущие шаги настройки: предварительную настройку, установку DHCP и DNS, теперь можем перейти к следующему небольшому шагу — настройке общего доступа к интернету для локальной сети, через Ubuntu Server используя NAT.

Создаем  файл конфигурации NAT, командой:

sudo touch /etc/nat

и открываем его:

sudo nano /etc/nat

Вносим в файл следующий текст:#!/bin/sh

#Включаем форвардинг пакетов echo 1 > /proc/sys/net/ipv4/ip_forward

#Разрешаем траффик на lo iptables -A INPUT -i lo -j ACCEPT

#Разрешаем доступ из внутренней сети наружу iptables -A FORWARD -i enp9s0 -o enp14s0 -j ACCEPT

#Включаем NAT iptables -t nat -A POSTROUTING -o enp14s0 -s 192.168.137.0/24 -j MASQUERADE

#Разрешаем ответы из внешней сети iptables -A FORWARD -i enp14s0 -m state —state ESTABLISHED,RELATED -j ACCEPT

#Запрещаем доступ снаружи во внутреннюю сеть iptables -A FORWARD -i enp14s0 -o enp9s0 -j REJECT

Должно выглядеть вот так:

Создаем из файла скрипт (преобразуем в запускаемый файл), командой:

sudo chmod +x /etc/nat

Добавляем строку запуска скрипта post—up/etc/nat в файл конфигурации сетевых интерфейсов сервера, командой:

sudo nano /etc/network/interfaces

Файл конфигурации выглядит вот так:

Перезагружаем сервер, командой:

reboot

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

Большинство «не работает» вызвано невнимательностью! Внимательно проверяйте команды и не допускайте в файлах конфигурации лишних символов.

В следующей статье — Установка и настройка прокси сервера SQUID3 на Ubuntu Server

[nx_heading style=»coloredline» heading_tag=»h4″ size=»24″ align=»left»]От автора:[/nx_heading]

Если проблема решена, один из способов сказать «Спасибо» автору — здесь.

Если же проблему разрешить не удалось и появились дополнительные вопросы, задать их можно на нашем форуме, в специальном разделе.

[/nx_box]

1. Сбой работы DHCP-клиента Windows

Как правило, на подключенном к роутеру компьютере, при первоначальной настройке IP-адрес, маску и адрес шлюза не прописывают, а оставляют просто оставляют значение «Получить IP-адрес автоматически».  Не спорю — в большинстве случаев отлично работает и никаких проблем. Но вот когда в силу каких-либо причин, начинают сбоить службы — это может сыграть злую шутку. Поэтому, если у Вас периодически кратковременно пропадает проводная или беспроводная сеть, а в Диагностике сетей выдается сообщение «Шлюз недоступен» — первым делом пропишите статически IP-адреса. Делается это очень просто — нажимаем комбинацию клавиш Win+R. Откроется окно Выполнить:

 В строку открыть пишем команду ncpa.cpl и нажимаем кнопку ОК. Таким образом мы быстро попадем в список сетевых подключений Windows. На сетевом адаптере, где появляются проблемы с сетью, кликаем правой кнопкой мыши и выбираем пункт меню «Свойства»:

Нас интересует компонент Протокол Интернета версии 4(TCP/IPv4) — кликаем на нём дважды левой кнопкой. Откроется окно свойства протокола. Ставим галочку «Использовать следующий IP-адрес» и прописываем в качестве шлюза по умолчанию — IP-адрес роутера (если Вы его не знаете — смотрите пост Как узнать адрес роутера в сети). Маска как правило 255.255.255.0, а IP компьютера сделайте отличным на единицу от адреса шлюза, например, как на скриншоте выше. Сохраняем конфигурацию и наблюдаем за работой системы.

2. Windows отключает питание сетевого адаптера

Такой вариант можно смело обозвать «болезнью ноутбуков».  Дело в том, что на них при работе от батареи включается режим Экономия энергии. А это значит, что при простое сетевой карты, особенно беспроводного адаптера, система может просто отключить на нём питание. Вы же, запустив Диагностику, просто перезапустите адаптер и … получите сообщение «Шлюз, установленный по умолчанию, не доступен», после чего всё снова заработает. Чтобы этого избежать, надо зайти в свойства самого адаптера и на вкладке Управление электропитанием — снять флажок «Разрешить отключение этого устройства для экономии энергии»:

В принципе, после этого операционная система больше не будет его отключать. Но я бы ещё посоветовал немного подправить схему электропитания. Для этого в панели управления Windows находим раздел «Электропитание» -> «Настройка схемы электропитания» -> «Изменить дополнительные параметры схемы электропитания». Откроется вот такое окно:

Находим пункт «Параметры адаптера беспроводной сети»->»Режим энергосбережения» и выставляем ему значение «Максимальная производительность». Применяем параметры.

3. Проблема с драйверами сетевого адаптера

Это тоже один из частых случаев. Иногда, пользователи после переустановки Windows 7 или Windows 8 не особо замарачиваются с драйверами. А зря. Установка устаревшего драйвера может привести к постоянным сбоям адаптера. Он вроде и работает нормально, и ошибок больше никаких нет, а сбои случаются часто. Сетевая карта может просто кратковременно терять линк, либо вообще подвисать. Само-собой при этом может появляться сообщение, что шлюз недоступен. Поэтому в обязательном надо обновить драйвер до самой последней, актуальной версии. Для этого Вы должны зайти на сайт производителя сетевой карты и скачать оттуда последнюю версию драйвера. После этого идем в его настройки и на вкладке «Драйвер» нажимаем кнопку «Обновить»:

Тут-то Вы и должны подсунуть системе новый драйвер, после чего перезагрузить компьютер.

Используемые источники:

• https://interface31.ru/tech_it/2015/08/organizaciya-vpn-kanalov-mezhdu-ofisami-marshrutizaciya.html
• https://mhelp.kz/nastroyka-internet-gateway-ubuntu-server/
• https://nastroisam.ru/gateway-not-found/