Создать маршрут для рабочего VPN-трафика

Question

Что создало вашу проблему?

Что здесь происходит, так это то, что подключение к VPN вставляет очень широкий маршрут в таблицу маршрутизации вашей ОС. Вы можете запустить `route print` до и после подключения VPN, чтобы увидеть, какие маршруты добавляются как побочный эффект подключения VPN.

Вы видите, что в вашу таблицу маршрутов добавлена следующая комбинация маршрутов:

===========================================================================
  Network Address          Netmask         Gateway         Interface  Metric
          0.0.0.0          0.0.0.0         On-link    172.17.101.209      56
      65.70.114.5  255.255.255.255    192.168.86.1     192.168.86.37    4516
      172.17.15.0    255.255.255.0         On-link    172.17.101.209      56
===========================================================================

Также добавлены другие маршруты. Нас они не так уж и волнуют.

Первый добавленный маршрут говорит, что трафик, предназначенный для "куда угодно", должен использовать туннель VPN. Следовательно, это маршрут по умолчанию. За исключением некоторых более конкретных пунктов назначения, любой трафик, исходящий с вашего компьютера, будет использовать шлюз VPN. Обратите внимание, что в таблице все еще указан старый маршрут по умолчанию, который указывает "использовать шлюз LAN для где угодно", но его метрика выше (хуже). Этот маршрут больше не является предпочтительным.

Второй добавленный маршрут пробивает дыру, которая говорит, что трафик, предназначенный для публичного IP VPN-сервера, должен использовать старый шлюз. Обратите внимание, что даже несмотря на то, что метрика выше, маршрут более специфичен. Сетевая маска 255.255.255.255означает «только для этого IP-адреса». Специфичность имеет приоритет над метрикой.

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

Другие добавленные маршруты включают новый многоадресный маршрут по умолчанию (224.0.0.0) и широковещательный маршрут (..*.255) маршруты. Также есть маршруты, добавленные для собственного IP-адреса вашего компьютера в каждой сети. Не уверен, зачем они нужны; возможно, это особенность Windows.

В чем техническая проблема?

Эти маршруты сообщают вашему компьютеру о необходимости отправлять через VPN-туннель ВЕСЬ трафик, за исключением самого VPN-туннеля и трафика для непосредственной локальной сети. Это делается потому, что VPN-шлюз может (и часто должен) направлять ваш трафик в большее количество подсетей в удаленной интрасети (в отличие от Интернета). Например, при подключении к VPN вашему компьютеру выдается IP-адрес 172.17.101.209/24. Почтовые серверы в удаленной сети могут быть расположены по адресу 172.17.15.4/24, Sharepoint по адресу 172.17.7.16/24, Skype по адресу 172.17.55.27/24 и т. д. Все они находятся в отдельных подсетях от вашего VPN IP, и только VPN-шлюз может направлять трафик на эти машины. Вместо того чтобы вносить каждый IP-адрес или подсеть по отдельности в таблицу маршрутизации (например, маршрут к 172.17.15.0), корпоративному ИТ-отделу проще задать/переопределить маршрут по умолчанию для всего трафика, чтобы использовать VPN, и позволить VPN-шлюзу самостоятельно разобраться, как подключить вас ко всем подсетям, к которым вы хотите получить доступ.

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

Как теоретически решить эту проблему?

Нам нужно знать, какие сети находятся на каком шлюзе. Если мы попытаемся использовать шлюз для сети, которая не маршрутизируется с этого шлюза, мы получим ответ `DESTINATION NOT REACHABLE`. Если мы используем удаленный шлюз для доступа к нашему локальному серверу SharePoint, мы получим этот ответ. Это ставит нас в сложное положение, когда нам приходится вручную добавлять маршруты в таблицу маршрутизации нашей ОС, сообщая ей, какой шлюз использовать для разных диапазонов IP-адресов. Это может быть очень капризно, особенно в крупных корпоративных сетях, поскольку обе сети могут использовать одни и те же внутренние диапазоны IP-адресов. По сути, мы находимся в ситуации, когда мы выбираем один из двух шлюзов в качестве шлюза по умолчанию, а затем добавляем маршруты для отдельных подсетей, которые нам нужны, с другого шлюза.

Какую команду мне выполнить, чтобы эта проблема исчезла?

