StrongSwan sender en DNS-adresse, som Mac'en ikke kan nå

Alt virker, indtil nogen åbner en MacBook. Tunnelen etableres, interne hosts svarer på adresse, og navneopløsningen dør. På iPhone opfører den samme profil sig på samme måde, mens Windows- og Linux-klienterne er fine. Det er normalt den pushede DNS-attribut, der er synderen: serveren uddeler sin egen offentlige interface-adresse, og Apples IKEv2-klient sender ikke forespørgsler derhen gennem tunnelen. Flyt resolveren ind i puljen, og symptomerne forsvinder uden at røre klienten.

Symptomet peger på den pushede adresse

Når kun nogle platforme fejler, er tunnelen og legitimationsoplysningerne næsten sikkert i orden, fordi de deles. Det, der varierer, er, hvordan hver klient anvender den konfigurationsnyttelast, den modtager, inklusive den interne DNS-server. En klient, der accepterer adressen, men sender forespørgsler uden om tunnelen, ender med en resolver, den kan se og ikke kan bruge.

Den offentlige adresse er det sædvanlige valg, fordi det er den, administratoren allerede kender. Det er også den ene adresse, der med garanti ligger uden for tunnelens eget præfiks, og netop den egenskab ødelægger Apples klienter.

Se på værdien, før du ændrer noget. Hvis den pushede resolver er serverens WAN-adresse, har du fundet problemets form og kan springe resten af gætteriet over. Sammenlign den også med puljens præfiks, for en adresse inde i puljen men uden for det udlejede område er præcis, hvordan rettelsen kommer til at se ud. To minutter med konfigurationen slår en eftermiddag med pakkeoptagelser på klienten.

Skær resolveren ud af lease-området

Giv tunnelen en adresseplan, hvor resolveren er medlem af puljens eget subnet, og reserver derefter den adresse, så den aldrig udlejes til en klient. I dette eksempel er puljen 10.180.7.0/24, serveren holder 10.180.7.1, og leases begynder ved 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Puljens præfiks og resolveren deler et subnet, så den rute, der allerede bærer tunnel-trafik, bærer også forespørgslerne. Netop den egenskab gør rettelsen flytbar på tværs af klienter. I en swanctl-konfiguration optræder de samme to fakta som en puljedefinition og en DNS-indstilling på forbindelsen i stedet for i ipsec.conf-syntaks.

Serveren behøver ikke en ny fysisk interface til dette. At tilføje 10.180.7.1 til loopback-interfacet er nok til, at en resolver kan binde og svare, da klienterne når den gennem puljens rute, som allerede findes. Hold adressen ude af lease-området, så ingen klient kan tage den ved et uheld. Hvis puljen styres af en ekstern DHCP- eller RADIUS-tjeneste, skal adressen reserveres der også, ellers tager den første klient, der spørger, den.

Bind resolveren og luk port 53

At tildele en adresse er ikke det samme som at lytte på den. En resolver, der kun lytter på LAN-adressen, vil afvise eller ignorere forespørgsler sendt til puljeadressen, og klienten ser en timeout, der ligner en routingfejl.

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

Det unbound-fragment accepterer forespørgsler fra tunnelpuljen og afviser alt andet, hvilket er den politik, de fleste virksomhedsresolvere ønsker. Hvis den samme instans også svarer LAN-klienter, skal LAN-præfikset tilføjes eksplicit i stedet for at udvide lytteren til alle kilder.

Firewall-reglerne skal derefter stemme overens med resolverens egen adgangskontrol. Accepter port 53 fra puljen, og drop den alle andre steder, men kontrollér først kædens rækkefølge.

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

En tidligere, bredere accept-regel gør de sidste to linjer dekorative, og resolveren forbliver tilgængelig fra internettet. Læs det effektive regelsæt med tællerne i stedet for at stole på den tilsigtede rækkefølge. Den alternative politik, at pushe den offentlige adresse og tillade forespørgsler fra enhver kilde, virker for mange klienter, men sætter resolveren på internettet og kræver sin egen hastighedsbegrænsning og overvågning.

Bekræft, hvad klienten faktisk modtog

Tjek først serverens syn, derefter klientens, fordi de to er uenige på oplysende måder. En puljeliste viser, hvilken adresse der blev udlejet, og listen over sikkerhedsassociationer viser, om forbindelsen er oppe med den forventede identitet.

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

Den direkte forespørgsel beviser, at resolveren svarer på puljeadressen fra en host, der kan nå den. Den beviser ikke, at Mac'en valgte den server. På macOS viser scutil --dns resolvere pr. scoped tjeneste og er mere oplysende end oversigtspanelet; på Windows viser Get-DnsClientServerAddress, om tunnel-adapteren accepterede den pushede værdi.

Hvis klienten viser puljeadressen, og forespørgslerne stadig timer ud, er det tunnelruten eller firewall-kæden, der er skyld i det. En klient, der ikke rapporterer nogen resolver, betyder, at konfigurationsnyttelasten aldrig landede, så se på, hvordan den platform anvender pushede indstillinger, i stedet for på netværket. Skriv ned, hvilket af de to tilfælde du observerede, før du ændrer noget andet. De to fejl ser identiske ud i en supportbillet og fører til modsatte reparationer.