Показать полную графическую версию : VPN подключение под MacOS и проблемы с маршрутизацией.
Tonny_Bennet
25-09-2014, 14:54
Здравствуйте.
Имеем домашнюю сеть с адресацией 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.
Подскажите пожалуйста, что я упустил?
как мне казалось является прямым соответствием windows-формулировки "Использовать основной шлюз в удалённой сети" »
Так и есть. Помогает ли добавление маршрута вручную?
Tonny_Bennet
26-09-2014, 11:44
xandry, я не хочу добавлять маршрут вручную, мне нужно чтобы шлюз (192.168.2.1) VPN был шлюзом по-умолчанию. Но эта тачка выделывается и не хочет слать весь трафик в тунель.
я не хочу добавлять маршрут вручную »Посмотрите (http://habrahabr.ru/post/88946/), может пригодится...
И подсети разные вы, видимо, тоже делать не хотите? :)
Tonny_Bennet
26-09-2014, 12:11
Посмотрите, может пригодится... »
Смотрел вчера - не то.
И подсети разные вы, видимо, тоже делать не хотите? »
Я то сделаю разные подсети, а вот если 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 подключением захотите воспользоваться локальными ресурсами, что тогда отключаться?
А если вы с VPN подключением захотите воспользоваться локальными ресурсами, что тогда отключаться? »
С настроенной маршрутизацией это не проблема. И что за нагрузка такая на свитчи и маршрутизаторы в подсети 192.168.0.x?
И что за нагрузка такая на свитчи и маршрутизаторы в подсети 192.168.0.x? »
Да я тоже не в курсе, но коллега обьяснял это чтото вроде тем что свичи видят что подсеть другого класса и на обработку, и на обработку каждого IP адреса выделяется больше ресурсов.
Еще он оперировал такими словами как широкая и узкая труба, я всеже склоняюсь что маршрутизаторам реально пофиг на то какого класса подсеть и насколько велика маска, и если это и влияет на производительность то в такой малой степени что фаза луны в данный момент влияет сильней.
Tonny_Bennet,
странно, что эта "магия" работает на Windows - это нормальное поведение, MacOSX ведёт себя штатно - а именно ищет хост в своём сабнете через ARP.
скорее всего дело в "весе" маршрутов.
ну а вообще вам дали верный совет - 192.168.0.0/24 в офисной сети это гарантированные грабли со всякими другими интеграциями/миграциями/доверительными отношениями и nl/
вариант 192.168.xxx.0/24, где XXX что-то выше 100-200, причём не ровное - значительно практичней.
С настроенной маршрутизацией это не проблема. И что за нагрузка такая на свитчи и маршрутизаторы в подсети 192.168.0.x? »
видимо речь идёт о едином броадкаст домене при /16 или /8 ;)
но коллега обьяснял это чтото вроде тем что свичи видят что подсеть другого класса и на обработку, и на обработку каждого IP адреса выделяется больше ресурсов. »
мда...
Tonny_Bennet
01-10-2014, 13:01
Tonny_Bennet,
странно, что эта "магия" работает на Windows - это нормальное поведение, »
скорее всего дело в "весе" маршрутов. »
Я прекрасно понимаю, что метрика у двух маршрутов была разной (к слову в терминале по команде netstat -r метрику я не увидел), но вот почему МакОсь не ставит метрику маршруту default меньше (приоритетней) текущей по заветному флажку "Использовать основной шлюз в удалённой сети" для меня всё же осталось загадкой. Винда как-то справляется с этим.
Не стоит использовать подсети 192.168.0-5.X/24 поскольку их часто все используют, сам ввожу VPN в организации и в половине офисов подсети 192.168.0. »
Это первый случай, когда возникли подобные проблемы из-за одинаковой адресации.
А если вы с VPN подключением захотите воспользоваться локальными ресурсами, что тогда отключаться? »
Да, отключатся. Ну или настроить маршрутизацию так, чтобы работать и в локальной и в удалённых сетях. В большинстве случаев сотрудникам требуется поработать по RDP и всё. Остальным я открываю секреты мастерства route add.
Да я тоже не в курсе, но коллега обьяснял это чтото вроде тем что свичи видят что подсеть другого класса и на обработку, и на обработку каждого IP адреса выделяется больше ресурсов.
Еще он оперировал такими словами как широкая и узкая труба, я всеже склоняюсь что маршрутизаторам реально пофиг на то какого класса подсеть и насколько велика маска, и если это и влияет на производительность
Если не затруднит: примеры в студию, пожалуйста.
мда... »
:laugh: +1
В общем вы чего хотите?
https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man8/route.8.html
Чтобы работали удаленные ресурсы
route add %IP.VPN.SERVER%/32 gw 192.168.0.1
route delete default
route add default gw 192.168.2.1
все обратно
route delete default
route delete %IP.VPN.SERVER%/32
route add default gw 192.168.0.1
не вписывать ничего руками каждый раз когда подключаетесь? попробуйте OpenVPN.
попробуйте OpenVPN. »
или CMAK.
или Option 249\121 на DHCP сервере, с которого VPN клиенты полуают адреса.
вот только с overlapped networks нужно разобраться, чтобы магии не было.
Tonny_Bennet
03-10-2014, 13:53
В общем вы чего хотите? »
Я задавался вопросом: "Почему в винде так работает, а в маке нет?"
попробуйте OpenVPN. »
Пробовал. Не понравился.
или CMAK. »
Штука (http://habrahabr.ru/post/186674/) конечно интересная, но VPN-сервер-то под Ubuntu Server ;)
или Option 249\121 на DHCP сервере, с которого VPN клиенты полуают адреса. »
Вариант, наверное хороший. Но т.к. создаётся ptp подключение в конфиге сервера указан только диапазон клиентских адресов, и сервис pptpd контролирует только адреса клиентов. Адреса выдаются не dhcpd. Может в спецификации где-нибудь и есть возможность добавить Option, попробую поискать.
вот только с overlapped networks нужно разобраться, чтобы магии не было. »
Из-за одного случая менять адресацию - лень. Немного волшебства ещё никому не мешало.
Немного волшебства ещё никому не мешало. »А чем костыль со скриптом не понравился? Костыли это же тоже волшебно :)
Tonny_Bennet
03-10-2014, 15:00
Костыли это же тоже волшебно »
Маэстро не путайте волшебство и чёрную магию, ибо любой костыль порождение зла.
Штука конечно интересная, но VPN-сервер-то под Ubuntu Server »
а что, у убунты свой PPTP\L2TP протокол? прямо таки с отдельным RFC?
IPSec - Да, CMAK не настроит.
Вариант, наверное хороший. Но т.к. создаётся ptp подключение в конфиге сервера указан только диапазон клиентских адресов, и сервис pptpd контролирует только адреса клиентов. Адреса выдаются не dhcpd. Может в спецификации где-нибудь и есть возможность добавить Option, попробую поискать. »
вариант отличный, просто ваша реализация хромает и не допускает его использования. Хинт: локальный DHCP сервер, DHCP-Relay на нужный интерфейс и 67-68 UDP -> DROP на внутреннем ;)
Из-за одного случая менять адресацию - лень. »
ваше дело.
просто на будущее не совершайте таких ошибок.
не вписывать ничего руками каждый раз когда подключаетесь? »
А чем костыль со скриптом не понравился? »
можно вообще круто закостылить - поднимать VPN через rasdial, потом роутами играться, а всё это обернуть в красивый ярлычок для пользователя.
ах, чтобы совсем по феншую завернуть в MSI и красиво высылать по почте ;)
Tonny_Bennet
03-10-2014, 15:25
Штука конечно интересная, но VPN-сервер-то под Ubuntu Server »
а что, у убунты свой PPTP\L2TP протокол? прямо таки с отдельным RFC? »
Сори, вчитался ещё раз. Думал это серверное решение, которое настраивает клиентское подключение. А это по сути модуль, создающий exe файл, который создаёт подключение и может прописывать маршрутизацию. Удобно.
вариант отличный, просто ваша реализация хромает и не допускает его использования. Хинт: локальный DHCP сервер, DHCP-Relay на нужный интерфейс и 67-68 UDP -> DROP на внутреннем »
Спасибо за наводку. Попробую на досуге.
можно вообще круто закостылить - поднимать VPN через rasdial, потом роутами играться, а всё это обернуть в красивый ярлычок для пользователя.
ах, чтобы совсем по феншую завернуть в MSI и красиво высылать по почте »
Интересно что пользовать MacOS будет делать с MSI и где у него rasdial =)
Написать какойто автоматор или скрипт на баше реально возможно, но нужно обладать хотябы минимальными познаниями о шелкодинге в MacOS, да и черная это магия+)
Вообще DHCP в L2TP какбы не предусмотрен, что делает невозможным даже передать информацию о маршрутах. Както я читал статью что MPD5 под FreeBSD можно пропатчить поддержку DHCP, но я не уверен что это тот самый DHCP а не просто выдача адреса из пула DHCP. И всеже я гдето читал что MS Windows шлет запрос DHCP через туннель после установления связи.
Интересно что пользовать MacOS будет делать с MSI и где у него rasdial »
я не знакома с маками, поэтому не знаю, есть ли там средства автоматизации хотя бы таких моментов, поэтому не знаю.
Написать какойто автоматор или скрипт на баше реально возможно, но нужно обладать хотябы минимальными познаниями о шелкодинге в MacOS, да и черная это магия+) »
поэтому костыли есть зло, нужно обходиться без них.
Вообще DHCP в L2TP какбы не предусмотрен »
удивительно, да?
что делает невозможным даже передать информацию о маршрутах. »
а это что-то новое.
а не просто выдача адреса из пула DHCP. »
а бОльшего и не требуется.
И всеже я гдето читал что MS Windows шлет запрос DHCP через туннель после установления связи. »
не совсем так, но почти.
а бОльшего и не требуется. »
DHCP это долеко не только выдавалка IP адресов.
а это что-то новое. »
Можно поподробнее о маршрутизации в относительно L2TP, только кросплатформенно без черной магии от Microsoft.
Я нашел только про маршрут мо умолчанию, а если мне ненадо заворачивать весь трафик а только в несколько подсетей?
http://tools.ietf.org/html/rfc5571#page-7
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.