StrongSwan праќа DNS адреса до која Mac не може да стигне

Сѐ работи додека некој не отвори MacBook. Тунелот се воспоставува, внатрешните хостови одговараат по адреса, а резолуцијата на имиња умира. На iPhone истиот профил се однесува исто, додека клиентите на Windows и Linux се во ред. Обично виновник е пратениот DNS атрибут: серверот ја распределува сопствената јавна адреса на интерфејсот, а IKEv2 клиентот на Apple не праќа барања таму низ тунелот. Преместете го resolver-от внатре во пулот и симптомот исчезнува без допирање на клиентот.

Симптомот укажува на пратената адреса

Кога паѓаат само некои платформи, тунелот и акредитивите се речиси сигурно во ред, бидејќи тие се заеднички. Разликата е како секој клиент го применува добиениот конфигурациски товар, вклучувајќи го внатрешниот DNS сервер. Клиент што ја прифаќа адресата но ги насочува барањата околу тунелот останува со resolver што го гледа и не може да го користи.

Јавната адреса е вообичаениот избор зашто е единствената што администраторот веќе ја знае. Таа е и единствената адреса загарантирано надвор од сопствениот префикс на тунелот, и токму тоа својство ги крши клиентите на Apple.

Погледнете ја вредноста пред да смените нешто. Ако пратениот resolver е WAN адресата на серверот, ја најдовте формата на проблемот и можете да го прескокнете остатокот од погодувањето. Споредете ја и со префиксот на пулот, бидејќи адреса внатре во пулот но надвор од опсегот за изнајмување е точно тоа како ќе изгледа поправката. Две минути со конфигурацијата се подобри од попладне фаќање пакети на клиентот.

Исечете го resolver-от од опсегот за изнајмување

Дајте му на тунелот план за адреси каде resolver-от е член на сопствената подмрежа на пулот, потоа резервирајте ја таа адреса за никогаш да не биде изнајмена на клиент. Во овој пример пулот е 10.180.7.0/24, серверот држи 10.180.7.1, а изнајмувањата почнуваат на 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Префиксот на пулот и resolver-от делат подмрежа, па рутата што веќе носи тунелски сообраќај ги носи и барањата. Токму ова својство ја прави поправката пренослива меѓу клиентите. Во swanctl конфигурација истите два факти се појавуваат како дефиниција на пул и DNS поставка на врската, а не во синтаксата на ipsec.conf.

На серверот не му треба нов физички интерфејс за ова. Додавањето на 10.180.7.1 на loopback интерфејсот е доволно за resolver-от да се врзе и одговори, бидејќи клиентите го достигнуваат преку рутата на пулот што веќе постои. Држете ја адресата надвор од опсегот за изнајмување за ниеден клиент случајно да не ја заземе. Ако пулот го управува надворешна DHCP или RADIUS служба, резервирајте ја адресата и таму, инаку првиот клиент што ќе праша ќе ја земе.

Врзете го resolver-от и затворете го портот 53

Доделувањето адреса не е исто како слушање на неа. Resolver што слуша само на LAN адресата ќе одбие или игнорира барања пратени до адресата на пулот, а клиентот гледа тајмаут што изгледа како грешка во рутирањето.

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

Овој unbound фрагмент прифаќа барања од тунелскиот пул и одбива сѐ друго, што е политиката што ја сакаат повеќето корпоративни resolver-и. Ако истата инстанца одговара и на LAN клиенти, додајте го LAN префиксот експлицитно наместо да го проширите слушачот на сите извори.

Потоа правилата на огнениот ѕид мора да се согласат со сопствената контрола на пристап на resolver-от. Прифатете го портот 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

Претходно пошироко правило за прифаќање ги прави последните две линии декоративни, а resolver-от останува достапен од интернет. Читајте го ефективниот сет правила со бројачите наместо да му верувате на редоследот што сте го намерачиле. Алтернативната политика, да ја праќате јавната адреса и да дозволувате барања од кој било извор, работи за многу клиенти, но го става resolver-от на интернет и бара сопствено ограничување на брзината и надзор.

Проверете што всушност примил клиентот

Прво проверете го погледот на серверот, потоа на клиентот, бидејќи двете се разликуваат на поучен начин. Списокот на пулот покажува која адреса е изнајмена, а списокот на безбедносни асоцијации покажува дали врската е крената со очекуваниот идентитет.

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

Директното барање докажува дека resolver-от одговара на адресата на пулот од хост што може да стигне до неа. Тоа не докажува дека Mac го избрал токму тој сервер. На macOS scutil --dns ги наведува resolver-ите по ограничена служба и е поучен од панелот за резиме; на Windows Get-DnsClientServerAddress покажува дали тунелскиот адаптер ја прифатил пратената вредност.

Ако клиентот ја покажува адресата на пулот а барањата сѐ уште истекуваат, виновна е рутата на тунелот или синџирот на огнениот ѕид. Клиент што не пријавува никаков resolver значи дека конфигурацискиот товар никогаш не пристигнал, затоа гледајте како таа платформа ги применува пратените поставки, а не мрежата. Запишете кој од двата случаи сте го забележале пред да смените нешто друго. Овие две грешки изгледаат идентично во билет за поддршка и водат до спротивни поправки.