VPN подключение под MacOS и проблемы с маршрутизацией.
 

Здравствуйте.

Имеем домашнюю сеть с адресацией 192.168.0.0/24. Подключаемся с MacBookAir по VPN к локальной сети офиса с адресацией 192.168.0.0/24. В Mac OS в настройках VPN есть галочка "Отправить весь трафик через VPN", которая как мне казалось является прямым соответствием windows-формулировки "Использовать основной шлюз в удалённой сети". Эта галочка стоит в настройках подключения. При подключении в таблице маршрутизации клиента появляется ещё один шлюз по умолчанию идущий через сервер 192.168.2.1 (сеть для VPN клиентов 192.168.2.0/26).

Ресурсы офисной сети недоступны. Т.е. при пинге или другом обращении к сети 192.168.0.0/24 все запросы уходят через wi-fi адаптер в домашнюю сеть. Мне кажется что он не назначает шлюзом VPN соединение. Под виндой такая магия работает из коробки.

Из офисной сети MacBookAir пингуется по адресу 192.168.2.11.

Подскажите пожалуйста, что я упустил?

Так и есть. Помогает ли добавление маршрута вручную?

xandry, я не хочу добавлять маршрут вручную, мне нужно чтобы шлюз (192.168.2.1) VPN был шлюзом по-умолчанию. Но эта тачка выделывается и не хочет слать весь трафик в тунель.

Посмотрите, может пригодится...

И подсети разные вы, видимо, тоже делать не хотите? :)

Смотрел вчера - не то.

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

Как временное решение сделал проброс 3389 с 192.168.2.1 на терминальный сервер.

Какая-то странная логика работы маршрутизации в маках.

Обычный конфликт подсетей.
Не стоит использовать подсети 192.168.0-5.X/24 поскольку их часто все используют, сам ввожу VPN в организации и в половине офисов подсети 192.168.0.
Еще лучше имхо хотя знакомый админ раскритиковал(под предлогом что нагрузка на свичи и маршрутизаторы выше) использовать подсеть 10.X.X.X. Если взять какойнибудь 10.86.0.0/24 оочень мала вероятность в у когото дома или какой то WiFi в кафе такую подсеть уже использует.

А если вы с VPN подключением захотите воспользоваться локальными ресурсами, что тогда отключаться?

С настроенной маршрутизацией это не проблема. И что за нагрузка такая на свитчи и маршрутизаторы в подсети 192.168.0.x?

Да я тоже не в курсе, но коллега обьяснял это чтото вроде тем что свичи видят что подсеть другого класса и на обработку, и на обработку каждого IP адреса выделяется больше ресурсов.
Еще он оперировал такими словами как широкая и узкая труба, я всеже склоняюсь что маршрутизаторам реально пофиг на то какого класса подсеть и насколько велика маска, и если это и влияет на производительность то в такой малой степени что фаза луны в данный момент влияет сильней.

Tonny_Bennet,
странно, что эта "магия" работает на Windows - это нормальное поведение, MacOSX ведёт себя штатно - а именно ищет хост в своём сабнете через ARP.
скорее всего дело в "весе" маршрутов.
ну а вообще вам дали верный совет - 192.168.0.0/24 в офисной сети это гарантированные грабли со всякими другими интеграциями/миграциями/доверительными отношениями и nl/
вариант 192.168.xxx.0/24, где XXX что-то выше 100-200, причём не ровное - значительно практичней.
видимо речь идёт о едином броадкаст домене при /16 или /8 ;)

мда...

Я прекрасно понимаю, что метрика у двух маршрутов была разной (к слову в терминале по команде netstat -r метрику я не увидел), но вот почему МакОсь не ставит метрику маршруту default меньше (приоритетней) текущей по заветному флажку "Использовать основной шлюз в удалённой сети" для меня всё же осталось загадкой. Винда как-то справляется с этим.

Это первый случай, когда возникли подобные проблемы из-за одинаковой адресации.

