StrongSwan шаље DNS адресу коју Mac не може да достигне

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

Симптом указује на адресу која се шаље

Када само неке платформе не раде, тунел и акредитиви су готово сигурно у реду, јер су заједнички. Оно што се разликује јесте како сваки клијент примењује конфигурациони терет који прима, укључујући интерни 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 префикс експлицитно уместо да проширите слушање на све изворе.

Затим се firewall правила морају слагати са контролом приступа самог резолвера. Прихватите порт 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 показује да ли је тунелски адаптер прихватио послату вредност.

Ако клијент приказује адресу пула а упити и даље истичу, тунелска рута или ланац firewall-а је у квару. Клијент који не пријављује ниједан резолвер значи да конфигурациони терет никада није стигао, па гледајте како та платформа примењује послата подешавања, а не мрежу. Запишите коју од те две ствари сте приметили пре него што било шта друго промените. Та два квара изгледају идентично у тикету подршке и воде ка супротним поправкама.