StrongSwan siunčia DNS adresą, kurio Mac nepasiekia

Viskas veikia, kol kas nors neatidaro MacBook. Tunelis užmezgamas, vidiniai mazgai atsako adresu, o vardų skyrimas miršta. iPhone tas pats profilis elgiasi taip pat, o Windows ir Linux klientai veikia gerai. Dažniausiai kaltas siunčiamas DNS atributas: serveris dalija savo viešą sąsajos adresą, o Apple IKEv2 klientas nesiunčia ten užklausų per tunelį. Perkelkite resolverį į baseino vidų ir simptomas išnyks nelietus kliento.

Simptomas nurodo siunčiamą adresą

Kai nepavyksta tik kai kurios platformos, tunelis ir kredencialai beveik neabejotinai tvarkingi, nes jie bendri. Skiriasi tai, kaip kiekvienas klientas taiko gautą konfigūracijos naudingąją apkrovą, įskaitant vidinį DNS serverį. Klientas, kuris priima adresą, bet užklausas nukreipia aplink tunelį, lieka su resolveriu, kurį mato ir negali naudoti.

Viešas adresas yra įprastas pasirinkimas, nes tai vienintelis, kurį administratorius jau žino. Tai taip pat vienintelis adresas, garantuotai esantis už paties tunelio prefikso, ir būtent ši savybė sugadina Apple klientus.

Pažiūrėkite į reikšmę prieš ką nors keisdami. Jei siunčiamas resolveris yra serverio WAN adresas, radote problemos formą ir galite praleisti likusius spėjimus. Palyginkite jį ir su baseino prefiksu, nes adresas baseino viduje, bet už nuomos diapazono, yra būtent tai, kaip atrodys pataisa. Dvi minutės su konfigūracija geriau nei popietė paketų gaudymo kliente.

Iškirpkite resolverį iš nuomos diapazono

Duokite tuneliui adresų planą, kuriame resolveris yra baseino pačio potinklio narys, tada rezervuokite tą adresą, kad jis niekada nebūtų išnuomotas jokiam klientui. Šiame pavyzdyje baseinas yra 10.180.7.0/24, serveris laiko 10.180.7.1, o nuomos prasideda nuo 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Baseino prefiksas ir resolveris dalijasi potinkliu, todėl maršrutas, kuris jau neša tunelio srautą, neša ir užklausas. Būtent ši viena savybė daro pataisą perkeliamą tarp klientų. swanctl konfigūracijoje tie patys du faktai pasirodo kaip baseino apibrėžimas ir DNS nustatymas ryšyje, o ne ipsec.conf sintaksėje.

Serveriui tam nereikia naujos fizinės sąsajos. 10.180.7.1 pridėjimas prie loopback sąsajos pakanka, kad resolveris prisirištų ir atsakytų, nes klientai pasiekia jį per jau egzistuojantį baseino maršrutą. Laikykite adresą už nuomos diapazono, kad joks klientas jo netyčia neužimtų. Jei baseiną valdo išorinė DHCP arba RADIUS tarnyba, rezervuokite adresą ir ten, kitaip jį paims pirmasis klientas, kuris paklaus.

Prisiriškite resolverį ir uždarykite 53 prievadą

Priskirti adresą nėra tas pats, kas juo klausytis. Resolveris, kuris klausosi tik LAN adreso, atmes arba nepaisys užklausų, siunčiamų į baseino adresą, o klientas mato laiko limitą, kuris atrodo kaip maršrutizavimo gedimas.

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

Šis unbound fragmentas priima užklausas iš tunelio baseino ir atmeta visa kita, kuri yra politika, kurios nori dauguma įmonės resolverių. Jei ta pati instancija atsako ir LAN klientams, aiškiai pridėkite LAN prefiksą, o ne plėskite klausytoją į visus šaltinius.

Tada ugniasienės taisyklės turi sutapti su paties resolverio prieigos kontrole. Priimkite 53 prievadą iš baseino ir atmeskite jį visur kitur, bet pirmiausia patikrinkite grandinės tvarką.

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

Ankstesnė platesnė priėmimo taisyklė paverčia paskutines dvi eilutes dekoracija, o resolveris lieka pasiekiamas iš interneto. Skatykite veiksmingą taisyklių rinkinį su skaitikliais, o ne pasikliaukite numatyta tvarka. Alternatyvi politika, siųsti viešą adresą ir leisti užklausas iš bet kurio šaltinio, veikia daugeliui klientų, bet pastato resolverį į internetą ir reikalauja savo spartos limito bei stebėjimo.

Patikrinkite, ką klientas iš tikrųjų gavo

Pirmiausia patikrinkite serverio vaizdą, tada kliento, nes abu informatyviai nesutaria. Baseino sąrašas rodo, kuris adresas buvo išnuomotas, o saugos asociacijų sąrašas rodo, ar ryšys pakeltas su tikėtinu tapatumu.

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

Tiesioginė užklausa įrodo, kad resolveris atsako baseino adresu iš mazgo, kuris gali jį pasiekti. Ji neįrodo, kad Mac pasirinko būtent tą serverį. macOS scutil --dns išvardija resolverius pagal apribotą paslaugą ir yra informatyvesnis už suvestinės skydelį; Windows Get-DnsClientServerAddress rodo, ar tunelio adapteris priėmė siunčiamą reikšmę.

Jei klientas rodo baseino adresą, o užklausos vis tiek baigiasi laiko limitu, kaltas tunelio maršrutas arba ugniasienės grandinė. Klientas, kuris nepraneša jokio resolverio, reiškia, kad konfigūracijos naudingoji apkrova niekada neatvyko, todėl žiūrėkite, kaip ta platforma taiko siunčiamus nustatymus, o ne į tinklą. Užsirašykite, kurį iš dviejų atvejų pastebėjote, prieš ką nors keisdami. Šie du gedimai pagalbos biliete atrodo vienodai ir veda prie priešingų taisymų.