StrongSwan sendas DNS-adreson, kiun la Mac ne povas atingi

Ĉio funkcias ĝis iu malfermas MacBook-on. La tunelo establiĝas, internaj gastigantoj respondas laŭ adreso, kaj nomrezolucio mortas. Sur la iPhone la sama profilo kondutas same, dum la klientoj Windows kaj Linux estas bonaj. Kutime la kulpo estas la puŝita DNS-atributo: la servilo disdonas sian propran publikan interfacan adreson, kaj la IKEv2-kliento de Apple ne sendas demandojn tien tra la tunelo. Movu la solvilon en la pool-on, kaj la simptomo malaperas sen tuŝi la klienton.

La simptomo montras al la puŝita adreso

Kiam nur kelkaj platformoj malsukcesas, la tunelo kaj la akreditaĵoj preskaŭ certe estas bonaj, ĉar ili estas komunaj. Tio, kio malsamas, estas kiel ĉiu kliento aplikas la ricevitan agordan ŝarĝon, inkluzive de la interna DNS-servilo. Kliento, kiu akceptas la adreson sed direktas demandojn ĉirkaŭ la tunelo, finiĝas kun solvilo, kiun ĝi vidas kaj ne povas uzi.

La publika adreso estas la kutima elekto, ĉar ĝi estas la sola, kiun la administranto jam konas. Ĝi ankaŭ estas la sola adreso garantiite ekster la propra prefikso de la tunelo, kaj ĝuste tiu eco rompas la klientojn de Apple.

Rigardu la valoron antaŭ ol ŝanĝi ion ajn. Se la puŝita solvilo estas la WAN-adreso de la servilo, vi trovis la formon de la problemo kaj povas preterpasi la reston de la divenado. Komparu ĝin ankaŭ kun la pool-prefikso, ĉar adreso ene de la pool sed ekster la luata gamo estas ĝuste tio, kiel aspektos la riparo. Du minutoj kun la agordo superas posttagmezon da paketkaptado sur la kliento.

Eltranĉu la solvilon el la lua gamo

Donu al la tunelo adresplanon, en kiu la solvilo estas membro de la propra subreto de la pool, poste rezervu tiun adreson tiel, ke neniu kliento iam luos ĝin. En ĉi tiu ekzemplo la pool estas 10.180.7.0/24, la servilo tenas 10.180.7.1, kaj luoj komenciĝas ĉe 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

La pool-prefikso kaj la solvilo kunhavas subreton, do la itinero, kiu jam portas tunelan trafikon, portas ankaŭ la demandojn. Ĝuste tiu unu eco faras la riparon portebla inter klientoj. En swanctl-agordo la samaj du faktoj aperas kiel pool-difino kaj DNS-agordo sur la konekto anstataŭ en la sintakso de ipsec.conf.

La servilo ne bezonas novan fizikan interfacon por ĉi tio. Aldoni 10.180.7.1 al la loopback-interfaco sufiĉas por ke solvilo ligiĝu kaj respondu, ĉar klientoj atingas ĝin per la pool-itinero, kiu jam ekzistas. Tenu la adreson ekster la lua gamo, por ke neniu kliento hazarde postulu ĝin. Se la pool estas administrata de ekstera DHCP aŭ RADIUS-servo, rezervu la adreson ankaŭ tie, alie la unua kliento, kiu demandos, prenos ĝin.

Ligu la solvilon kaj fermu pordon 53

Asigni adreson ne samas kiel aŭskulti sur ĝi. Solvilo, kiu aŭskultas nur sur la LAN-adreso, rifuzos aŭ ignoros demandojn senditajn al la pool-adreso, kaj la kliento vidas tempolimon, kiu aspektas kiel itinera fiasko.

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

Tiu unbound-fragmento akceptas demandojn el la tunela pool kaj rifuzas ĉion alian, kio estas la politiko, kiun plej multaj entreprenaj solviloj volas. Se la sama instanco ankaŭ respondas al LAN-klientoj, aldonu la LAN-prefikson eksplice anstataŭ vastigi la aŭskultanton al ĉiuj fontoj.

La fajroŝirmilaj reguloj tiam devas kongrui kun la propra alirkontrolo de la solvilo. Akceptu pordon 53 el la pool, kaj forĵetu ĝin ĉie alie, sed unue kontrolu la ordon de la ĉeno.

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

Pli frua, pli vasta akcepta regulo faras la lastajn du liniojn dekoraciaj, kaj la solvilo restas atingebla el la interreto. Legu la efektivan regulskemon kun la nombriloj anstataŭ fidi la intencitan ordon. La alternativa politiko, puŝi la publikan adreson kaj permesi demandojn el ajna fonto, funkcias por multaj klientoj, sed metas la solvilon en la interreton kaj bezonas propran rapidolimigon kaj monitoradon.

Kontrolu, kion la kliento efektive ricevis

Kontrolu unue la vidpunkton de la servilo, poste tiun de la kliento, ĉar la du malkonsentas informplene. Pool-listo montras, kiu adreso estis luata, kaj la listo de sekurecaj asocioj montras, ĉu la konekto estas aktiva kun la atendata idento.

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

La rekta demando pruvas, ke la solvilo respondas sur la pool-adreso de gastiganto, kiu povas atingi ĝin. Ĝi ne pruvas, ke la Mac elektis tiun servilon. En macOS scutil --dns listigas solvilojn laŭ limigita servo kaj estas pli informa ol la resuma panelo; en Windows Get-DnsClientServerAddress montras, ĉu la tunela adaptilo akceptis la puŝitan valoron.

Se la kliento montras la pool-adreson kaj la demandoj ankoraŭ tempolimas, la tunela itinero aŭ la fajroŝirmila ĉeno estas kulpa. Kliento, kiu raportas neniun solvilon, signifas, ke la agorda ŝarĝo neniam alvenis, do rigardu kiel tiu platformo aplikas puŝitajn agordojn, ne la reton. Notu, kiun el la du kazoj vi observis, antaŭ ol ŝanĝi ion alian. Tiuj du fiaskoj aspektas idente en subtena bileto kaj kondukas al kontraŭaj riparoj.