Вы правы. Вы запускаете команды типа `route -p add`, чтобы добавить маршруты для любого шлюза, который не является вашим шлюзом по умолчанию. Похоже, ваш коллега решил использовать шлюз VPN в качестве шлюза по умолчанию, а затем вручную добавить маршруты для каждого локального подмножества, к которому вам нужен доступ. Вы можете использовать `nslookup`, чтобы найти IP-адреса нужных вам серверов из вашей локальной сети, а затем добавить всю подсеть, в которой находится служба, в вашу таблицу маршрутизации.

Например, я бы запустил nslookup sharepoint.localcompany.comи получил бы IP 192.168.12.51. Затем я бы запустил route -p add 192.168.12.0 mask 255.255.255.0 <LAN-gateway-ip>.

Надеюсь, вам нужно добавить только одну или две подсети, чтобы все заработало. Надеюсь, эти подсети не являются общими (например, 192.168.0.0/24, 192.168.0.1/24 или 10.0.0.0/24). См. "другие проблемы" ниже.

Редактировать для новой информации

Учитывая IP-адреса, которые я вижу в вашей таблице маршрутизации, я бы запустил эту команду и посмотрел, будет ли все работать лучше. Я не знаю, какой интерфейс 10 или 14 вы используете для локальной сети, поэтому выберите соответствующий номер в зависимости от вашей настройки.

route -p add 192.168.0.0 mask 255.255.0.0 0.0.0.0 IF [10/14]

Эта команда говорит: «Использовать шлюз, полученный на интерфейсе LAN, для IP-адресов в диапазоне от 192.168.0.0 до 192.168.255.255». Это может нарушить некоторые вещи, в этом случае вы можете откатить его, заменив addна delete.

Другие проблемы

Вся эта проблема реплицируется в подсистеме DNS. У вас есть DNS-серверы для двух разных сетей, а `internal-sharepoint..com` не находится на удаленном DNS-сервере. Мне не хочется оставлять это упражнение пользователю, но это совершенно отдельная проблема для отлова. TL;DR: Я полагаю, что вы полагаетесь на «DNS-суффиксы», чтобы узнать, какой DNS-сервер использовать. Пожалуйста, задайте отдельный вопрос, если вам нужна помощь с этим.

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

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

Пожалуйста, дайте мне знать, если это объяснение непонятно или если я могу объяснить часть более подробно.

Answer 1

Что создало вашу проблему?

Что здесь происходит, так это то, что подключение к VPN вставляет очень широкий маршрут в таблицу маршрутизации вашей ОС. Вы можете запустить `route print` до и после подключения VPN, чтобы увидеть, какие маршруты добавляются как побочный эффект подключения VPN.

Вы видите, что в вашу таблицу маршрутов добавлена следующая комбинация маршрутов:

===========================================================================
  Network Address          Netmask         Gateway         Interface  Metric
          0.0.0.0          0.0.0.0         On-link    172.17.101.209      56
      65.70.114.5  255.255.255.255    192.168.86.1     192.168.86.37    4516
      172.17.15.0    255.255.255.0         On-link    172.17.101.209      56
===========================================================================

Также добавлены другие маршруты. Нас они не так уж и волнуют.

Первый добавленный маршрут говорит, что трафик, предназначенный для "куда угодно", должен использовать туннель VPN. Следовательно, это маршрут по умолчанию. За исключением некоторых более конкретных пунктов назначения, любой трафик, исходящий с вашего компьютера, будет использовать шлюз VPN. Обратите внимание, что в таблице все еще указан старый маршрут по умолчанию, который указывает "использовать шлюз LAN для где угодно", но его метрика выше (хуже). Этот маршрут больше не является предпочтительным.

Второй добавленный маршрут пробивает дыру, которая говорит, что трафик, предназначенный для публичного IP VPN-сервера, должен использовать старый шлюз. Обратите внимание, что даже несмотря на то, что метрика выше, маршрут более специфичен. Сетевая маска 255.255.255.255означает «только для этого IP-адреса». Специфичность имеет приоритет над метрикой.

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

Другие добавленные маршруты включают новый многоадресный маршрут по умолчанию (224.0.0.0) и широковещательный маршрут (..*.255) маршруты. Также есть маршруты, добавленные для собственного IP-адреса вашего компьютера в каждой сети. Не уверен, зачем они нужны; возможно, это особенность Windows.

В чем техническая проблема?

