StrongSwan pošilja naslov DNS, ki ga Mac ne doseže

Vse deluje, dokler nekdo ne odpre MacBooka. Tunel se vzpostavi, notranji gostitelji odgovarjajo na naslov, razreševanje imen pa umre. Na iPhoneu se isti profil obnaša enako, medtem ko sta odjemalca Windows in Linux v redu. Poslani atribut DNS je običajno krivec: strežnik razdeli naslov svojega javnega vmesnika, odjemalec IKEv2 podjetja Apple pa poizvedb tja ne pošilja skozi tunel. Premaknite razreševalnik v bazen in simptom izgine brez posega v odjemalca.

Simptom kaže na poslani naslov

Ko odpovedo le nekatere platforme, sta tunel in poverilnice skoraj gotovo v redu, ker so skupne. Razlikuje se način, kako vsak odjemalec uporabi konfiguracijsko obremenitev, ki jo prejme, vključno z notranjim strežnikom DNS. Odjemalec, ki naslov sprejme, a poizvedbe usmerja mimo tunela, na koncu dobi razreševalnik, ki ga vidi in ga ne more uporabiti.

Javni naslov je običajna izbira, ker ga skrbnik že pozna. Je tudi edini naslov, zagotovljeno zunaj lastnega predpone tunela, kar je prav lastnost, ki pokvari odjemalce Apple.

Preden karkoli spremenite, poglejte vrednost. Če je poslani razreševalnik naslov WAN strežnika, ste našli obliko težave in lahko preskočite preostalo ugibanje. Primerjajte ga tudi s predpono bazena, ker je naslov, ki leži v bazenu, a zunaj obsega najema, natanko to, kako bo videti popravek. Dve minuti s konfiguracijo sta boljši od popoldneva zajemanja paketov na odjemalcu.

Izločite razreševalnik iz obsega najema

Tunelu dajte načrt naslovov, v katerem je razreševalnik član lastne podomrežja bazena, nato pa ta naslov rezervirajte, da ga noben odjemalec nikoli ne dobi v najem. V tem primeru je bazen 10.180.7.0/24, strežnik ima 10.180.7.1, najemi pa se začnejo pri 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Predpona bazena in razreševalnik si delita podomrežje, zato pot, ki že nosi tunelski promet, nosi tudi poizvedbe. Prav ta lastnost naredi popravek prenosljiv med odjemalci. V konfiguraciji swanctl se isti dve dejstvi pojavita kot definicija bazena in nastavitev DNS na povezavi, ne v sintaksi ipsec.conf.

Strežnik za to ne potrebuje novega fizičnega vmesnika. Dovolj je, da na povratni vmesnik dodate 10.180.7.1, da se razreševalnik veže in odgovarja, ker odjemalci do njega pridejo po poti bazena, ki že obstaja. Naslov držite zunaj obsega najema, da ga noben odjemalec ne more pomotoma dobiti. Če bazen upravlja zunanja storitev DHCP ali RADIUS, naslov rezervirajte tudi tam, sicer ga bo vzel prvi odjemalec, ki vpraša.

Vežite razreševalnik in zaprite vrata 53

Dodeliti naslov ni isto kot poslušati na njem. Razreševalnik, ki posluša le na naslovu LAN, zavrne ali prezre poizvedbe, poslane na naslov bazena, odjemalec pa vidi časovno prekoračitev, ki je videti kot okvara usmerjanja.

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

Ta delček unbound sprejema poizvedbe iz tunelskega bazena in vse drugo zavrača, kar je politika, ki jo želi večina poslovnih razreševalnikov. Če ista instanca odgovarja tudi odjemalcem LAN, dodajte predpono LAN izrecno, namesto da poslušanje razširite na vse vire.

Pravila požarnega zidu se morajo nato ujemati z lastno kontrolo dostopa razreševalnika. Sprejmite vrata 53 iz bazena in jih zavrzite od povsod drugod, a najprej preverite vrstni red verige.

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

Prejšnje, širše pravilo sprejemanja naredi zadnji dve vrstici okrasni in razreševalnik ostane dosegljiv z interneta. Berite učinkovit nabor pravil s števci, namesto da bi zaupali vrstnemu redu, ki ste ga nameravali. Alternativna politika, pošiljanje javnega naslova in dovoljenje poizvedb iz katerega koli vira, deluje pri mnogih odjemalcih, a postavi razreševalnik na internet in potrebuje lastno omejevanje hitrosti ter spremljanje.

Preverite, kaj je odjemalec res prejel

Najprej preverite pogled strežnika, nato odjemalca, ker se ta dva ne ujemata na poučen način. Seznam bazena pokaže, kateri naslov je bil najet, seznam varnostnih združenj pa, ali je povezava vzpostavljena s pričakovano identiteto.

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

Neposredna poizvedba dokaže, da razreševalnik odgovarja na naslovu bazena z gostitelja, ki ga doseže. Ne dokaže, da je Mac izbral ta strežnik. V macOS scutil --dns navaja razreševalnike po obsežnih storitvah in je bolj poučen od povzetka; v Windows Get-DnsClientServerAddress pokaže, ali je tunelski vmesnik sprejel poslano vrednost.

Če odjemalec kaže naslov bazena, poizvedbe pa še vedno potečejo, je kriva tunelska pot ali veriga požarnega zidu. Odjemalec, ki ne poroča nobenega razreševalnika, pomeni, da konfiguracijska obremenitev ni nikoli prispela, zato poglejte, kako ta platforma uporabi poslane nastavitve, in ne omrežja. Preden karkoli drugega spremenite, zapišite, katero od tistih dveh stvari ste opazili. Ti dve okvari sta v zahtevku za podporo videti enako in vodita v nasprotna popravka.