WireGuard DNS iPhone: domēns ir tikai meklēšanas piedēklis

Jūs rakstāt vienu rindu ar atrisinātāja adresi un uzņēmuma domēnu, gaidot, ka tikai šī domēna nosaukumi izmantos tuneļa atrisinātāju. Apple klientā tagad visi nosaukumi dodas turp, un arī īsie domēna nosaukumi tiek atrisināti. Rinda dara divas atsevišķas lietas, un tikai viena no tām ir par to, kurus vaicājumus tunelis apstrādā. Otra ir rakstīšanas ērtība, ko vēlēšanās lasījums paaugstinājis par politiku.

Kā tiek sadalīta DNS rinda

Klients ierakstu nolasa kā sarakstu un klasificē katru vienumu pēc formas. Viss, kas izskatās pēc adreses, kļūst par DNS serveri; viss, kas izskatās pēc domēna, kļūst par meklēšanas piedēkli. Abi nonāk tuneļa iestatījumos, bet dažādos laukos. Ilustratīva rinda tunelim, kas nes privātu atrisinātāju un vienu iekšēju domēnu, izskatās šādi.

DNS = 10.24.8.53, lab.internal.example

Adrese nodrošina atrisinātāju. Domēns nodrošina piedēkli, kas ļauj klientam ierakstīt īsu nosaukumu un sistēmai pirms jautāšanas pievienot pārējo. Neviens no tiem neko nesaka par atrisinātāja ierobežošanu ar šo domēnu, un tieši to cilvēki gaida un nesaņem. Tikai viens platformas lauks var izteikt šo ierobežojumu, un tas nav šis lauks.

Divi Apple lauki, divi dažādi uzdevumi

Apple atklāj atšķirību savā DNS iestatījumu objektā. Meklēšanas domēnu saraksts ir dokumentēts kā saraksts, ko izmanto vienas etiķetes resursdatora nosaukumu kvalificēšanai: ierakstiet tukšu resursdatora nosaukumu, un sistēma var pievienot katru piedēkli pēc kārtas. Tas ir pabeigšanas noteikums, nevis maršrutēšanas noteikums. Nekas šajā sarakstā neizlemj, kuram serverim jautā.

Atbilstības domēnu saraksts ir cita īpašība. Tas izlemj, kuras nosaukumvietas izmanto šo DNS iestatījumu kopu, un tukšs ieraksts nozīmē noklusējuma domēnu, nevis vienu konkrētu piedēkli. pakešu tuneļa iestatījumu ģenerators Apple klientā seko šim modelim. Tas ievieto analizētos meklēšanas piedēkļus meklēšanas sarakstā, un, ja ir serveri, atbilstības sarakstu iestata uz tukšu virkni. Rezultāts ir tuneļa atrisinātājs, kas atbild uz visu, ko sistēma tam sūta, un piedēklis, kas palīdz ar īsajiem nosaukumiem.

Tātad domēns šajā rindā nav nosaukumvietas atlasītājs. Vēl viena pievienošana nesašaurina to, kurus vaicājumus tunelis izmanto, un tā noņemšana tos arī nepaplašina. Vienīgais, kas mainās, ir tas, cik īsu nosaukumu tiek pabeigti.

Kāpēc katrs nosaukums joprojām sasniedz tuneļa atrisinātāju

Ar tukšu atbilstības ierakstu tunelis ir kandidāts atrisinātājs parastiem nosaukumiem, ne tikai uzņēmuma domēnam. Pilna tuneļa konfigurācijā tas parasti maz ko nozīmē, jo viss trafiks jau tā ir tunelī. Sadalītā tunelī tas ir ļoti svarīgi. Publiskos nosaukumus tagad var atrisināt atrisinātājs, kuram ir tikai privāta zona, un kļūme izskatās kā salauzts VPN, lai gan patiesībā tas ir atrisinātājs, kas atbild tikai uz daļu nosaukumvietas. Tunelis ir kārtībā, vaicājumi iziet, un atbildes atgriežas tukšas.

Ir pieejami divi labojumi, un tie ir dažādi lēmumi. Padariet tuneļa atrisinātāju par pilnu atrisinātāju, kas publiskos nosaukumus pārsūta pa apstiprināto ceļu, vai pārtrauciet sūtīt publiskos nosaukumus turp, mainot klienta konfigurāciju, nevis domēnu sarakstu. Pirmais patur katru vaicājumu tunelī un uzticas augšupējam. Otrais patur dažus vaicājumus lokāli un pieņem, ka privātie nosaukumi var pārstāt atrisināties, kamēr tunelis ir izslēgts.

Kas īsti būtu nepieciešams sadalītajam DNS

Uz nosaukumvietu attiecināta atrisinātāja politika prasa klientu, kas ļauj to izteikt: saskaņojiet domēnus Apple platformās vai līdzvērtīgu iestatījumu izmantotajā produktā. Konfigurācijas lauks, kas pieņem tikai serverus un piedēkļus, to nevar izteikt, lai kā tas būtu punktuēts. Profils var nest politiku, jo tas apraksta pārvaldītu konfigurāciju, nevis mājienu savienošanās laikā. Tas var nosaukt domēnu, serverus un to, kam jānotiek, kad šis domēns nav sasniedzams. Tā ir atšķirība starp iestatījumu un līgumu.

Pārvaldītās Apple ierīcēs to parasti piegādā ar konfigurācijas profilu, kas nes domēnam raksturīgos DNS iestatījumus. Tas ir cits mehānisms nekā WireGuard konfigurācijas fails, un abi var pastāvēt kopā tikai tad, ja klients ievēro profilu. Pirms pieņemat, ka abi produkti uzvedas vienādi, pārbaudiet, kā jūsu klients lauku patiešām sauc. Skripts wg-quick Mac datorā un WireGuard lietotne iPhone tālrunī lasa līdzīgas rindas un instalē tās caur dažādiem slāņiem.

Lasiet instalētos iestatījumus, nevis konfigurāciju

Mac datorā varat pārbaudīt, pie kā sistēma nonāca, un tas ir informatīvāk nekā jūsu rakstītā faila atkārtota lasīšana. Atrisinātāju saraksts parāda, kuri serveri ir konfigurēti kuriem domēniem, un ierobežotie vaicājumi parāda, kurš uzvarēja. Klients, kas sabojā rindu, to parāda šeit, nevis jūsu rakstītajā failā. iOS nav līdzvērtīgas komandrindas, tāpēc tur pierādījums ir rezultāts: privāts nosaukums, kas tiek atrisināts caur tuneli, un publisks nosaukums, kura atbilde atklāj, kurš atrisinātājs atbildēja.

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

Šīs divas komandas izdrukā pašreizējo atrisinātāja konfigurāciju un aktīvā pakalpojuma DNS serverus. Ja tuneļa atrisinātājs parādās kā noklusējuma atrisinātājs bez domēna ierobežojuma, konfigurācija dara tieši to, ko klients lūdza. Labojiet to, mainot mehānismu, nevis pievienojot otru piedēkli un cerot, ka uzvedība mainīsies.