WireGuard-DNS på iPhone: domænet er kun et søgesuffiks

Du skriver én linje med en resolveradresse og et firmadomæne og forventer, at kun navne i det domæne bruger tunnelens resolver. På Apple-klienten går alle navne nu derhen, og korte navne i domænet slås også op. Linjen gør to separate ting, og kun én af dem handler om, hvilke forespørgsler tunnelen håndterer. Den anden er en skrivehjælp, der er blevet ophøjet til politik af ønsketænkning.

Hvad DNS-linjen opdeles i

Klienten læser posten som en liste og klassificerer hvert element efter form. Alt, der ligner en adresse, bliver en DNS-server; alt, der ligner et domæne, bliver et søgesuffiks. Begge ender i tunnelindstillingerne, men i forskellige felter. En illustrativ linje til en tunnel, der bærer en privat resolver og ét internt domæne, ser sådan ud.

DNS = 10.24.8.53, lab.internal.example

Adressen leverer resolveren. Domænet leverer et suffiks, der lader klienten skrive et kort navn og systemet tilføje resten, før der spørges. Ingen af delene siger noget om at begrænse resolveren til det domæne, og det er netop den del, folk forventer og ikke får. Kun ét felt på platformen kan udtrykke den begrænsning, og det er ikke dette felt.

To Apple-felter, to forskellige opgaver

Apple viser forskellen i sit DNS-indstillingsobjekt. Søgedomænelisten er dokumenteret som den liste, der bruges til at kvalificere værtsnavne med ét label: skriv et bart værtsnavn, og systemet kan tilføje hvert suffiks efter tur. Det er en fuldførelsesregel, ikke en routingregel. Intet på den liste afgør, hvilken server der spørges.

Matchdomænelisten er en anden egenskab. Den afgør, hvilke navnerum der bruger dette sæt DNS-indstillinger, og en tom post betyder standarddomænet snarere end et bestemt suffiks. generator for pakketunnelindstillinger på Apple-klienten følger den model. Den lægger parsede søgesuffikser i søgelisten, og når der er servere, sætter den matchlisten til den tomme streng. Resultatet er en tunnelresolver, der svarer på alt, hvad systemet sender den, plus et suffiks, der hjælper med korte navne.

Så et domæne på den linje er ikke en navnerumsvælger. At tilføje endnu et indsnævrer ikke, hvilke forespørgsler tunnelen bruger, og at fjerne det udvider dem heller ikke. Det eneste, der ændrer sig, er, hvor mange korte navne der fuldføres.

Hvorfor hvert navn stadig når tunnelresolveren

Med den tomme matchpost er tunnelen en kandidatresolver til almindelige navne, ikke kun til firmadomænet. I en fuldtunnelkonfiguration betyder det normalt lidt, fordi al trafik alligevel er i tunnelen. I en opdelt tunnel betyder det en hel del. Offentlige navne kan nu blive slået op af en resolver, der kun har en privat zone, og en fejl ligner en brudt VPN, når det i virkeligheden er en resolver, der kun svarer på en del af navnerummet. Tunnelen er fin, forespørgslerne forlader den, og svarene kommer tomme tilbage.

Der findes to reparationer, og de er forskellige beslutninger. Gør tunnelresolveren til en komplet resolver, der videresender offentlige navne ad den godkendte vej, eller hold op med at sende offentlige navne til den ved at ændre klientkonfigurationen i stedet for domænelisten. Den første holder hver forespørgsel på tunnelen og stoler på opstrømmen. Den anden holder nogle forespørgsler lokalt og accepterer, at private navne måske holder op med at slås op, mens tunnelen er nede.

Hvad opdelt DNS egentlig ville kræve

En resolverpolitik afgrænset til et navnerum kræver en klient, der lader dig udtrykke den: match domæner på Apple-platforme, eller en tilsvarende indstilling i det produkt, du bruger. Et konfigurationsfelt, der kun accepterer servere og suffikser, kan ikke udtrykke det, uanset hvordan det tegnsættes. En profil kan bære politikken, fordi den beskriver en administreret konfiguration i stedet for et hint ved forbindelsestidspunktet. Den kan navngive domænet, serverne og hvad der skal ske, når det domæne ikke kan nås. Det er forskellen mellem en indstilling og en kontrakt.

På administrerede Apple-enheder leveres det normalt via en konfigurationsprofil, der bærer de domænespecifikke DNS-indstillinger. Det er en anden mekanisme end en WireGuard-konfigurationsfil, og de to kan kun eksistere sammen, hvis klienten respekterer profilen. Tjek, hvad din klient egentlig kalder feltet, før du antager, at de to produkter opfører sig ens. Et script til wg-quick på en Mac og WireGuard-appen på en iPhone læser lignende linjer og installerer dem gennem forskellige lag.

Læs de installerede indstillinger, ikke konfigurationen

På en Mac kan du undersøge, hvad systemet endte med, og det er mere informativt end at læse filen, du skrev, igen. Resolverlisten viser, hvilke servere der er konfigureret til hvilke domæner, og de afgrænsede forespørgsler viser, hvilken der vandt. En klient, der ødelægger linjen, viser det her i stedet for i filen, du skrev. På iOS er der ingen tilsvarende kommandolinje, så beviset der er et resultat: et privat navn, der slås op gennem tunnelen, og et offentligt navn, hvis svar afslører, hvilken resolver der svarede.

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

Disse to kommandoer udskriver den aktuelle resolverkonfiguration og DNS-serverne for den aktive tjeneste. Hvis tunnelresolveren optræder som standardresolver uden domænebegrænsning, gør konfigurationen præcis det, klienten bad om. Ret det ved at ændre mekanismen, ikke ved at tilføje et andet suffiks og håbe på, at adfærden ændrer sig.