WireGuard-DNS på iPhone: domenet er berre eit søkjesuffiks

Du skriv éi linje med ei resolveradresse og eit firmadomene, og reknar med at berre namn i det domenet brukar tunnelresolveren. På Apple-klienten går alle namn no dit, og korte namn i domenet blir også løyste. Linja gjer to separate ting, og berre éin av dei handlar om kva spørjingar tunnelen handterer. Den andre er ei skrivehjelp som er blitt opphøgd til policy av ønsketenking.

Kva DNS-linja blir parsa til

Klienten les oppføringa som ei liste og klassifiserer kvart element etter form. Alt som ser ut som ei adresse, blir ein DNS-server; alt som ser ut som eit domene, blir eit søkjesuffiks. Begge endar i tunnelinnstillingane, men i ulike felt. Ei illustrerande linje for ein tunnel som ber ein privat resolver og eitt internt domene, ser slik ut.

DNS = 10.24.8.53, lab.internal.example

Adressa leverer resolveren. Domenet leverer eit suffiks som lèt klienten skrive eit kort namn og systemet leggje til resten før det spør. Ingen av delane seier noko om å avgrense resolveren til det domenet, og det er nettopp den delen folk ventar og ikkje får. Berre eitt felt på plattforma kan uttrykkje den avgrensinga, og det er ikkje dette feltet.

To Apple-felt, to ulike jobbar

Apple viser skilnaden i DNS-innstillingsobjektet sitt. Søkjedomenelista er dokumentert som lista som blir brukt til å kvalifisere vertsnamn med éin etikett: skriv eit bart vertsnamn, og systemet kan leggje til kvart suffiks etter tur. Det er ein fullføringsregel, ikkje ein rutingregel. Ingenting på den lista avgjer kva server som blir spurd.

Samsvarsdomenelista er ein annan eigenskap. Ho avgjer kva namnerom som brukar dette settet med DNS-innstillingar, og ei tom oppføring tyder standarddomenet snarare enn eitt bestemt suffiks. generator for pakketunnelinnstillingar på Apple-klienten følgjer den modellen. Han legg parsede søkjesuffiks i søkjelista, og når det finst serverar, set han samsvarslista til den tomme strengen. Resultatet er ein tunnelresolver som svarar på alt systemet sender han, pluss eit suffiks som hjelper med korte namn.

Så eit domene på den linja er ikkje ein namneromsveljar. Å leggje til eitt til snevrar ikkje inn kva spørjingar tunnelen brukar, og å fjerne det utvidar dei heller ikkje. Det einaste som endrar seg, er kor mange korte namn som blir fullførte.

Kvifor kvart namn framleis når tunnelresolveren

Med den tomme samsvarsoppføringa er tunnelen ein kandidatresolver for vanlege namn, ikkje berre for firmadomenet. I ein fulltunnelkonfigurasjon tyder dette vanlegvis lite, fordi all trafikk uansett er i tunnelen. I ein delt tunnel tyder det mykje. Offentlege namn kan no bli løyste av ein resolver som berre har ei privat sone, og ein feil ser ut som ein øydelagd VPN når det eigentleg er ein resolver som berre svarar på ein del av namnerommet. Tunnelen er i orden, spørjingane går ut, og svara kjem tomme tilbake.

Det finst to reparasjonar, og dei er ulike avgjerder. Gjer tunnelresolveren til ein komplett resolver som videresender offentlege namn via den godkjende vegen, eller slutt å sende offentlege namn dit ved å endre klientkonfigurasjonen i staden for domenelista. Den første held kvar spørjing på tunnelen og stolar på oppstraums. Den andre held nokre spørjingar lokalt og godtar at private namn kan slutte å bli løyste medan tunnelen er nede.

Kva delt DNS eigentleg ville krevje

Ein resolverpolicy avgrensa til eit namnerom krev ein klient som lèt deg uttrykkje han: match domene på Apple-plattformer, eller ei tilsvarande innstilling i produktet du brukar. Eit konfigurasjonsfelt som berre godtar serverar og suffiks kan ikkje uttrykkje det, same korleis det blir teiknsett. Ein profil kan bere policyen fordi han skildrar ein administrert konfigurasjon og ikkje eit hint ved tilkoplingstid. Han kan namngje domenet, serverane og kva som skal skje når det domenet ikkje er tilgjengeleg. Det er skilnaden mellom ei innstilling og ein kontrakt.

På administrerte Apple-einingar blir dette vanlegvis levert via ein konfigurasjonsprofil som ber dei domenespesifikke DNS-innstillingane. Det er ein annan mekanisme enn ei WireGuard-konfigurasjonsfil, og dei to kan berre eksistere saman om klienten respekterer profilen. Sjekk kva klienten din faktisk kallar feltet, før du reknar med at dei to produkta oppfører seg likt. Eit skript med wg-quick på ein Mac og WireGuard-appen på ein iPhone les liknande linjer og installer dei gjennom ulike lag.

Les dei installerte innstillingane, ikkje konfigurasjonen

På ein Mac kan du undersøkje kva systemet enda med, noko som er meir informativt enn å lese fila du skreiv på nytt. Resolverlista viser kva serverar som er konfigurerte for kva domene, og dei avgrensa spørjingane viser kven som vann. Ein klient som øydelegg linja, viser det her i staden for i fila du skreiv. På iOS finst det inga tilsvarande kommandolinje, så beviset der er eit resultat: eit privat namn som blir løyst gjennom tunnelen, og eit offentleg namn der svaret avslører kven resolver som svara.

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

Desse to kommandoane skriv ut gjeldande resolverkonfigurasjon og DNS-serverane for den aktive tenesta. Om tunnelresolveren viser seg som standardresolver utan domeneavgrensing, gjer konfigurasjonen nøyaktig det klienten bad om. Rett det ved å endre mekanismen, ikkje ved å leggje til eit andre suffiks og håpe at åtferda endrar seg.