Я не читал всю ветку, но если подсеть вашего VPN уже отличается от подсети вашей локальной сети (а так и должно быть!), попробуйте изменить порядок приоритета сетевых подключений в OS X так, чтобы VPN-соединение было первым (с самым высоким приоритетом). Неважно, включена у вас опция «Отправлять весь трафик через VPN» или нет.

Спасибо, это решение. Я правда не понимаю, почему Unifi не позволяют настроить этот очень важный параметр прямо в контроллере.

Листал эту ветку в поисках решения, потому что у меня была такая же проблема. Оказалось, что моя сеть использовала тот же CIDR-диапазон, что и моя домашняя сеть, и опция «Отправлять весь трафик через VPN» не распространяется на локальный сетевой диапазон. То есть и локальная, и удалённая сети были 192.168.1.0/24, поэтому любые запросы к 192.168.1.x направлялись в локальную сеть.

В этом обсуждении затрагивается несколько разных вопросов. Я работаю на Mac, и все, о чём говорю, касается именно OS X/macOS.

Прежде всего, надо понимать, что Unifi по умолчанию создаёт VPN-соединение в подсети, отличной от удалённой сети… и я не нашёл способа изменить это.

Я работаю только с L2TP VPN, так как именно этот тип у меня лучше всего показал себя по простоте настройки и стабильности (он всегда работает на OS X/macOS и iOS без каких-либо заморочек). Есть три возможных типа настройки VPN для удалённого клиента.

Сценарий 1) Это стандартная конфигурация, которую создаёт Unifi. Я не указываю публичные IP или FQDN, так как они не важны для обсуждения поведения при удалённом подключении, но надо знать следующие моменты:

- Удалённая сеть — диапазон 192.168.1.0/24,
- VPN создаётся в диапазоне 172.26.0.0/24,
- Моя локальная сеть — 10.0.0.0/24.

Для наглядности я использую три очень разные частные подсети. Мой MacBook Pro подключён к локальной сети и получил IP 10.0.0.6, шлюз — 10.0.0.1. Я подключаюсь встроенным VPN-клиентом macOS с обычной L2TP-конфигурацией к удалённой сети и получаю в VPN IP 172.26.0.6. В этом примере mDNS и протоколы автодетекта удалённой сети 192.168.1.0/24 не пробрасываются через VPN, поэтому я не вижу автоматически принтеры, серверы и другие сервисы, которые сообщают о себе в удалённой сети. Если хочу пинговать или подключиться к устройству, надо указывать IP, если, конечно, нет DNS-сервера/сервиса, сконфигурированного с разделением зон (Views в Bind), который отвечает по-разному в зависимости от того, откуда идут запросы — из VPN, локалки или из внешней сети.

Это значит, что для простых операций нужно знать IP-адреса, но если настроить VPN так, чтобы маршрутизировать трафик только на удалённую сеть, а остальной интернет- трафик отправлять через локальный шлюз — всё работает. Например: если добавлю удалённый принтер по IP и буду на него печатать — будет работать, как и печать на локальные принтеры, и просмотр сайтов (например, www.apple.com) пойдёт через локальный интернет, а не через VPN. В моём VPN-клиенте есть опция «Route all traffic through the VPN» («Маршрутизировать весь трафик через VPN»), и я ставлю её только когда это действительно нужно. В остальном трафик делится: через VPN идут только вызовы к сети 192.168.1.0/24.

Это стандартная конфигурация Unifi VPN клиента… но иногда возникает проблема, как в следующем сценарии.

Сценарий 2) Часто подчас локальная и удалённая сети имеют одинаковый диапазон — большинство провайдеров и операторы используют для роутеров диапазон 192.168.1.0/24. В этом случае сети выглядят так:

- Удалённая сеть — 192.168.1.0/24,
- VPN — 172.26.0.0/24,
- Локальная сеть — 192.168.1.0/24.

Я по-прежнему получаю VPN IP 172.26.0.6, но, как вы можете представить, проблема в том, что локальная и удалённая подсети совпадают, и если не поставить галочку «Route all traffic through the VPN», поведение некорректное — компьютер не понимает, нужно ли направлять трафик к 192.168.1.0/24 через локальный шлюз или через VPN.

Единственное решение, которое я нашёл — ставить эту галочку и маршрутизировать весь трафик через VPN. Но тогда теряется возможность пользоваться локальными принтерами и серверами. Поэтому, когда я настраиваю новую сеть, моя практика — использовать отличающийся от 192.168.1.0/24 диапазон адресов, чтобы избежать таких конфликтов. Конечно, я поступаю так же и со своей локальной сетью. Например, моя локалка — 192.168.0.0/24, а у клиентов — 192.168.10.0/24. Если у клиента несколько филиалов, каждому выделяю свой диапазон: офис 1 — 192.168.11.0/24, офис 2 — 192.168.12.0/24, офис 3 — 192.168.13.0/24 и так далее.