Да, отключатся. Ну или настроить маршрутизацию так, чтобы работать и в локальной и в удалённых сетях. В большинстве случаев сотрудникам требуется поработать по RDP и всё. Остальным я открываю секреты мастерства route add.

Цитата:

Цитата kiralex Да я тоже не в курсе, но коллега обьяснял это чтото вроде тем что свичи видят что подсеть другого класса и на обработку, и на обработку каждого IP адреса выделяется больше ресурсов. Еще он оперировал такими словами как широкая и узкая труба, я всеже склоняюсь что маршрутизаторам реально пофиг на то какого класса подсеть и насколько велика маска, и если это и влияет на производительность

Если не затруднит: примеры в студию, пожалуйста.

:laugh: +1

В общем вы чего хотите?

https://developer.apple.com/library/...8/route.8.html

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

или CMAK.
или Option 249\121 на DHCP сервере, с которого VPN клиенты полуают адреса.
вот только с overlapped networks нужно разобраться, чтобы магии не было.

Я задавался вопросом: "Почему в винде так работает, а в маке нет?"

Пробовал. Не понравился.

Штука конечно интересная, но VPN-сервер-то под Ubuntu Server ;)

Вариант, наверное хороший. Но т.к. создаётся ptp подключение в конфиге сервера указан только диапазон клиентских адресов, и сервис pptpd контролирует только адреса клиентов. Адреса выдаются не dhcpd. Может в спецификации где-нибудь и есть возможность добавить Option, попробую поискать.

Из-за одного случая менять адресацию - лень. Немного волшебства ещё никому не мешало.

а что, у убунты свой PPTP\L2TP протокол? прямо таки с отдельным RFC?
IPSec - Да, CMAK не настроит.
вариант отличный, просто ваша реализация хромает и не допускает его использования. Хинт: локальный DHCP сервер, DHCP-Relay на нужный интерфейс и 67-68 UDP -> DROP на внутреннем ;)
ваше дело.
просто на будущее не совершайте таких ошибок.

можно вообще круто закостылить - поднимать VPN через rasdial, потом роутами играться, а всё это обернуть в красивый ярлычок для пользователя.
ах, чтобы совсем по феншую завернуть в MSI и красиво высылать по почте ;)

Сори, вчитался ещё раз. Думал это серверное решение, которое настраивает клиентское подключение. А это по сути модуль, создающий exe файл, который создаёт подключение и может прописывать маршрутизацию. Удобно.

Спасибо за наводку. Попробую на досуге.

Интересно что пользовать MacOS будет делать с MSI и где у него rasdial =)

Написать какойто автоматор или скрипт на баше реально возможно, но нужно обладать хотябы минимальными познаниями о шелкодинге в MacOS, да и черная это магия+)

Вообще DHCP в L2TP какбы не предусмотрен, что делает невозможным даже передать информацию о маршрутах. Както я читал статью что MPD5 под FreeBSD можно пропатчить поддержку DHCP, но я не уверен что это тот самый DHCP а не просто выдача адреса из пула DHCP. И всеже я гдето читал что MS Windows шлет запрос DHCP через туннель после установления связи.

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

DHCP это долеко не только выдавалка IP адресов.

Можно поподробнее о маршрутизации в относительно L2TP, только кросплатформенно без черной магии от Microsoft.
Я нашел только про маршрут мо умолчанию, а если мне ненадо заворачивать весь трафик а только в несколько подсетей?
http://tools.ietf.org/html/rfc5571#page-7

ну а это здесь причём? вы если уж дёргаете фразы из контекста, то сами хотя бы понимайте, откуда дёргаете.
задача ТС - выдавать маршруты VPN клиентам, независимо от ОС. Это можно сделать через DHCP сервер, вне зависимости от прокола туннелирования, через который подключается клиент.
какая маршрутизация относительно L2TP?... :swoon:
и причём тут магия Microsoft?
DHCP вам в помощь..