В моей домашней сети (10.0.1.0/24) у меня есть Mac и устройства iOS (остальные не имеют значения). Клиенты LAN получают IPv4 и IPv6 (собственный) доступ через Airport Extreme (AEBS), подключенный к кабельному модему на Comcast (у меня нет лучшего выбора). Мне требуется VPN для доступа к некоторым рабочим ресурсам, и было бы удобно, если бы VPN "просто работала" на любом из имеющихся у меня экранов. Чтобы избежать управления VPN-клиентом на каждом устройстве, я запускаю OpenVPN на своем сервере (10.0.1.252).

После подключения к VPN на сервер добавляются типичные статические маршруты, и я включил переадресацию и NAT, поэтому трафик от $ private_lan -> <vpn_netblocks> правильно NAT направляется по туннелю VPN (tun0). Мой DNS-рекурсор работает на этом сервере и знает, что нужно перенаправить определенные DNS-запросы на внутренние DNS-серверы. Все работает

Последний бит - информировать клиентов локальной сети о VPN. Их маршрут по умолчанию - AEBS (10.0.1.1). Это идеально, потому что у AEBS и кабельного модема есть собственная батарея, поэтому сеть не отключается через много часов после отключения питания. Чтобы клиенты ЛВС могли получить доступ к VPN, им необходимо изучить более конкретные маршруты, доступные на сервере. В Mac OS ручное добавление статических маршрутов работает следующим образом:

route add 10.7.0.0/16 10.0.1.252

Вопрос в том, как автоматически информировать устройства Mac и iOS об этих маршрутах. Я не могу добавить статические маршруты в AEBS (я был бы рад оказаться ошибочным!). Изменение маршрута IPv4 по умолчанию для указания на сервер - это мое последнее средство.

Я попытался добавить маршруты в dhcpd.conf как статические маршруты (код опции dhcp 121), как описано в RFC 3442. Вот соответствующие части моего dhcpd.conf:

# options for static routes
option rfc3442-classless-static-routes code 121 = array of integer 8;
option ms-classless-static-routes code 249 = array of integer 8;

subnet 10.0.1.0 netmask 255.255.255.0 {
      option rfc3442-classless-static-routes 16, 10,7, 10,0,1,252;
      option ms-classless-static-routes      16, 10,7, 10,0,1,252;
      # needed b/c this overrides option routers
      option rfc3442-classless-static-routes  0, 10,0,1,1;
      option ms-classless-static-routes       0, 10,0,1,1;
}

Опции обслуживаются dhcpd, но в Mac OS X они игнорируются. Есть:

  1. Какой-то другой вариант DHCP, который работает?
  2. Если я настрою OSPF или RIP, будет ли он "просто работать" для устройств Mac и iOS?
  3. Что-то вроде протокола обнаружения соседей для IPv4?

Указатели на документацию, которая, как известно, работает, высоко ценится.

Обновить

  1. Добавлен dhcpd.conf, показывающий мой конфиг
  2. Добавлена ссылка на обсуждение в Apple, ссылаясь на отсутствие поддержки RFC 3442

3 ответа3

0

Похоже, правильный ответ на вопрос: «Вы не можете».

Mac OS X (и iOS) не поддерживают RFC 3442, и хотя Mac OS X 10.10 по-прежнему содержит справочную страницу для маршрутизируемого, двоичный файл больше не присутствует.

Есть обходные пути.

  1. Чтобы проинформировать клиентов Mac OS X о более конкретных маршрутах, можно запустить демон маршрутизации в Mac OS X через пакет программного обеспечения, называемый quagga, который включает в себя ripd и ospfd, который затем может узнать маршруты OpenVPN от эквивалентных демонов на сервере ( разгромленный, квагга, зебра). Это много беспокоит, чтобы избежать # 2.

  2. Укажите маршрут по умолчанию IPv4 на сервере (а не на маршрутизаторе) и воспользуйтесь короткой арендой DHCP. Когда сервер недоступен, срок аренды DHCP быстро истекает, и устройства выбирают новую аренду из AEBS с самим собой в качестве шлюза по умолчанию.

(Да, у меня есть два DHCP-сервера в моей локальной сети, я делал это более десяти лет, dhcpd на сервере выигрывает, за исключением случаев, когда он выключен, то есть работает отлично).

