StrongSwan надсилає DNS-адресу, якої Mac не може дістатися

Mac або iPhone ігнорує адресу публічного резолвера, яку надсилає ваш сервер StrongSwan. Перенесіть резолвер у пул клієнтів і обмежте порт 53 ним.

Усе працює, доки хтось не відкриє 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 показує, чи тунельний адаптер прийняв надіслане значення.

Якщо клієнт показує адресу пулу, а запити все ще вичерпують час, винен тунельний маршрут або ланцюжок брандмауера. Клієнт, який не повідомляє жодного резолвера, означає, що навантаження конфігурації так і не дійшло, тож дивіться, як ця платформа застосовує надіслані налаштування, а не на мережу. Перш ніж змінювати щось інше, запишіть, який із двох випадків ви спостерігали. Ці дві несправності виглядають однаково в заявці підтримки й ведуть до протилежних виправлень.

Схожі статті