Эти маршруты сообщают вашему компьютеру о необходимости отправлять через VPN-туннель ВЕСЬ трафик, за исключением самого VPN-туннеля и трафика для непосредственной локальной сети. Это делается потому, что VPN-шлюз может (и часто должен) направлять ваш трафик в большее количество подсетей в удаленной интрасети (в отличие от Интернета). Например, при подключении к VPN вашему компьютеру выдается IP-адрес 172.17.101.209/24. Почтовые серверы в удаленной сети могут быть расположены по адресу 172.17.15.4/24, Sharepoint по адресу 172.17.7.16/24, Skype по адресу 172.17.55.27/24 и т. д. Все они находятся в отдельных подсетях от вашего VPN IP, и только VPN-шлюз может направлять трафик на эти машины. Вместо того чтобы вносить каждый IP-адрес или подсеть по отдельности в таблицу маршрутизации (например, маршрут к 172.17.15.0), корпоративному ИТ-отделу проще задать/переопределить маршрут по умолчанию для всего трафика, чтобы использовать VPN, и позволить VPN-шлюзу самостоятельно разобраться, как подключить вас ко всем подсетям, к которым вы хотите получить доступ.

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

Как теоретически решить эту проблему?

Нам нужно знать, какие сети находятся на каком шлюзе. Если мы попытаемся использовать шлюз для сети, которая не маршрутизируется с этого шлюза, мы получим ответ `DESTINATION NOT REACHABLE`. Если мы используем удаленный шлюз для доступа к нашему локальному серверу SharePoint, мы получим этот ответ. Это ставит нас в сложное положение, когда нам приходится вручную добавлять маршруты в таблицу маршрутизации нашей ОС, сообщая ей, какой шлюз использовать для разных диапазонов IP-адресов. Это может быть очень капризно, особенно в крупных корпоративных сетях, поскольку обе сети могут использовать одни и те же внутренние диапазоны IP-адресов. По сути, мы находимся в ситуации, когда мы выбираем один из двух шлюзов в качестве шлюза по умолчанию, а затем добавляем маршруты для отдельных подсетей, которые нам нужны, с другого шлюза.

Какую команду мне выполнить, чтобы эта проблема исчезла?

Вы правы. Вы запускаете команды типа `route -p add`, чтобы добавить маршруты для любого шлюза, который не является вашим шлюзом по умолчанию. Похоже, ваш коллега решил использовать шлюз VPN в качестве шлюза по умолчанию, а затем вручную добавить маршруты для каждого локального подмножества, к которому вам нужен доступ. Вы можете использовать `nslookup`, чтобы найти IP-адреса нужных вам серверов из вашей локальной сети, а затем добавить всю подсеть, в которой находится служба, в вашу таблицу маршрутизации.

Например, я бы запустил nslookup sharepoint.localcompany.comи получил бы IP 192.168.12.51. Затем я бы запустил route -p add 192.168.12.0 mask 255.255.255.0 <LAN-gateway-ip>.

Надеюсь, вам нужно добавить только одну или две подсети, чтобы все заработало. Надеюсь, эти подсети не являются общими (например, 192.168.0.0/24, 192.168.0.1/24 или 10.0.0.0/24). См. "другие проблемы" ниже.

Редактировать для новой информации

Учитывая IP-адреса, которые я вижу в вашей таблице маршрутизации, я бы запустил эту команду и посмотрел, будет ли все работать лучше. Я не знаю, какой интерфейс 10 или 14 вы используете для локальной сети, поэтому выберите соответствующий номер в зависимости от вашей настройки.

route -p add 192.168.0.0 mask 255.255.0.0 0.0.0.0 IF [10/14]

Эта команда говорит: «Использовать шлюз, полученный на интерфейсе LAN, для IP-адресов в диапазоне от 192.168.0.0 до 192.168.255.255». Это может нарушить некоторые вещи, в этом случае вы можете откатить его, заменив addна delete.

Другие проблемы

Вся эта проблема реплицируется в подсистеме DNS. У вас есть DNS-серверы для двух разных сетей, а `internal-sharepoint..com` не находится на удаленном DNS-сервере. Мне не хочется оставлять это упражнение пользователю, но это совершенно отдельная проблема для отлова. TL;DR: Я полагаю, что вы полагаетесь на «DNS-суффиксы», чтобы узнать, какой DNS-сервер использовать. Пожалуйста, задайте отдельный вопрос, если вам нужна помощь с этим.

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

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

Пожалуйста, дайте мне знать, если это объяснение непонятно или если я могу объяснить часть более подробно.

Создать маршрут для рабочего VPN-трафика

решение1

Что создало вашу проблему?

В чем техническая проблема?

Как теоретически решить эту проблему?

Какую команду мне выполнить, чтобы эта проблема исчезла?

Редактировать для новой информации

Другие проблемы

Связанный контент