Nagpapadala ang StrongSwan ng DNS address na hindi maabot ng Mac

Gumagana ang lahat hanggang may magbukas ng MacBook. Nabubuo ang tunnel, sumasagot ang mga panloob na host sa pamamagitan ng address, at namamatay ang paglutas ng pangalan. Sa iPhone ganoon din ang ugali ng parehong profile, habang maayos ang mga kliyenteng Windows at Linux. Ang ipinapadalang katangian ng DNS ang karaniwang salarin: ibinibigay ng server ang address ng sarili nitong pampublikong interface, at hindi nagpapadala ng mga query doon ang IKEv2 client ng Apple sa pamamagitan ng tunnel. Ilipat ang resolver sa loob ng pool at mawawala ang sintomas nang hindi ginagalaw ang kliyente.

Itinuturo ng sintomas ang ipinapadalang address

Kapag iilan lang ang nabibigong platform, halos tiyak na maayos ang tunnel at ang mga kredensyal, dahil pinagsasaluhan ang mga iyon. Ang kaibahan ay kung paano inilalapat ng bawat kliyente ang natatanggap nitong configuration payload, kasama ang panloob na DNS server. Ang kliyenteng tumatanggap ng address pero inililigaw ang mga query sa labas ng tunnel ay nauuwi sa resolver na nakikita nito pero hindi magamit.

Ang pampublikong address ang karaniwang pinipili dahil iyon ang alam na ng administrator. Iyon din ang nag-iisang address na garantisadong nasa labas ng sariling prefix ng tunnel, at iyon mismo ang katangiang sumisira sa mga kliyente ng Apple.

Tingnan ang halaga bago magbago ng anuman. Kung ang ipinapadalang resolver ay ang WAN address ng server, natagpuan mo na ang hugis ng problema at malalampasan ang natitirang hula. Ihambing din ito sa prefix ng pool, dahil ang address na nasa loob ng pool pero labas ng saklaw ng lease ang eksaktong magiging hitsura ng pagtatama. Mas mabuti ang dalawang minuto sa configuration kaysa isang hapon ng paghuli ng packet sa kliyente.

Ihiwalay ang resolver mula sa saklaw ng lease

Bigyan ang tunnel ng plano ng address kung saan kasapi ang resolver ng sariling subnet ng pool, pagkatapos ireserba ang address na iyon para hindi ito maupahan ng kahit sinong kliyente. Sa halimbawang ito ang pool ay 10.180.7.0/24, hawak ng server ang 10.180.7.1, at nagsisimula ang mga lease sa 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Pinagsasaluhan ng prefix ng pool at ng resolver ang isang subnet, kaya ang rutang nagdadala na ng trapik ng tunnel ay nagdadala rin ng mga query. Ang nag-iisang katangiang iyon ang nagpapahiram ng pagtatama sa lahat ng kliyente. Sa isang configuration ng swanctl, ang parehong dalawang katotohanan ay lumilitaw bilang depinisyon ng pool at setting ng DNS sa koneksyon, hindi sa syntax ng ipsec.conf.

Hindi kailangan ng server ng bagong pisikal na interface para dito. Sapat ang pagdaragdag ng 10.180.7.1 sa loopback interface para makabigkis at makasagot ang resolver, dahil nakakarating ang mga kliyente dito sa rutang pool na umiiral na. Itago ang address sa labas ng saklaw ng lease para walang kliyenteng makakuha nito nang aksidente. Kung pinamamahalaan ang pool ng panlabas na serbisyong DHCP o RADIUS, ireserba rin ang address doon, kung hindi ay kukunin ito ng unang kliyenteng magtatanong.

Ibigkis ang resolver at isara ang port 53

Ang pagtatalaga ng address ay hindi katulad ng pakikinig dito. Ang resolver na nakikinig lamang sa LAN address ay tatanggi o babalewalain ang mga query na ipinadala sa pool address, at makikita ng kliyente ang timeout na mukhang pagkabigo ng routing.

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

Tinatanggap ng pragmentong unbound na iyon ang mga query mula sa tunnel pool at tinatanggihan ang lahat ng iba, na siyang patakarang gusto ng karamihan ng corporate resolver. Kung ang parehong instance ay sumasagot din sa mga kliyente ng LAN, idagdag nang tahasan ang LAN prefix sa halip na palawakin ang pakikinig sa lahat ng pinagmulan.

Kailangan nang sumang-ayon ng mga patakaran ng firewall sa sariling access control ng resolver. Tanggapin ang port 53 mula sa pool, at i-drop ito mula sa lahat ng ibang lugar, pero tingnan muna ang pagkakasunod-sunod ng chain.

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

Ang mas maaga at mas malawak na patakaran ng pagtanggap ay ginagawang pandekorasyon ang huling dalawang linya, at nananatiling maabot ang resolver mula sa internet. Basahin ang epektibong set ng patakaran kasama ang mga counter sa halip na magtiwala sa order na sinadya mo. Gumagana sa maraming kliyente ang alternatibong patakaran, ang ipadala ang pampublikong address at payagan ang mga query mula sa kahit anong pinagmulan, pero inilalagay nito ang resolver sa internet at nangangailangan ng sariling rate limiting at monitoring.

Tiyakin kung ano talaga ang natanggap ng kliyente

Tingnan muna ang pananaw ng server, pagkatapos ang sa kliyente, dahil nagkakaiba ang dalawa sa makabuluhang paraan. Ipinapakita ng listahan ng pool kung aling address ang naupahan, at ipinapakita ng listahan ng security association kung nakatayo ang koneksyon sa inaasahang pagkakakilanlan.

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

Pinatutunayan ng direktang query na sumasagot ang resolver sa pool address mula sa host na makakaabot dito. Hindi nito pinatutunayan na pinili ng Mac ang server na iyon. Sa macOS, inililista ng scutil --dns ang mga resolver bawat naka-scope na serbisyo at mas may impormasyon kaysa sa summary panel; sa Windows, ipinapakita ng Get-DnsClientServerAddress kung tinanggap ng tunnel adapter ang ipinadalang halaga.

Kung ipinapakita ng kliyente ang pool address at nagti-timeout pa rin ang mga query, ang ruta ng tunnel o ang chain ng firewall ang may diperensya. Ang kliyenteng walang iniuulat na resolver ay nangangahulugang hindi kailanman dumating ang configuration payload, kaya tingnan kung paano inilalapat ng platform na iyon ang ipinapadalang setting, hindi ang network. Isulat kung alin sa dalawang iyon ang naobserbahan mo bago magbago ng iba. Magkamukha ang dalawang pagkabigong iyon sa isang support ticket at kabaligtarang pagtatama ang patutunguhan.