StrongSwan posiela DNS adresu, na ktorú sa Mac nedostane

Všetko funguje, kým niekto neotvorí MacBook. Tunel sa nadviaže, interné hosty odpovedajú na adresu a rozlišovanie mien zlyhá. Na iPhone sa ten istý profil správa rovnako, kým klienti Windows a Linux sú v poriadku. Zasielaný atribút DNS je zvyčajne vinníkom: server vydáva adresu vlastného verejného rozhrania a klient IKEv2 od Apple tam neposiela dopyty cez tunel. Presuňte resolver dovnútra fondu a príznak zmizne bez zásahu do klienta.

Príznak ukazuje na zasielanú adresu

Keď zlyhávajú len niektoré platformy, tunel a prihlasovacie údaje sú takmer isto v poriadku, pretože sú spoločné. Líši sa spôsob, akým každý klient aplikuje konfiguračnú záťaž, ktorú dostane, vrátane interného servera DNS. Klient, ktorý adresu prijme, ale dopyty obchádza mimo tunela, skončí s resolverom, ktorý vidí a nemôže použiť.

Verejná adresa je obvyklá voľba, pretože ju administrátor už pozná. Je to tiež jediná adresa zaručene mimo vlastného prefixu tunela, čo je presne vlastnosť, ktorá pokazí klientov Apple.

Pred akoukoľvek zmenou sa pozrite na hodnotu. Ak je zasielaný resolver adresa WAN servera, našli ste podobu problému a môžete preskočiť zvyšok hádania. Porovnajte ju aj s prefixom fondu, pretože adresa, ktorá leží vo fonde, ale mimo rozsahu prenájmu, presne zodpovedá tomu, ako bude oprava vyzerať. Dve minúty s konfiguráciou sú lepšie ako popoludnie zachytávania paketov na klientovi.

Vyčleňte resolver z rozsahu prenájmu

Dajte tunelu plán adries, v ktorom je resolver členom vlastnej podsiete fondu, a potom túto adresu rezervujte, aby ju žiadny klient nikdy nedostal do prenájmu. V tomto príklade je fond 10.180.7.0/24, server drží 10.180.7.1 a prenájmy začínajú na 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Prefix fondu a resolver zdieľajú podsiet, takže trasa, ktorá už prenáša tunelovú prevádzku, prenáša aj dopyty. Práve táto jediná vlastnosť robí opravu prenosnou medzi klientmi. V konfigurácii swanctl sa tie isté dve skutočnosti objavujú ako definícia fondu a nastavenie DNS na spojení, nie v syntaxi ipsec.conf.

Server na to nepotrebuje nové fyzické rozhranie. Pridanie 10.180.7.1 na slučkové rozhranie stačí, aby sa resolver pripútal a odpovedal, pretože klienti sa k nemu dostanú cez trasu fondu, ktorá už existuje. Držte adresu mimo rozsahu prenájmu, aby ju žiadny klient nemohol omylom získať. Ak fond spravuje externá služba DHCP alebo RADIUS, rezervujte adresu aj tam, inak si ju vezme prvý klient, ktorý požiada.

Pripútajte resolver a zatvorte port 53

Prideliť adresu nie je to isté ako na nej počúvať. Resolver, ktorý počúva len na adrese LAN, odmietne alebo ignoruje dopyty poslané na adresu fondu a klient vidí časový limit, ktorý vyzerá ako porucha smerovania.

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

Tento fragment unbound prijíma dopyty z tunelového fondu a odmieta všetko ostatné, čo je politika, ktorú chce väčšina firemných resolverov. Ak tá istá inštancia odpovedá aj klientom LAN, pridajte prefix LAN výslovne namiesto rozšírenia počúvania na všetky zdroje.

Pravidlá firewallu sa potom musia zhodovať s vlastnou kontrolou prístupu resolvera. Prijmite port 53 z fondu a zahoďte ho odkiaľkoľvek inde, ale najprv skontrolujte poradie reťazca.

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

Skoršie, širšie pravidlo prijatia robí tie posledné dva riadky ozdobnými a resolver zostáva dostupný z internetu. Čítajte efektívnu množinu pravidiel s počítadlami namiesto dôvery v zamýšľané poradie. Alternatívna politika, posielanie verejnej adresy a povolenie dopytov z akéhokoľvek zdroja, funguje pre mnohých klientov, ale stavia resolver na internet a potrebuje vlastné obmedzovanie rýchlosti a monitorovanie.

Overte, čo klient skutočne dostal

Najprv skontrolujte pohľad servera, potom klienta, pretože tieto dva sa nezhodujú poučným spôsobom. Výpis fondu ukazuje, ktorá adresa bola prenajatá, a výpis bezpečnostných asociácií ukazuje, či je spojenie nadviazané s očakávanou identitou.

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

Priama otázka dokazuje, že resolver odpovedá na adrese fondu z hostiteľa, ktorý sa k nej dostane. Nedokazuje, že Mac si vybral ten server. Na macOS vypisuje scutil --dns resolvery podľa rozsahových služieb a je informatívnejší než panel so súhrnom; na Windows Get-DnsClientServerAddress ukazuje, či tunelový adaptér prijal zasielanú hodnotu.

Ak klient zobrazuje adresu fondu a dopyty stále končia časovým limitom, na vine je tunelová trasa alebo reťazec firewallu. Klient, ktorý nehlási žiadny resolver, znamená, že konfiguračná záťaž nikdy nedorazila, preto sa pozerajte na to, ako daná platforma aplikuje zasielané nastavenia, a nie na sieť. Pred ďalšou zmenou si zapíšte, ktorý z tých dvoch javov ste pozorovali. Tie dve poruchy vyzerajú v tiketu podpory rovnako a vedú k protikladným opravám.