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 показва дали тунелният адаптер е приел подадената стойност.

Ако клиентът показва адреса на пула, а заявките все още изтичат, вината е в маршрута на тунела или във веригата на защитната стена. Клиент, който не съобщава резолвер, означава, че конфигурационният полезен товар никога не е пристигнал, затова гледайте как тази платформа прилага подадените настройки, а не мрежата. Запишете кой от двата случая сте наблюдавали, преди да промените друго. Тези два отказа изглеждат еднакво в тикет за поддръжка и водят до противоположни поправки.