Сервер Mac OS X 10.8 VPN: обход VPN для трафика локальной сети (маршрутизация трафика локальной сети на вторичное соединение)


10

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

Подключение к экстрасети осуществляется через маршрутизатор Wireless-N (назовем его Wi-Fi X). Мой сервер Mac Mini сконфигурирован с подключением к этому маршрутизатору в качестве основного подключения, что обеспечивает беспрепятственный доступ в Интернет через маршрутизатор. Соединения с этим устройством в непосредственной подсети возможны через порт LAN, но за пределами подсети вещи менее надежны.

Мне удалось настроить VPN-сервер для предоставления IP-адресов клиентам в диапазоне 192.168.11.150-192.168.11.200 с использованием как PPTP, так и L2TP, и я могу подключаться к экстрасети через VPN с использованием стандартной Mac OS X VPN Клиент в Системных настройках, однако неудивительно, что локальный адрес (назовем его internal.company.com) ничего не возвращает.

Я попытался обойти ограничение VPN-сервера, настроив Маршруты в настройках VPN. Наша компания использует 13.xxx для всего внутреннего трафика вместо 10.xxx, поэтому таблица маршрутизации выглядела примерно так:

IP Address ---------- Subnet Mask ---------- Configuration
0.0.0.0               248.0.0.0              Private
8.0.0.0               252.0.0.0              Private
12.0.0.0              255.0.0.0              Private
13.0.0.0              255.0.0.0              Public
14.0.0.0              254.0.0.0              Private
16.0.0.0              240.0.0.0              Private
32.0.0.0              224.0.0.0              Private
64.0.0.0              192.0.0.0              Private
128.0.0.0             128.0.0.0              Private

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

Я подозреваю, что, поскольку я не могу подключиться к VPN-серверу из-за пределов локальной подсети, он не устанавливает соединение с основным DNS-сервером и, следовательно, не может быть доступен в более крупной сети. Я думаю, что ввод имен хостов, таких как internal.company.com, не передается клиенту для разрешения, потому что сервер не знает, что IP-адрес попадает в публичный диапазон, так как я подозреваю (вероятно, следует проверить его, но у меня нет доступа к нему прямо сейчас), что он не может связаться с DNS-сервером, чтобы узнать что-нибудь об этом имени хоста.

Мне кажется, что все мои варианты решения этой проблемы сводятся к одному и тому же типу решения:

Выясните, как связаться с DNS через вторичное соединение на сервере. Я думаю, что если я смогу сделать [что-то], чтобы мой сервер распознал, что он также должен проверить мой локальный шлюз (скажем, IP-адрес сервера == 13.100.100.50 и IP-адрес шлюза == 13.100.100.1). Оттуда IP-адрес шлюза может сказать мне, что нужно найти DNS-сервер по адресу 13.1.1.1 и предоставить мне информацию о моей внутренней сети. Я очень озадачен этим путем - на самом деле не уверен, что у меня вообще есть смысл.

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

Любая помощь там? Или я над головой? Прямой прокси или прозрачный прокси также вариант для меня, хотя я понятия не имею, как настроить любой из них. (Я знаю, Google мой друг.)


может быть, этот другой пост может быть полезным: superuser.com/questions/453766/…
Лоренцо фон Маттерхорн

Ответы:


2

Ну, я даю ему шанс

Я не уверен, как пройти через какой-то трафик, я могу решить вашу проблему, но это потребует небольшого изменения настроек. Я предполагаю, что у вашего Mac есть два сетевых интерфейса, давайте назовем их eth0 и eth1 :-)

мы предполагаем, что eth0 подключен к вашей рабочей сети и имеет внутренний (рабочий) адрес 13.1.1.6, подсеть 255.0.0.0.

мы также предполагаем, что eth1 подключен к вашему WiFi X и имеет адрес (eth1 <---> WiFi X network) 192.168.1.10, подсеть 255.0.0.0, чтобы упростить задачу.

Я настроил VPN-серверы на BSD и Linux, но не на Mac, но концепция будет прежней, у вас есть варианты, я перечислю один:

1) Убедитесь, что таблица маршрутизации на Mac имеет следующую запись:

$>sudo route add 13.0.0.0/8 eth0

Для этого нужно убедиться, что туда поступит любой трафик, поступающий через интерфейс WiFi X или VPN, предназначенный для сети вашей компании (сети 13). Без этого Mac (который обеспечивает мост) действительно не сможет узнать, как маршрутизировать трафик между двумя интерфейсами, и по умолчанию он попытается отправить его из любого интерфейса по умолчанию, то есть WiFi X, который вы указали.

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.