StrongSwan šalje DNS adresu do koje Mac ne može doći

Sve radi dok neko ne otvori MacBook. Tunel se uspostavi, interni hostovi odgovaraju po adresi, a razrješavanje imena umre. Na iPhoneu se isti profil ponaša isto, dok su Windows i Linux klijenti u redu. Obično je kriv pushani DNS atribut: server dijeli vlastitu javnu adresu sučelja, a Appleov IKEv2 klijent ne šalje upite tamo kroz tunel. Premjestite resolver unutar poola i simptom nestaje bez diranja klijenta.

Simptom upućuje na pushanu adresu

Kad zakažu samo neke platforme, tunel i vjerodajnice su gotovo sigurno u redu jer su zajednički. Razlikuje se to kako svaki klijent primjenjuje primljeni konfiguracijski teret, uključujući interni DNS poslužitelj. Klijent koji prihvati adresu ali upite usmjeri oko tunela završi s resolverom koji vidi i ne može koristiti.

Javna adresa uobičajen je izbor jer je jedina koju administrator već zna. To je i jedina adresa zajamčeno izvan vlastitog prefiksa tunela, a upravo to svojstvo lomi Appleove klijente.

Pogledajte vrijednost prije nego što bilo što promijenite. Ako je pushani resolver WAN adresa poslužitelja, pronašli ste oblik problema i možete preskočiti ostatak nagađanja. Usporedite ga i s prefiksom poola, jer adresa unutar poola ali izvan zakupljenog raspona upravo je ono kako će popravak izgledati. Dvije minute s konfiguracijom bolje su od poslijepodneva hvatanja paketa na klijentu.

Izrežite resolver iz raspona najma

Dajte tunelu plan adresa u kojem je resolver član vlastite podmreže poola, zatim rezervirajte tu adresu da se nikad ne iznajmi klijentu. U ovom primjeru pool je 10.180.7.0/24, poslužitelj drži 10.180.7.1, a najam počinje na 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Prefiks poola i resolver dijele podmrežu, pa ruta koja već nosi tunelski promet nosi i upite. Upravo to jedno svojstvo čini popravak prenosivim među klijentima. U swanctl konfiguraciji iste dvije činjenice pojavljuju se kao definicija poola i DNS postavka na vezi, a ne u sintaksi ipsec.conf.

Poslužitelju za to ne treba novo fizičko sučelje. Dodavanje 10.180.7.1 na loopback sučelje dovoljno je da se resolver veže i odgovara, jer mu klijenti pristupaju kroz pool rutu koja već postoji. Držite adresu izvan raspona najma da je nijedan klijent ne zauzme slučajno. Ako poolom upravlja vanjska DHCP ili RADIUS usluga, rezervirajte adresu i tamo, inače će je uzeti prvi klijent koji pita.

Vežite resolver i zatvorite port 53

Dodijeliti adresu nije isto što i slušati na njoj. Resolver koji sluša samo na LAN adresi odbit će ili ignorirati upite poslane na pool adresu, a klijent vidi istek koji izgleda kao greška usmjeravanja.

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

Taj unbound fragment prihvaća upite iz tunelskog poola i odbija sve ostalo, što je politika koju želi većina korporativnih resolvera. Ako ista instanca odgovara i LAN klijentima, dodajte LAN prefiks izričito umjesto proširivanja slušača na sve izvore.

Firewall pravila zatim moraju odgovarati resolverovoj vlastitoj kontroli pristupa. Prihvatite port 53 iz poola i odbacite ga sa svih ostalih mjesta, ali prvo provjerite redoslijed lanca.

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

Ranije, šire pravilo prihvaćanja čini ta posljednja dva retka ukrasom, a resolver ostaje dostupan s interneta. Čitajte efektivni skup pravila s brojačima umjesto da vjerujete namjeravanom redoslijedu. Alternativna politika, slanje javne adrese i dopuštanje upita sa svakog izvora, radi za mnoge klijente, ali stavlja resolver na internet i traži vlastito ograničavanje brzine i nadzor.

Provjerite što je klijent stvarno primio

Prvo provjerite pogled poslužitelja, zatim klijenta, jer se njih dvoje informativno razilaze. Popis poola pokazuje koja je adresa iznajmljena, a popis sigurnosnih asocijacija pokazuje je li veza podignuta s očekivanim identitetom.

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

Izravni upit dokazuje da resolver odgovara na pool adresi s hosta koji do nje može doći. Ne dokazuje da je Mac odabrao taj poslužitelj. Na macOS-u scutil --dns navodi resolvere po obuhvaćenoj usluzi i informativniji je od sažetka; na Windowsu Get-DnsClientServerAddress pokazuje je li tunelski adapter prihvatio pushanu vrijednost.

Ako klijent prikazuje pool adresu a upiti i dalje istječu, kriva je tunelska ruta ili firewall lanac. Klijent koji ne prijavljuje nijedan resolver znači da konfiguracijski teret nikad nije stigao, pa gledajte kako ta platforma primjenjuje pushane postavke, a ne mrežu. Zapišite koji ste od ta dva slučaja vidjeli prije nego što išta drugo promijenite. Ta dva kvara izgledaju identično u ticketu za podršku i vode do suprotnih popravaka.