WireGuard DNS iPhone: domenas tėra paieškos priesaga

Rašote vieną eilutę su sprendėjo adresu ir įmonės domenu, tikėdamiesi, kad tik to domeno vardai naudos tunelio sprendėją. Apple kliente dabar visi vardai keliauja ten, o trumpi domeno vardai taip pat išsprendžiami. Eilutė daro du atskirus dalykus, ir tik vienas jų susijęs su tuo, kurias užklausas tvarko tunelis. Kitas yra įvedimo patogumas, kurį trokštamas skaitymas pakėlė iki politikos.

Į ką išskaidoma DNS eilutė

Klientas įrašą skaito kaip sąrašą ir kiekvieną elementą klasifikuoja pagal formą. Viskas, kas atrodo kaip adresas, tampa DNS serveriu; viskas, kas atrodo kaip domenas, tampa paieškos priesaga. Abu patenka į tunelio nustatymus, bet į skirtingus laukus. Iliustracinė eilutė tuneliui, kuris neša privatų sprendėją ir vieną vidinį domeną, atrodo taip.

DNS = 10.24.8.53, lab.internal.example

Adresas suteikia sprendėją. Domenas suteikia priesagą, leidžiančią klientui įvesti trumpą vardą, o sistemai prieš klausiant pridėti likusią dalį. Nė vienas iš jų nieko nesako apie sprendėjo apribojimą tuo domenu, ir būtent to žmonės tikisi ir negauna. Tik vienas platformos laukas gali išreikšti tą apribojimą, ir tai ne šis laukas.

Du Apple laukai, dvi skirtingos užduotys

Apple atskleidžia skirtumą savo DNS nustatymų objekte. Paieškos domenų sąrašas dokumentuotas kaip sąrašas, naudojamas vienos etiketės prieglobos vardams kvalifikuoti: įveskite pliką prieglobos vardą ir sistema gali paeiliui pridėti kiekvieną priesagą. Tai užbaigimo taisyklė, o ne maršrutizavimo taisyklė. Niekas tame sąraše nenusprendžia, kurio serverio klausiama.

Atitikties domenų sąrašas yra kita savybė. Jis nusprendžia, kurios vardų erdvės naudoja šį DNS nustatymų rinkinį, o tuščias įrašas reiškia numatytąjį domeną, o ne vieną konkrečią priesagą. paketinio tunelio nustatymų generatorius Apple kliente laikosi to modelio. Jis sudeda išanalizuotas paieškos priesagas į paieškos sąrašą, o kai yra serverių, atitikties sąrašą nustato į tuščią eilutę. Rezultatas – tunelio sprendėjas, atsakantis į viską, ką sistema jam siunčia, ir priesaga, padedanti su trumpais vardais.

Taigi domenas toje eilutėje nėra vardų erdvės parinkiklis. Dar vieno pridėjimas nesusiaurina, kurias užklausas naudoja tunelis, o pašalinimas jų taip pat nepadidina. Vienintelis dalykas, kuris keičiasi, yra tai, kiek trumpų vardų užbaigiama.

Kodėl kiekvienas vardas vis tiek pasiekia tunelio sprendėją

Su tuščiu atitikties įrašu tunelis yra kandidatas sprendėjas įprastiems vardams, ne tik įmonės domenui. Pilno tunelio konfigūracijoje tai paprastai mažai reiškia, nes visas srautas vis tiek yra tunelyje. Skaidomajame tunelyje tai labai svarbu. Viešieji vardai dabar gali būti sprendžiami sprendėjo, kuris turi tik privačią zoną, o gedimas atrodo kaip sugedęs VPN, nors iš tikrųjų tai sprendėjas, atsakantis tik į dalį vardų erdvės. Tunelis tvarkingas, užklausos išeina, o atsakymai grįžta tušti.

Yra du taisymai, ir tai skirtingi sprendimai. Padarykite tunelio sprendėją visišku sprendėju, kuris viešuosius vardus perduoda patvirtintu keliu, arba nustokite siųsti viešuosius vardus ten, keisdami kliento konfigūraciją, o ne domenų sąrašą. Pirmasis laiko kiekvieną užklausą tunelyje ir pasitiki aukštesniuoju srautu. Antrasis laiko kai kurias užklausas vietoje ir pripažįsta, kad privatūs vardai gali nustoti spręstis, kol tunelis išjungtas.

Ko iš tikrųjų reikėtų skaidomajam DNS

Vardų erdve apribota sprendėjo politika reikalauja kliento, kuris leidžia ją išreikšti: suderinkite domenus Apple platformose arba atitinkamą nustatymą naudojamame produkte. Konfigūracijos laukas, priimantis tik serverius ir priesagas, negali jos išreikšti, kad ir kaip būtų punktuotas. Profilis gali nešti politiką, nes jis aprašo valdomą konfigūraciją, o ne užuominą prisijungimo metu. Jis gali įvardyti domeną, serverius ir tai, kas turėtų nutikti, kai tas domenas nepasiekiamas. Tai skirtumas tarp nustatymo ir sutarties.

Valdomuose Apple įrenginiuose tai paprastai pateikiama per konfigūracijos profilį, nešantį konkretaus domeno DNS nustatymus. Tai kitas mechanizmas nei WireGuard konfigūracijos failas, ir abu gali egzistuoti kartu tik jei klientas gerbia profilį. Patikrinkite, kaip jūsų klientas iš tikrųjų vadina lauką, prieš manydami, kad abu produktai elgiasi vienodai. Scenarijus wg-quick Mac kompiuteryje ir WireGuard programėlė iPhone telefone skaito panašias eilutes ir įdiegia jas per skirtingus sluoksnius.

Skaitykite įdiegtus nustatymus, o ne konfigūraciją

Mac kompiuteryje galite patikrinti, prie ko galiausiai priėjo sistema, ir tai informatyviau nei iš naujo skaityti jūsų rašytą failą. Sprendėjų sąrašas rodo, kurie serveriai sukonfigūruoti kuriems domenams, o apribotos užklausos rodo, kuris laimėjo. Eilutę sugadinančios klientas tai parodo čia, o ne jūsų rašytame faile. iOS neturi atitinkamos komandinės eilutės, todėl ten įrodymas yra rezultatas: privatus vardas, išsprendžiamas per tunelį, ir viešas vardas, kurio atsakymas atskleidžia, kuris sprendėjas atsakė.

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

Šios dvi komandos išspausdina dabartinę sprendėjo konfigūraciją ir aktyvios paslaugos DNS serverius. Jei tunelio sprendėjas rodomas kaip numatytasis sprendėjas be domeno apribojimo, konfigūracija daro būtent tai, ko paprašė klientas. Ištaisykite tai keisdami mechanizmą, o ne pridėdami antrą priesagą ir tikėdamiesi, kad elgsena pasikeis.