У мене дещо дивна настройка для 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 клієнт у System Preferences, але не дивно, що локальна адреса (назвемо її 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 - мій друг.)