StrongSwan sender ei DNS-adresse Macen ikkje når

Alt verkar til nokon opnar ein MacBook. Tunnelen vert oppretta, interne vertar svarar på adresse, og namneoppslaget døyr. På iPhone oppfører same profil seg likt, medan Windows- og Linux-klientane er i orden. Vanlegvis er den pusja DNS-attributten skuldaren: tenaren deler ut si eiga offentlege grensesnittadresse, og Apples IKEv2-klient sender ikkje spørjingar dit gjennom tunnelen. Flytt resolveren inn i poolen, og symptomet forsvinn utan å røre klienten.

Symptomet peikar på den pusja adressa

Når berre nokre plattformer feilar, er tunnelen og legitimasjonen nesten sikkert i orden, fordi dei vert delte. Det som varierer, er korleis kvar klient nyttar konfigurasjonslasta han får, inkludert den interne DNS-tenaren. Ein klient som godtar adressa men ruter spørjingane utanom tunnelen, endar med ein resolver han ser og ikkje kan bruke.

Den offentlege adressa er det vanlege valet fordi ho er den einaste administratoren allereie kjenner. Ho er også den einaste adressa som garantert ligg utanfor tunnelen sitt eige prefiks, og nettopp den eigenskapen øydelegg Apples klientar.

Sjå på verdien før du endrar noko. Viss resolveren som vert pusja er WAN-adressa til tenaren, har du funne forma på problemet og kan hoppe over resten av gjettinga. Samanlikn han også med prefikset til poolen, for ei adresse inne i poolen men utanfor leigeområdet er nøyaktig korleis rettinga vil sjå ut. To minutt med konfigurasjonen slår ein ettermiddag med pakkefangst på klienten.

Skjer resolveren ut av leigeområdet

Gje tunnelen ein adresseplan der resolveren er medlem av poolen sitt eige subnett, og reserver deretter adressa slik at ho aldri vert leigd ut til ein klient. I dette dømet er poolen 10.180.7.0/24, tenaren held 10.180.7.1, og leigene startar på 10.180.7.2.

rightsourceip=10.180.7.2/24
rightdns=10.180.7.1

Prefikset til poolen og resolveren deler eit subnett, så ruta som allereie ber tunnelatrafikk, ber også spørjingane. Nettopp den eine eigenskapen gjer rettinga flyttbar mellom klientar. I ein swanctl-konfigurasjon viser dei same to fakta seg som ein pooldefinisjon og ei DNS-innstilling på tilkoblinga i staden for i ipsec.conf-syntaks.

Tenaren treng ikkje eit nytt fysisk grensesnitt for dette. Å leggje 10.180.7.1 til loopback-grensesnittet er nok for at ein resolver kan binde og svare, sidan klientane når han gjennom poolruta som allereie finst. Hald adressa utanfor leigeområdet slik at ingen klient tek henne ved eit uhell. Viss poolen vert styrt av ein ekstern DHCP- eller RADIUS-teneste, reserver adressa der også, elles tek den første klienten som spør henne.

Bind resolveren og lukk port 53

Å tildele ei adresse er ikkje det same som å lytte på henne. Ein resolver som berre lyttar på LAN-adressa, vil avvise eller ignorere spørjingar sende til pooladressa, og klienten ser ein tidsavbrot som liknar ein rutingsfeil.

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

Det unbound-fragmentet godtek spørjingar frå tunnelpoolen og avviser alt anna, som er politikken dei fleste bedriftsresolvarar ønskjer. Viss same instans også svarar LAN-klientar, legg til LAN-prefikset eksplisitt i staden for å utvide lyttaren til alle kjelder.

Deretter må brannmurreglane stemme overeins med resolveren si eiga tilgangskontroll. Godta port 53 frå poolen, og dropp han overalt elles, men sjekk rekkjefølgja i kjeda 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

Ein tidlegare, breiare godtakingsregel gjer dei to siste linjene dekorative, og resolveren held fram med å vere tilgjengeleg frå internett. Les det effektive regelsettet med teljarane i staden for å stole på rekkjefølgja du meinte. Den alternative politikken, å pushe den offentlege adressa og tillate spørjingar frå kvar kjelde, fungerer for mange klientar, men set resolveren på internett og treng si eiga fartsavgrensing og overvaking.

Stadfest kva klienten faktisk fekk

Sjekk synet til tenaren først, deretter klienten sitt, fordi dei to er usamde på opplysande måtar. Ei poolliste viser kva adresse som vart leigd ut, og lista over tryggleiksassosiasjonar viser om tilkoblinga er oppe med den venta identiteten.

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

Den direkte spørjinga bevisar at resolveren svarar på pooladressa frå ein vert som kan nå han. Ho bevisar ikkje at Macen valde den tenaren. På macOS listar scutil --dns resolverar per avgrensa teneste og er meir opplysande enn samandragspanelet; på Windows viser Get-DnsClientServerAddress om tunneladapteren godtok den pusja verdien.

Viss klienten viser pooladressa og spørjingane framleis timar ut, er det tunnelruta eller brannmurkjeda som er skuld i det. Ein klient som ikkje rapporterer nokon resolver, tyder på at konfigurasjonslasta aldri kom fram, så sjå på korleis den plattforma nyttar pusja innstillingar i staden for på nettet. Skriv ned kva av dei to sakene du såg, før du endrar noko anna. Dei to feila ser identiske ut i ein støttebillett og fører til motsette reparasjonar.