StrongSwan stuur 'n DNS-adres wat die Mac nie kan bereik nie

Alles werk totdat iemand ’n MacBook oopmaak. Die tonnel kom staan, interne gashere antwoord per adres, en naamresolusie sterf. Op die iPhone gedra dieselfde profiel hom dieselfde, terwyl die Windows- en Linux-kliënte foutloos werk. Die gestuurde DNS-kenmerk is gewoonlik die skuldige: die bediener gee sy eie openbare koppelvlakadres uit, en Apple se IKEv2-kliënt stuur nie navrae daarheen deur die tonnel nie. Skuif die resolver in die poel in, en die simptoom verdwyn sonder om aan die kliënt te raak.

Die simptoom wys na die gestuurde adres

Wanneer net sommige platforms misluk, is die tonnel en die geloofsbriewe byna seker reg, want dié word gedeel. Wat verskil, is hoe elke kliënt die konfigurasielading toepas wat hy ontvang, insluitend die interne DNS-bediener. ’n Kliënt wat die adres aanvaar maar navrae om die tonnel heen stuur, beland met ’n resolver wat hy kan sien en nie kan gebruik nie.

Die openbare adres is die gewone keuse omdat dit die ene is wat die administrateur reeds ken. Dit is ook die enigste adres wat gewaarborg buite die tonnel se eie voorvoegsel lê, en dit is presies die eienskap wat die Apple-kliënte breek.

Kyk na die waarde voordat jy enigiets verander. As die gestuurde resolver die bediener se WAN-adres is, het jy die vorm van die probleem gevind en kan jy die res van die raaiery oorslaan. Vergelyk dit ook met die poelvoorvoegsel, want ’n adres binne die poel maar buite die toegewysde reeks is presies hoe die oplossing gaan lyk. Twee minute met die konfigurasie klop ’n middag pakketopnames op die kliënt.

Sny die resolver uit die toegewysde reeks

Gee die tonnel ’n adresplan waarin die resolver ’n lid van die poel se eie subnet is, en reserveer dan daardie adres sodat dit nooit aan ’n kliënt toegewys word nie. In hierdie voorbeeld is die poel 10.180.7.0/24, die bediener hou 10.180.7.1, en toewysings begin by 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Die poelvoorvoegsel en die resolver deel ’n subnet, so die roete wat reeds tonnelverkeer dra, dra ook die navrae. Daardie enkele eienskap maak die oplossing oordraagbaar oor kliënte heen. In ’n swanctl-konfigurasie verskyn dieselfde twee feite as ’n poeldefinisie en ’n DNS-instelling op die verbinding eerder as in ipsec.conf-sintaksis.

Die bediener het nie ’n nuwe fisiese koppelvlak hiervoor nodig nie. Om 10.180.7.1 by die loopback-koppelvlak te voeg, is genoeg vir ’n resolver om te bind en te antwoord, want kliënte bereik dit deur die poelroete wat al bestaan. Hou die adres buite die toewysingsreeks sodat geen kliënt dit per ongeluk kan opeis nie. As die poel deur ’n eksterne DHCP- of RADIUS-diens bestuur word, reserveer die adres ook daar, anders neem die eerste kliënt wat vra dit.

Bind die resolver en sluit poort 53

Om ’n adres toe te wys is nie dieselfde as om daarop te luister nie. ’n Resolver wat net op die LAN-adres luister, weier of ignoreer navrae wat na die poeladres gestuur word, en die kliënt sien ’n tydsverloop wat soos ’n roetefout lyk.

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

Daardie unbound-fragment aanvaar navrae van die tonnelpoel en weier alles anders, wat die beleid is wat die meeste korporatiewe resolvers wil hê. As dieselfde instansie ook LAN-kliënte antwoord, voeg die LAN-voorvoegsel eksplisiet by in plaas daarvan om die luisteraar na alle bronne te verbreed.

Firewall-reëls moet dan met die resolver se eie toegangsbeheer ooreenstem. Aanvaar poort 53 vanaf die poel, en verwerp dit van oral elders, maar kyk eers na die volgorde van die ketting.

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

’n Vroeëre, breër aanvaardingsreël maak daardie laaste twee reëls dekoratief, en die resolver bly van die internet af bereikbaar. Lees die effektiewe reëlstel met die tellers eerder as om die volgorde te vertrou wat jy bedoel het. Die alternatiewe beleid, om die openbare adres te stuur en navrae van enige bron toe te laat, werk vir baie kliënte, maar dit plaas die resolver op die internet en het sy eie tempo-aanpassing en monitering nodig.

Verifieer wat die kliënt werklik ontvang het

Kyk eers na die bediener se siening, dan na die kliënt s’n, want die twee stem nie op informatiewe maniere ooreen nie. ’n Poellys wys watter adres toegewys is, en die lys van sekuriteitsverenigings wys of die verbinding op is met die verwagte identiteit.

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

Die direkte navraag bewys die resolver antwoord op die poeladres vanaf ’n gasheer wat dit kan bereik. Dit bewys nie die Mac het daardie bediener gekies nie. Op macOS lys scutil --dns resolvers per omvatte diens en is meer informatie as die oorsigpaneel; op Windows wys Get-DnsClientServerAddress of die tonneladapter die gestuurde waarde aanvaar het.

As die kliënt die poeladres wys en navrae steeds tydsverloop, is die tonnelroete of die firewall-ketting skuld. ’n Kliënt wat geen resolver rapporteer nie, beteken die konfigurasielading het nooit geland nie, so kyk na hoe daardie platform gestuurde instellings toepas eerder as na die netwerk. Skryf neer watter van dié twee jy waargeneem het voordat jy enigiets anders verander. Daardie twee mislukkings lyk identies in ’n ondersteuningskaartjie en lei tot teenoorgestelde herstellings.