0

Ad.1 Я не эксперт по OS X, но вы можете попробовать настроить опцию DHCP 249 (ms-classless-static-маршруты) следующим образом:

option ms-classless-static-routes 24, 192, 168, 16, 192, 168, 6, 1; 
24 - mask (number of bits)
192, 168, 16 - network address
192, 168, 6, 1 - gateway

Есть также опция DHCP 33 (одиночный маршрут): - https://ercpe.de/blog/advanced-dhcp-options-pushing-static-routes-to-clients

Одиночный маршрут

Пробиться по одному маршруту очень легко. Значение конфигурации состоит из двух пар IP-адресов в шестнадцатеричном формате. Первый адрес - хост назначения, второй - маршрутизатор.

Пример:

Destination: 192.168.123.234 (Hex: C0:A8:7B:EA)
Router: 10.34.72.42 (Hex: 0A:22:48:2A)

Значение: C0: A8: 7B: EA: 0A: 22: 48: 2A

Примечание: это конфигурация pfsense, чтобы использовать ее в dhcpd, вам нужно конвертировать шестнадцатеричное в десятичное.

Возможно, вы сделали какую-то ошибку, можете ли вы показать нам конфигурацию dhcpd?

Очень хорошее описание здесь: https://ercpe.de/blog/pushing-static-routes-with-isc-dhcp-server

Передача статических маршрутов вашим клиентам dhcp с помощью pfsense была сложной задачей, потому что вы должны указать информацию о сети и маршрутизаторе в виде необработанных шестнадцатеричных значений. Выполнить ту же задачу с сервером ISC DHCP проще. Прежде всего, мы должны объявить опцию dhcp в глобальной области видимости серверу:

option rfc3442-classless-static-routes code 121 = array of integer 8;
option ms-classless-static-routes code 249 = array of integer 8;

Вторая строка предназначена для клиентов Windows, поскольку MS решила использовать опцию dhcp 249 вместо существующих 121. Следующим шагом является объявление этих опций в нашем определении подсети:

 subnet 192.168.1.0 netmask 255.255.255.0 {
     ... other options ....
     option rfc3442-classless-static-routes 24, 192, 168, 123, 10, 10, 10, 1, 0, 192, 168, 1, 2;
     option ms-classless-static-routes 24, 192, 168, 123, 10, 10, 10, 1, 0, 192, 168, 1, ;
 }

Формат параметров:

<netmask>, <network-byte1>, <network-byte2>, <network-byte3>, <router-byte1>, <router-byte2>, <router-byte3>

где байты со значением 0 опущены. Опять же, вы должны включить маршрут по умолчанию в опции, потому что клиентам dhcp разрешено игнорировать опцию routers xxxx option. Таким образом, опция строки rfc3442-classless- static-маршруты 24, 192, 168, 123, 10, 10, 10, 1, 0, 192, 168, 1, 2 задает следующую информацию о маршрутизации:

24, 192, 168, 123, 10, 10, 10, 1: 192.168.123.0/24 via 10.10.10.1 0,
192, 168, 1, 2: 0.0.0.0 via 192.168.1.2 (default route)

Обязательно прочтите комментарии.

Есть также другой поток @ serverfault, который может быть полезен:

https://serverfault.com/questions/248821/does-the-os-x-dhcp-client-support-classless-static-routes-rfc3442

Еще одна вещь: вы знаете о опционе толчка OpenVPN? Вы можете проталкивать маршруты напрямую через сервер OpenVPN, добавив такую опцию:

push "route 192.168.16.0 255.255.255.0 192.168.6.1" 

Это означает передачу статического маршрута клиенту для сети 192.168.16.0 и маски 255.255.255.0 через 192.168.6.1.

0

Разве вы не можете просто установить шлюз по умолчанию ваших клиентов локальной сети, чтобы он указывал на сервер OpenVPN? Это уже маршрутизатор, который должен знать все правильные маршруты.

Я предполагаю, что это на вашей локальной сети, чтобы местные клиенты могли связаться с ней. Он будет знать, чтобы переслать материал в сеть OpenVPN. Он будет либо пересылать данные на ваш пограничный маршрутизатор, либо отправлять перенаправление ICMP для системы, пытающейся установить связь с Интернетом.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .