VPN между площадками или удалённый доступ: что соединяет каждый
Один соединяет шлюзы, другой соединяет устройства. Сравните селекторы трафика с маршрутами, спланируйте адресацию, затем проверьте пересылку и политику с реального хоста.
Оба решения называются VPN и решают разные задачи. Туннель между площадками соединяет два шлюза, поэтому каждый хост за ними может достичь разрешённых адресов на другой стороне, ничего не устанавливая. Туннель удалённого доступа подключает отдельные устройства к сети, по одному клиенту за раз. Сравнение важно потому, что большинство ошибок развёртывания возникает из-за настройки одного решения в ожидании поведения другого, а симптомом обычно становится тайм-аут в сервисе, до которого туннель действительно дошёл.
Два решения, две границы
| Site-to-site | Remote access | |
|---|---|---|
| Endpoints | two gateways | a gateway and each client |
| Who configures | network owners | each user or an MDM |
| Scope of reach | whatever the gateways route | whatever the client is granted |
| Broadcast discovery | not carried | not carried |
Ни одно из решений не расширяет широковещательный домен LAN. Устройства на дальней стороне не появляются в локальном списке обнаружения, и ожидать этого — первое допущение, от которого нужно отказаться. Частные DNS-имена, которые вы намеренно публикуете, предсказуемее любого протокола обнаружения и переживают смену поставщика.
Возьмите 10.10.0.0/24 на одной площадке и 10.20.0.0/24 на другой. Шлюзу A нужен маршрут или селектор трафика, отправляющий префикс 10.20.0.0/24 в туннель, а шлюзу B нужно его зеркальное отражение. Затем хосты по обе стороны используют обычную IP-связность и никогда не узнают, что туннель существует. Эта невидимость и есть функция, и поэтому сбои выглядят как обычные сетевые ошибки, а не как ошибки туннеля.
На основе политики и на основе маршрута — это не один и тот же туннель
При развёртывании IPsec на основе политики согласованные селекторы трафика точно определяют, какие пары источника и назначения защищены. Если за одним шлюзом появляется новая подсеть и ни один селектор её не покрывает, туннель остаётся поднятым, а новая подсеть просто не передаётся. В решении на основе маршрута трафик принимает интерфейс, а решение принимает таблица маршрутизации, что делает добавление префикса изменением маршрута, а не повторным согласованием туннеля.
StrongSwan показывает оба представления напрямую, и читать их вместе — это способ понять, какую модель вы на самом деле развернули.
swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'Список селекторов, в котором отсутствует нужный вам префикс, объясняет сбой без какого-либо перехвата пакетов, а маршрут, указывающий на неправильный интерфейс, объясняет зеркальный сбой на обратном пути. Прочитайте оба, прежде чем что-либо пересогласовывать, потому что обновление ключа не добавит селектор, который вы никогда не настраивали.
Спланируйте адресацию до туннеля
Пересекающиеся диапазоны — это ошибка проектирования, которую нельзя исправить конфигурацией. Если обе площадки используют 192.168.1.0/24, у хоста, которому нужен 192.168.1.50, есть два кандидата и никакого способа выбрать. Туннель пройдёт аутентификацию, ассоциации безопасности установятся, а решение маршрутизации всё равно будет неверным или неоднозначным.
Выберите один из трёх честных вариантов: перенумеровать одну площадку, транслировать пересекающийся диапазон на шлюзе, чтобы каждая сторона видела отдельный префикс, или отказаться от прямой маршрутизации для этих хостов и опубликовать сервис иначе. У каждого есть цена, и первый обычно самый дешёвый на двухлетнем горизонте. Решите до того, как туннель появится, потому что потом изменение затронет каждое устройство со старым адресом.
Вопрос с MTU тоже решите заранее. Туннель уменьшает полезную нагрузку, и решение, полагающееся на фрагментацию, ведёт себя иначе, чем то, которое фиксирует MSS на шлюзах.
Пересылка и политика находятся вне туннеля
Шлюз должен быть готов пересылать пакеты между интерфейсом туннеля и интерфейсом LAN, и обоим направлениям нужна политика, разрешающая сервис. В Linux это две отдельные настройки, плюс правила брандмауэра, которые решают, разрешён ли пересылаемый поток вообще.
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPTПринимающий хост добавляет третий уровень: его собственный брандмауэр всё ещё должен принять клиента из удалённой подсети. Файловый сервер, разрешающий только свою локальную /24, отклонит пересылаемый трафик от 10.20.0.7, как бы здраво ни выглядел туннель, и это отклонение легко прочитать как сбой маршрутизации.
Проверяйте с хоста, а не со шлюза
Ping, отправленный самим шлюзом, может следовать другому адресу источника и другой политике, чем пересылаемый пользовательский трафик. Это делает его слабым тестом и иногда вводящим в заблуждение: он успешен, когда приложение сбоит, или сбоит, когда приложение работает.
ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/nullИспользуйте реальный хост, реальный адрес источника и реальный протокол, который использует приложение. Затем отдельно прочитайте обратный путь, потому что работающее прямое направление без обратного маршрута даёт тайм-аут, выглядящий так же, как заблокированный сервис.
Выбирайте решение по вопросу, на который отвечаете: вы соединяете сети или принимаете устройства? Всё остальное, включая то, какого поставщика вы настраиваете, следует из этого ответа.