WireGuard-DNS på iPhone: domenet er bare et søkesuffiks

Du skriver én linje med en resolveradresse og et firmadomene, og forventer at bare navn i det domenet bruker tunnelresolveren. På Apple-klienten går alle navn nå dit, og korte navn i domenet løses også. Linjen gjør to separate ting, og bare én av dem handler om hvilke spørringer tunnelen håndterer. Den andre er en skrivehjelp som er blitt opphøyet til policy av ønsketenkning.

Hva DNS-linjen parses til

Klienten leser oppføringen som en liste og klassifiserer hvert element etter form. Alt som ser ut som en adresse, blir en DNS-server; alt som ser ut som et domene, blir et søkesuffiks. Begge ender i tunnelinnstillingene, men i forskjellige felt. En illustrerende linje for en tunnel som bærer en privat resolver og ett internt domene, ser slik ut.

DNS = 10.24.8.53, lab.internal.example

Adressen leverer resolveren. Domenet leverer et suffiks som lar klienten skrive et kort navn og systemet legge til resten før det spør. Ingen av delene sier noe om å begrense resolveren til det domenet, og det er nettopp den delen folk forventer og ikke får. Bare ett felt på plattformen kan uttrykke den begrensningen, og det er ikke dette feltet.

To Apple-felt, to forskjellige jobber

Apple viser forskjellen i DNS-innstillingsobjektet sitt. Søkedomenelisten er dokumentert som listen som brukes til å kvalifisere vertsnavn med én etikett: skriv et bart vertsnavn, og systemet kan legge til hvert suffiks etter tur. Det er en fullføringsregel, ikke en rutingregel. Ingenting på den listen avgjør hvilken server som spørres.

Samsvarsdomenelisten er en annen egenskap. Den avgjør hvilke navnerom som bruker dette settet med DNS-innstillinger, og en tom oppføring betyr standarddomenet snarere enn ett bestemt suffiks. generator for pakketunnelinnstillinger på Apple-klienten følger den modellen. Den legger parsede søkesuffikser i søkelisten, og når det finnes servere, setter den samsvarslisten til den tomme strengen. Resultatet er en tunnelresolver som svarer på alt systemet sender den, pluss et suffiks som hjelper med korte navn.

Så et domene på den linjen er ikke en navneromsvelger. Å legge til ett til innsnevrer ikke hvilke spørringer tunnelen bruker, og å fjerne det utvider dem heller ikke. Det eneste som endres, er hvor mange korte navn som fullføres.

Hvorfor hvert navn fortsatt når tunnelresolveren

Med den tomme samsvarsoppføringen er tunnelen en kandidatresolver for vanlige navn, ikke bare for firmaets domene. I en fulltunnelkonfigurasjon betyr dette vanligvis lite, fordi all trafikk uansett er i tunnelen. I en delt tunnel betyr det mye. Offentlige navn kan nå løses av en resolver som bare har en privat sone, og en feil ser ut som en ødelagt VPN når det egentlig er en resolver som bare svarer på en del av navnerommet. Tunnelen er i orden, spørringene går ut, og svarene kommer tomme tilbake.

Det finnes to reparasjoner, og de er forskjellige beslutninger. Gjør tunnelresolveren til en komplett resolver som videresender offentlige navn via den godkjente veien, eller slutt å sende offentlige navn dit ved å endre klientkonfigurasjonen i stedet for domenelisten. Den første holder hver spørring på tunnelen og stoler på oppstrøms. Den andre holder noen spørringer lokalt og aksepterer at private navn kan slutte å løses mens tunnelen er nede.

Hva delt DNS egentlig ville kreve

En resolverpolicy avgrenset til et navnerom krever en klient som lar deg uttrykke den: match domener på Apple-plattformer, eller en tilsvarende innstilling i produktet du bruker. Et konfigurasjonsfelt som bare godtar servere og suffikser kan ikke uttrykke det, uansett hvordan det tegnsettes. En profil kan bære policyen fordi den beskriver en administrert konfigurasjon og ikke et hint ved tilkoblingstid. Den kan navngi domenet, serverne og hva som skal skje når det domenet ikke er tilgjengelig. Det er forskjellen mellom en innstilling og en kontrakt.

På administrerte Apple-enheter leveres dette vanligvis via en konfigurasjonsprofil som bærer de domenespesifikke DNS-innstillingene. Det er en annen mekanisme enn en WireGuard-konfigurasjonsfil, og de to kan bare eksistere sammen hvis klienten respekterer profilen. Sjekk hva klienten din faktisk kaller feltet, før du antar at de to produktene oppfører seg likt. Et skript med wg-quick på en Mac og WireGuard-appen på en iPhone leser lignende linjer og installerer dem gjennom forskjellige lag.

Les de installerte innstillingene, ikke konfigurasjonen

På en Mac kan du undersøke hva systemet endte med, noe som er mer informativt enn å lese filen du skrev på nytt. Resolverlisten viser hvilke servere som er konfigurert for hvilke domener, og de avgrensede spørringene viser hvilken som vant. En klient som ødelegger linjen, viser det her i stedet for i filen du skrev. På iOS finnes det ingen tilsvarende kommandolinje, så beviset der er et resultat: et privat navn som løses gjennom tunnelen, og et offentlig navn hvis svar avslører hvilken resolver som svarte.

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

Disse to kommandoene skriver ut gjeldende resolverkonfigurasjon og DNS-serverne for den aktive tjenesten. Hvis tunnelresolveren vises som standardresolver uten domenebegrensning, gjør konfigurasjonen nøyaktig det klienten ba om. Rett det ved å endre mekanismen, ikke ved å legge til et andre suffiks og håpe at oppførselen endres.