StrongSwan sender en DNS-adresse Macen ikke når

Alt virker til noen åpner en MacBook. Tunnelen etableres, interne verter svarer på adresse, og navneoppslaget dør. På iPhone oppfører samme profil seg likt, mens Windows- og Linux-klientene er i orden. Vanligvis er den pushede DNS-attributten skyldneren: serveren deler ut sin egen offentlige grensesnittadresse, og Apples IKEv2-klient sender ikke spørringer dit gjennom tunnelen. Flytt resolveren inn i poolen, og symptomet forsvinner uten å røre klienten.

Symptomet peker på den pushede adressen

Når bare noen plattformer feiler, er tunnelen og legitimasjonen nesten sikkert i orden, fordi de deles. Det som varierer, er hvordan hver klient bruker konfigurasjonsnyttelasten den mottar, inkludert den interne DNS-serveren. En klient som godtar adressen men ruter spørringene utenom tunnelen, ender med en resolver den ser og ikke kan bruke.

Den offentlige adressen er det vanlige valget fordi den er den eneste administratoren allerede kjenner. Den er også den eneste adressen som garantert ligger utenfor tunnelens eget prefiks, og nettopp den egenskapen ødelegger Apples klienter.

Se på verdien før du endrer noe. Hvis den pushede resolveren er serverens WAN-adresse, har du funnet problemets form og kan hoppe over resten av gjettingen. Sammenlign den også med poolens prefiks, for en adresse inne i poolen men utenfor leieområdet er nøyaktig hvordan rettelsen vil se ut. To minutter med konfigurasjonen slår en ettermiddag med pakkefangst på klienten.

Skjær resolveren ut av leieområdet

Gi tunnelen en adresseplan der resolveren er medlem av poolens eget subnett, og reserver deretter adressen slik at den aldri leies ut til en klient. I dette eksempelet er poolen 10.180.7.0/24, serveren holder 10.180.7.1, og leiene starter på 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Poolens prefiks og resolveren deler et subnett, så ruten som allerede bærer tunnelrafikk, bærer også spørringene. Nettopp den ene egenskapen gjør rettelsen flyttbar mellom klienter. I en swanctl-konfigurasjon vises de samme to fakta som en pooldefinisjon og en DNS-innstilling på tilkoblingen i stedet for i ipsec.conf-syntaks.

Serveren trenger ikke et nytt fysisk grensesnitt for dette. Å legge 10.180.7.1 til loopback-grensesnittet er nok til at en resolver kan binde og svare, siden klientene når den gjennom poolruten som allerede finnes. Hold adressen utenfor leieområdet slik at ingen klient tar den ved et uhell. Hvis poolen styres av en ekstern DHCP- eller RADIUS-tjeneste, reserver adressen der også, ellers tar den første klienten som spør den.

Bind resolveren og lukk port 53

Å tildele en adresse er ikke det samme som å lytte på den. En resolver som bare lytter på LAN-adressen, vil avvise eller ignorere spørringer sendt til pooladressen, og klienten ser en tidsavbrudd som ligner en rutingfeil.

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

Det unbound-fragmentet godtar spørringer fra tunnelpoolen og avviser alt annet, som er policyen de fleste bedriftsresolvere ønsker. Hvis samme instans også svarer LAN-klienter, legg til LAN-prefikset eksplisitt i stedet for å utvide lytteren til alle kilder.

Deretter må brannmurreglene stemme overens med resolverens egen tilgangskontroll. Godta port 53 fra poolen, og dropp den overalt ellers, men sjekk rekkefølgen i kjeden først.

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 godtakelsesregel gjør de to siste linjene dekorative, og resolveren forblir tilgjengelig fra internett. Les det effektive regelsettet med tellerne i stedet for å stole på rekkefølgen du mente. Den alternative policyen, å pushe den offentlige adressen og tillate spørringer fra enhver kilde, fungerer for mange klienter, men setter resolveren på internett og trenger sin egen hastighetsbegrensning og overvåking.

Bekreft hva klienten faktisk mottok

Sjekk serverens syn først, deretter klientens, fordi de to er uenige på opplysende måter. En poolliste viser hvilken adresse som ble leid ut, og listen over sikkerhetsassosiasjoner viser om tilkoblingen er oppe med den forventede identiteten.

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

Den direkte spørringen beviser at resolveren svarer på pooladressen fra en vert som kan nå den. Den beviser ikke at Macen valgte den serveren. På macOS lister scutil --dns resolvere per avgrenset tjeneste og er mer opplysende enn sammendragspanelet; på Windows viser Get-DnsClientServerAddress om tunneladapteren godtok den pushede verdien.

Hvis klienten viser pooladressen og spørringene fortsatt timer ut, er det tunnelruten eller brannmurkjeden som er skyld i det. En klient som ikke rapporterer noen resolver, betyr at konfigurasjonsnyttelasten aldri kom frem, så se på hvordan den plattformen bruker pushede innstillinger i stedet for på nettet. Skriv ned hvilken av de to sakene du observerte, før du endrer noe annet. De to feilene ser identiske ut i en støttebillett og fører til motsatte reparasjoner.