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 паказвае, ці прыняў тунельны адаптар перададзенае значэнне.

Калі кліент паказвае адрас пула, а запыты ўсё яшчэ сканчаюцца тайм-аўтам, вінаваты тунельны маршрут або ланцуг міжсеткавага экрана. Кліент, які не паведамляе ніводнага рэзалвера, азначае, што карысная нагрузка канфігурацыі так і не дайшла, таму глядзіце на тое, як гэтая платформа прымяняе перададзеныя налады, а не на сетку. Запішыце, які з двух выпадкаў вы назіралі, перш чым змяняць што-небудзь яшчэ. Гэтыя два збоі выглядаюць аднолькава ў тыкеце падтрымкі і вядуць да процілеглых рамонтаў.

Падобныя артыкулы