У меня несколько странная настройка для 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 Клиент в Системных настройках, однако неудивительно, что локальный адрес (назовем его внутренним.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 - мой друг.)