.png)
У меня довольно странная настройка 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, используя стандартный VPN-клиент Mac OS X в Системных настройках, однако, что неудивительно, локальный адрес (назовем его 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, как Private.
Я подозреваю, что поскольку я не могу связаться с VPN-сервером из-за пределов локальной подсети, он не подключается к основному DNS-серверу и, таким образом, не может быть доступен в более крупной сети. Я думаю, что ввод имен хостов, таких как internal.company.com, не отбрасывается клиенту для разрешения, потому что сервер не имеет представления о том, что IP-адрес попадает в публичный диапазон, поскольку я подозреваю (вероятно, следует провести ping-тест, но сейчас у меня нет к нему доступа), что он не может связаться с DNS-сервером, чтобы узнать что-нибудь об этом имени хоста.
Мне кажется, что все мои варианты решения этой проблемы сводятся к одному и тому же типу решения:
Выясните, как достичь DNS с помощью вторичного соединения на сервере. Я думаю, что если я смогу сделать [что-то], чтобы мой сервер распознал, он также должен проверить мой локальный шлюз (скажем, IP сервера == 13.100.100.50 и IP шлюза == 13.100.100.1). Оттуда IP шлюза может сказать мне найти DNS-сервер по адресу 13.1.1.1 и предоставить мне информацию о моей внутренней сети. Я совсем запутался в этом пути — на самом деле не уверен, что я вообще имею смысл.
Я думал попробовать сделать это на стороне клиента, но это тоже не имеет смысла, так как это добавит времени к каждой настройке на стороне клиента. Плюс, кажется более логичным решить это на сервере - я мог бы либо полностью избавиться от своей таблицы маршрутизации, либо сохранить ее - я думаю, единственное отличие будет в том, что внутренний трафик также будет проходить через сервер - вероятно, ненужная нагрузка для него.
Есть ли у кого-нибудь помощь? Или я не справляюсь? Прямой прокси или прозрачный прокси также являются вариантами для меня, хотя я понятия не имею, как настроить ни один из них. (Я знаю, Google — мой друг.)
решение1
Ну, я попробую:
Я не уверен, как заставить пройти только часть трафика. Я могу решить твою проблему, но это потребует небольшого изменения настроек. Я предполагаю, что у твоего Mac есть два сетевых интерфейса, назовем их eth0 и eth1 :-)
Предположим, что eth0 подключен к вашей рабочей сети и имеет внутренний (рабочий сетевой) адрес 13.1.1.6, подсеть 255.0.0.0.
Для простоты мы также предположим, что eth1 подключен к вашему WiFi X и имеет адрес (eth1 <---> сеть WiFi X) 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 выше, и попробовал бы это, если (надеюсь) этого еще нет.
Если вышеперечисленное не помогло, обновите таблицу маршрутизации и список IP-адресов вашего VPN-сервера или обновите исправление, с которым вы столкнулись. Надеюсь, это укажет вам правильное направление.