StrongSwan отправляет DNS-адрес, до которого Mac не может добраться

Всё работает, пока кто-нибудь не откроет MacBook. Туннель поднимается, внутренние хосты отвечают по адресу, а разрешение имён умирает. На iPhone тот же профиль ведёт себя так же, тогда как клиенты Windows и Linux в порядке. Обычно виноват отправляемый атрибут DNS: сервер раздаёт свой собственный публичный адрес интерфейса, а клиент IKEv2 от Apple не отправляет туда запросы через туннель. Перенесите резолвер внутрь пула, и симптом исчезнет без вмешательства в клиент.

Симптом указывает на отправленный адрес

Когда сбоят только некоторые платформы, туннель и учётные данные почти наверняка в порядке, потому что они общие. Различается то, как каждый клиент применяет полученную полезную нагрузку конфигурации, включая внутренний DNS-сервер. Клиент, который принимает адрес, но направляет запросы в обход туннеля, остаётся с резолвером, который он видит и не может использовать.

Публичный адрес — обычный выбор, потому что это единственный адрес, который администратор уже знает. Это также единственный адрес, гарантированно находящийся вне собственного префикса туннеля, и именно это свойство ломает клиенты Apple.

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

Вырежьте резолвер из диапазона аренды

Дайте туннелю план адресов, в котором резолвер является членом собственной подсети пула, а затем зарезервируйте этот адрес, чтобы он никогда не выдавался ни одному клиенту. В этом примере пул — 10.180.7.0/24, сервер держит 10.180.7.1, а аренды начинаются с 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Префикс пула и резолвер используют одну подсеть, поэтому маршрут, который уже несёт трафик туннеля, несёт и запросы. Именно это единственное свойство делает исправление переносимым между клиентами. В конфигурации swanctl те же два факта выглядят как определение пула и настройка DNS на соединении, а не в синтаксисе ipsec.conf.

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

Привяжите резолвер и закройте порт 53

Назначить адрес — не то же самое, что слушать на нём. Резолвер, который слушает только на адресе LAN, откажет или проигнорирует запросы, отправленные на адрес пула, и клиент увидит тайм-аут, похожий на сбой маршрутизации.

interface: 10.180.7.1
access-control: 10.180.7.0/24 allow
access-control: 0.0.0.0/0 refuse

Этот фрагмент unbound принимает запросы из пула туннеля и отклоняет всё остальное — это политика, которую хотят большинство корпоративных резолверов. Если тот же экземпляр отвечает и клиентам LAN, добавьте префикс LAN явно, вместо того чтобы расширять слушателя на все источники.

Затем правила брандмауэра должны согласовываться с собственной политикой доступа резолвера. Принимайте порт 53 из пула и отбрасывайте его везде остальном, но сначала проверьте порядок цепочки.

iptables -A INPUT -p udp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -s 10.180.7.0/24 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
iptables -A INPUT -p tcp --dport 53 -j DROP

Более раннее и широкое правило приёма делает последние две строки декоративными, и резолвер остаётся доступным из интернета. Читайте действующий набор правил вместе со счётчиками, а не доверяйте задуманному порядку. Альтернативная политика — отправлять публичный адрес и разрешать запросы из любого источника — работает для многих клиентов, но выставляет резолвер в интернет и требует собственного ограничения скорости и мониторинга.

Проверьте, что клиент действительно получил

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

swanctl --list-sas
swanctl --list-pools
dig +short @10.180.7.1 intranet.plant.example

Прямой запрос доказывает, что резолвер отвечает на адресе пула с хоста, который может до него добраться. Он не доказывает, что Mac выбрал именно этот сервер. В macOS scutil --dns перечисляет резолверы по службам с областью действия и информативнее панели сводки; в Windows Get-DnsClientServerAddress показывает, принял ли туннельный адаптер отправленное значение.

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