Что же касается большинства комментариев в этой ветке, то хотелось бы сделать следующее.

Сценарий 3) Хочется получить VPN IP в диапазоне удалённой сети, чтобы выглядеть там как локальная машина. Это выглядело бы так:

- Удалённая сеть — 192.168.1.0/24,
- VPN IP — в диапазоне 192.168.1.0, назначенный из пула удалённого DHCP-сервера или из выделенного подсета, не конфликтующего с DHCP, но находящегося в том же диапазоне.
- Локальная сеть — 10.0.0.0/24 (если локальная сеть будет тоже 192.168.1.0/24 — это очень плохо, так как могут возникать конфликты IP, даже с самим собой).

В этом случае мы бы сразу видели все протоколы автодетекта и могли бы настраивать и подключаться к любым устройствам/сервисам удалённой сети, как будто мы там физически. Я не смог воспроизвести такую настройку в Unifi без правки config.gateway.json, при этом система уходила в перезагрузочный цикл или велась странно — совсем не то, что я хотел. Уверен, это моя ошибка, и способ должен быть, но было бы здорово, если бы в GUI появилась опция такой конфигурации удалённого клиента VPN.

Выводы:

а) Не создавайте новые сети с диапазоном по умолчанию 192.168.1.0/24 — это может вызвать проблемы, так как часто вы не контролируете локальную сеть, из которой подключаетесь (публичный Wi-Fi, дом друзей и так далее).

б) Чаще всего самая безопасная настройка VPN клиента — включать «Route all traffic through the VPN», даже если это не то, чего вы хотите.

в) Если вы контролируете DNS-сервер удалённой сети, используйте Views в Bind, чтобы настроить «локальные удалённые сервисы» с FQDN-записями, и настройте клиент VPN, чтобы он обращался именно к этому DNS-серверу — тогда не нужно знать IP каждого устройства.

г) Поведение галочки «Route all traffic through the VPN» отличается между macOS/OS X и iOS. Пока не понимаю, почему — продолжаю разбираться.

Это мой ограниченный опыт настройки L2TP VPN клиента Unifi. Если кто-то может пролить свет на этот вопрос — буду рад услышать.

Я совсем новичок в Ubiquiti и много учусь, вообще разбираюсь в сетях.

Много лет я использовал модемы/роутеры Billion для подключения офиса и дома. Сейчас, прочитав эту тему, понимаю, что они, видимо, делали какие-то внутренние «танцы с бубном», чтобы их VPN работали так просто и гладко.

Billion Remote access VPN сервер выдавал IP-адрес из локального диапазона подсети. Когда я подключался удалённо, всё просто работало, как ожидалось: удалённый рабочий стол, VNC, печать — всё было доступно в удалённой сети, если использовать IP нужного устройства. Я при этом продолжал использовать интернет-соединение моего локального роутера для веб-серфинга, скачивания и т.д., так что скорость всегда была нормальной.

Site-to-site IPSec VPN было легко настроить, если обе стороны были в разных подсетях.

С тех пор как я перешёл на USG, заметил, что на iOS и Mac нужно включать опцию «Route all traffic over VPN», чтобы иметь доступ к удалённым устройствам. Теперь получить доступ к удалённым устройствам можно, но интернет-соединение сильно тормозит, ведь, видимо, весь трафик идёт через подключение с удалённой стороны.

Мои потребности в VPN простые: зайти, подключиться через удалённый рабочий стол к нескольким ПК, напечатать на удалённом принтере, изменить настройки на устройствах. Было бы здорово при этом продолжать пользоваться местным интернетом, потому что он куда быстрее, чем интернет на некоторых удалённых объектах.

Было бы классно, если бы в графическом интерфейсе появилась опция, позволяющая не включать полную пересылку трафика (функцию «Send all traffic») на клиенте, может, такая возможность появится в будущих обновлениях.

Мне очень нравится настройка UniFi, там намного больше возможностей, чем у того, что у меня было раньше, и я доволен активным развитием и внедрением новых функций, но, к сожалению, это сопровождается определёнными сложностями в удобстве использования и настройке.

Посмотри правила входящего трафика на фаерволе. В Windows 2008 по умолчанию блокируется ICMP, и, возможно, когда ты пытался его отключить, он на самом деле не выключился. Windows любит решать за тебя, что лучше, и во время обновлений может снова включать эти настройки.

Итак, пакеты доходят, и VPN/маршрутизация работают. На этом этапе вы имеете дело с проблемой на стороне системы. В таких случаях это почти всегда брандмауэр. Какая у вас операционная система?

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