StrongSwan Mac қол жеткізе алмайтын DNS мекенжайын жібереді

Барлығы біреу MacBook ашқанға дейін жұмыс істейді. Туннель орнатылады, ішкі хосттар мекенжай бойынша жауап береді, ал атауларды шешу өледі. iPhone-да сол профиль дәл осылай әрекет етеді, ал Windows және Linux клиенттері жақсы. Әдетте кінәлі — жіберілген DNS атрибуты: сервер өзінің жария интерфейс мекенжайын таратады, ал Apple-дың IKEv2 клиенті туннель арқылы ол жаққа сұраныс жібермейді. 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 конфигурациясында сол екі факт ipsec.conf синтаксисінде емес, пул анықтамасы мен қосылымдағы DNS параметрі ретінде көрінеді.

Серверге бұл үшін жаңа физикалық интерфейс қажет емес. 10.180.7.1-ді loopback интерфейсіне қосу resolver-дің байланып, жауап беруі үшін жеткілікті, өйткені клиенттер оған бұрыннан бар пул маршруты арқылы жетеді. Мекенжайды жалдау ауқымынан тыс ұстаңыз, сонда ешбір клиент оны абайсызда иемденбейді. Егер пулды сыртқы DHCP немесе RADIUS қызметі басқарса, мекенжайды сонда да қорыққа алыңыз, әйтпесе бірінші сұраған клиент оны алады.

Resolver-ді байланыстырып, 53 портын жабыңыз

Мекенжай тағайындау оған құлақ түрумен бірдей емес. Тек LAN мекенжайында тыңдайтын resolver пул мекенжайына жіберілген сұраныстарды қабылдамайды немесе елемейді, ал клиент маршруттау ақауына ұқсайтын таймаут көреді.

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 туралы хабарламайтын клиент конфигурация жүктемесі мүлде жетпегенін білдіреді, сондықтан желіге емес, сол платформаның жіберілген параметрлерді қалай қолданатынына қараңыз. Тағы бірдеңені өзгерту алдында осы екі жағдайдың қайсысын байқағаныңызды жазып қойыңыз. Бұл екі ақау қолдау билетінде бірдей көрінеді және қарама-қарсы жөндеулерге әкеледі.